集中设备采集监控系统架构思路

最近在帮朋友优化一套系统，系统为设备黑盒监控，设备黑盒通过移动网络，周期性将设备数据上报服务器，对周期性上报的数据进行分析处理后，进行存储。并将远端的控制指令，带回设备端，实现远端对设备的自动控制。

因为终端设备的数量不确定，当前有几十台，采用TCP进行报文上传，服务器端需要进行TCP会话连接上的数据的并发处理，原有系统，将数据存储环节也放在会话连接上了，这造成了很多的问题，因为设备的增加，必然需要对数据库的连接会话增加，因为数据库的写入和统计，以及IO性能的影响，势必造成速度降低，会影响系统的吞吐，可能会造成某个连接上出现大量的缓冲数据，甚至造成TCP缓冲区的溢出。为了规避上述风险，在新的系统处理时，加入了一层消息缓存层，TCP服务层只负责对字节流进行拆解包处理，转化为可调用的结构化数据之后，直接通过RMI送入异步缓存消息处理池，在这里结构化数据被再次转化成消息，但是TCP服务层的任务基本已经结束。异步消息缓存处理池，按照先入先处理的原则，首先由缓存处理线程，将消息落入硬盘存储，并构建消息处理ID，因为采用队列缓存，并且落盘速度会很快，此处处理会相当迅速。落盘之后，将消息ID分发到处理线程池，如果处理线程池忙，则进行消息ID的排队，因为消息已经落盘了，不会对系统内存造成额外的负载。消息处理ID由独立的数据库单独存储，处理完的消息从对应的存储移除，保证了即使每天有大量的消息处理包，也不会造成消息路由系统的负载。

异步消息接收缓存层，同时会将消息分发一份到异步下发消息缓存，此处会从异步消息下发缓存中，迅速获取对应设备要处理的下发指令，如果存在指令，则与当前的消息进行比对处理，检查当前消息是否是已经成功执行完命令的消息，或是需要处理，如果不存在命令，则此消息立即抛弃。存在的消息指令，被通过异步消息下发缓存层，广播到TCP服务层，由其管理的会话连接池，下发到对应的设备上，完成最终的指令下发操作。采用此种机制，避免了同步阻塞等待判断。