我们是传统行业，但是我们有一颗不传统的心。企业用户遍布国内和国外，面对行业，要建设行业级的（大）数据平台。一提到大数据平台，大家往往想到Hadoop、Spark、Nosql、分布式等等，我只能说我们还比较低级，但是后期肯定会涉及到这些技术。做大数据平台是有风险的，抛开绝技术方面，应该从四个方面来考虑这个问题：企业思维的转变、是否解决实际问题、是否落地可实施、是否有增值效应。
不转变思维，企业不死，个人死。为什么呢？战略定力差，推进动力不足，随时面临PASS的风险。
不能解决实际问题，那只是空中楼阁，创造不了实际的价值，变现也很困难，忽悠人是不能长久的。
不能落地可实施，要么是团体不行，要么是技术不行，总之还是团队不行，带头人不一定什么都懂，但是要有绝对的推进能力。
不能有增值效应，最终最不到钱，这是任何人都不愿意看到的情况。再美的女人，不能生孩子，你也要多顾虑一些。所以我大学同学找对象的第一原则，就是能生孩子。
全国大概有238个站点，不包括国外。每个站点大概有2000个传感器，5分钟上传一次数据，相当于1秒钟要传7个点的传感器。在大数据平台再进行数据的深度分析，帮助生产企业改进生产工艺，以及安全防范。
通讯协议主要从指令要求、传输流程、通讯层级、应答模式、重发机制、超时界定、数据完整性、通讯效率、代码和字典定义等，进行综合考虑，有些是用技术实现的，有些是用协议保障的……。
通讯协议命令包如下：
避免频繁的操作数据库，在上传数据端和接收数据端进行了缓冲设计，作为临时数据的存储，当然这些临时数据也可以保存在Hadoop上，前期没有打算这样做。
客户端缓存结构图：
服务端缓存结构图：
服务端使用的是SeverSuperIO（SSIO），并没有使用其他的框架。一是考虑到不同协议的接入，二是方便对站点的通讯状态、IO状态，以及站点进行管理。客户端就是自己写的控制台程序。
（1） 第一天客户端与服务端进行测试的时候，第二天发现客户端直接崩了，提示：OutOfMemoryException。经排查，再测试至今还没有出现问题。可能是因为线程并且对数据操作引起的。
（2） 测试过程中，发现接收到的数据开头和结尾都对，但是就是解析数据包为空。这个问题是因为CRC16校验与结尾字节数据组重复了，SeverSuperIO（SSIO）在过滤数据的时候，少了两个字节。后来把CRC16校验改成了校验和。
测试12小时，如下图：