基于非阻塞IO模型的设备通讯方法与流程

基于非阻塞io模型的设备通讯方法
技术领域
1.本发明涉及通讯方法技术领域，更具体地说，涉及基于非阻塞io模型的设备通讯方法。


背景技术：

2.在目前智慧社区中的门禁设备交互场景中，设备数据的安全性无法提升，在学校刷脸消费机和自动售货柜设备上无法正常使用，不能支持数百学校学生同时消费，且能够进行设备交互，其问题性和数据实时性以及设备监控方面无法达到最好状态。
3.专利号cn202011463908.8公开了一种基于vb环境下电测系统多台串口设备通讯方法，包括以下步骤：功能性函数封装，添加报文队列；报文解析函数封装，解析已收到报文并将解析的数据存储至对应的数据结构中；通过状态机函数来完成包括以下功能的任务：功能进度控制、突发上送处理、异常处理、状态刷新、报文解析任务；外部计时器循环调用状态机函数，处理及刷新当前任务进度；状态机判断当前任务状态，如果是处于忙碌状态则等待，优先处理高优先级数据，空闲时发送链路判断通讯报文；每次调用时需要读取串口缓冲池里的数据放入临时缓存区，每次读取到的内容加在后面，先在临时缓存区找到报文帧的报头，根据报头和帧结构找到报文长度字节，通过长度找到报尾并验证是否正确，再根据帧结构验证校验位是否正确，如果任何一个判断出现了否定，则继续找下一个报头，直到找到完整数据帧，找到完整报文帧后，将报文放入解析函数中解析，已找到有效报文后则清除前面无效的报文，没有脏报文，则不处理。
4.此专利解决了在如果遇到会主动上送的数据，会出现连帧解析问题，处理不好容易丢帧丢数据，对于终端设备响应较慢时，处理不好容易执行错乱当前任务的问题；但无法与现有通过http、socket等方案相比，比http服务端的并发量能有100倍的提升，与传统socket相比，终端连接数量和使用便捷度在3倍以上，对服务器的要求会降低只好一般，接入难度较低，能节省一半时间。


技术实现要素：

5.1.要解决的技术问题
6.本发明的目的在于提供基于非阻塞io模型的设备通讯方法，以解决上述背景技术中提出的问题。
7.2.技术方案
8.基于非阻塞io模型的设备通讯方法，包括以下步骤：
9.s1：使用spring boot生产jar包方式进行打包；
10.s2：选用redis集群作为数据内存共享工具提高服务端的响应速度；
11.s3：采用的具体的加密验证方法对数据进行加密；
12.s4：使用心跳机制和分布式自增机制对设备数据传输丢包问题进行处理。
13.优选的，所述步骤s1中，结合spring boot与spring cloud和docker技术来构建微
服务并部署到云端。
14.优选的，所述s2中，redis支持三种集群方案，包括主从复制模式、哨兵模式和cluster模式。
15.优选的，所述步骤s3中，复制模式：master能自动将数据同步到slave，可以进行读写分离，分担master的读压力。
16.优选的，所述步骤s3中，哨兵模式：
17.s31：监控master、slave是否正常运行；
18.s32:当master出现故障时，能自动将一个slave转换为master；
19.s33：多个哨兵可以监控同一个redis，哨兵之间也会自动监控；
20.s34:哨兵启动后，会与要监控的master建立两条连接。
21.优选的，所述步骤s3中，cluster模式：
22.在redis的每个节点上，都有一个插槽(slot)，取值范围为0-16383；
23.当我们存取key的时候，redis会根据crc16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作；
24.为了保证高可用，cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点；
25.当其它主节点ping一个主节点a时，如果半数以上的主节点与a通信超时，那么认为主节点a宕机了。如果主节点a和它的从节点都宕机了，那么该集群就无法再提供服务了；
26.cluster模式集群节点最小配置6个节点(3主3从，因为需要半数以上)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。
27.优选的，所述步骤s4中，加密验证方法具有三种方法：base64、md5和aes；
28.所述base64，采用base64编码具有不可读性，即所编码的数据不会被人用肉眼所直接看到；
29.所述md5用大容量信息在用数字签名软件签署私人密钥前被”压缩”成一种保密的格式；
30.所述aes进行多轮的重复和变换，包括如下步骤：密钥扩展；初始轮；重复轮，每一轮又包括：subbytes、shiftrows、mixcolumns、addroundkey；最终轮，最终轮没有mixcolumns。
31.优选的，所述步骤s4中，心跳机制，分布式系统中，分布在不同主机上的节点需要检测其他节点的状态，如服务器节点需要检测从节点是否失效，为了检测对方节点的有效性，每隔固定时间就发送一个固定信息给对方，对方回复一个固定信息，如果长时间没有收到对方的回复，则断开与对方的连接；
32.发包方既可以是服务端，也可以是客户端，这要看具体实现，因为是每隔固定时间发送一次，类似心跳，所以发送的固定信息称为心跳包，心跳包一般为比较小的包，可根据具体实现，心跳包主要应用于长连接的保持与短线链接。
33.优选的，所述步骤s4中，分布式自增机制：为解决设备数据传输丢包问题,每次设备与服务端交互都使用了分布式自增长id，与上一条消息进行比对确认。
34.优选的，所述信息对比确认后，当没有收到上一条消息的收到确认回复会立刻重
发上一条消息,只到重发10次或者收到消息接收通知。
35.3.有益效果
36.相比于现有技术，本发明的优点在于：
37.1、采用了springboot打jar包运行方式，方便可以快速任意部署在windows和linux等平台。
38.2、为提高服务端的响速度和集群模式，使用了redis集群作为数据内存共享工具。
39.3、为了提高数据之间交互传输的安全性，采用了多种数据加密验证方式，数据之间传输使用了jprotocol buffer二进制数据格式，在传输数据量较大的需求场景下，protocol buffer比xml、json更小(3到10倍)、更快(20到100倍)、使用&维护更简单；而且protocol buffer可以跨平台。服务端接收到数据之后将数据反序列化，得到的是rsa非堆成加密数据，根据时间、随即串、设备id等数据组后解密之后得到实际设备交互数据。将解密之后的数据与加密因子进行再次比对确认。完全匹配之后方可接收数据。
40.4、为解决设备数据传输丢包问题，每次设备与服务端交互都使用了分布式自增长id，与上一条消息进行比对确认，当没有收到上一条消息的收到确认回复会立刻重发上一条消息，只到重发10次或者收到消息接收通知。为避免出现设备离线数、设备会每5秒向服务端发送一条心跳指令，用来监控设备状态。当设备离线时或者网络超时会自动重新连接并将设备报告发送到服务端。
41.5、与现有通过http、socket等方案相比，比http服务端的并发量能有100倍的提升，与传统socket相比，终端连接数量和使用便捷度在3倍以上。对服务器的要求会降低只好一般。接入难度较低，能节省一半时间。
附图说明
42.图1为本发明基于非阻塞io模型的设备通讯方法流程示意图；
43.图2为本发明基于非阻塞io模型的设备通讯方法主从复制模式流程示意图；
44.图3为本发明基于非阻塞io模型的设备通讯方法哨兵模式流程示意图；
45.图4为本发明基于非阻塞io模型的设备通讯方法cluster模式基本原理示意图。
具体实施方式
46.在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”、“顺时针”、“逆时针”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的设备或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。
47.在本发明的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
48.在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“设置有”、“套设/接”、“连接”等，应做广义理解，例如“连接”，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。
49.请参阅图1-4,本发明提供一种技术方案：
50.基于非阻塞io模型的设备通讯方法，包括以下步骤：
51.s1：使用spring boot生产jar包方式进行打包；
52.s2：选用redis集群作为数据内存共享工具提高服务端的响应速度；
53.s3：采用的具体的加密验证方法对数据进行加密；
54.s4：使用心跳机制和分布式自增机制对设备数据传输丢包问题进行处理。
55.步骤s1中，结合spring boot与spring cloud和docker技术来构建微服务并部署到云端。
56.s2中，redis支持三种集群方案，包括主从复制模式、哨兵模式和cluster模式。
57.步骤s3中，复制模式：master能自动将数据同步到slave，可以进行读写分离，分担master的读压力。
58.步骤s3中，哨兵模式：
59.s31：监控master、slave是否正常运行；
60.s32:当master出现故障时，能自动将一个slave转换为master；
61.s33：多个哨兵可以监控同一个redis，哨兵之间也会自动监控；
62.s34:哨兵启动后，会与要监控的master建立两条连接。
63.步骤s3中，cluster模式：
64.在redis的每个节点上，都有一个插槽(slot)，取值范围为0-16383；
65.当我们存取key的时候，redis会根据crc16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作；
66.为了保证高可用，cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点；
67.当其它主节点ping一个主节点a时，如果半数以上的主节点与a通信超时，那么认为主节点a宕机了。如果主节点a和它的从节点都宕机了，那么该集群就无法再提供服务了；
68.cluster模式集群节点最小配置6个节点(3主3从，因为需要半数以上)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。
69.步骤s4中，加密验证方法具有三种方法：base64、md5和aes；
70.base64，采用base64编码具有不可读性，即所编码的数据不会被人用肉眼所直接看到；
71.md5用大容量信息在用数字签名软件签署私人密钥前被”压缩”成一种保密的格式；
72.aes进行多轮的重复和变换，包括如下步骤：密钥扩展；初始轮；重复轮，每一轮又包括：subbytes、shiftrows、mixcolumns、addroundkey；最终轮，最终轮没有mixcolumns。
73.步骤s4中，心跳机制，分布式系统中，分布在不同主机上的节点需要检测其他节点的状态，如服务器节点需要检测从节点是否失效，为了检测对方节点的有效性，每隔固定时间就发送一个固定信息给对方，对方回复一个固定信息，如果长时间没有收到对方的回复，则断开与对方的连接；
74.发包方既可以是服务端，也可以是客户端，这要看具体实现，因为是每隔固定时间
发送一次，类似心跳，所以发送的固定信息称为心跳包，心跳包一般为比较小的包，可根据具体实现，心跳包主要应用于长连接的保持与短线链接。
75.步骤s4中，分布式自增机制：为解决设备数据传输丢包问题,每次设备与服务端交互都使用了分布式自增长id，与上一条消息进行比对确认。
76.信息对比确认后，当没有收到上一条消息的收到确认回复会立刻重发上一条消息,只到重发10次或者收到消息接收通知。
77.除此之外，采用了springboot打jar包运行方式，方便可以快速任意部署在windows和linux等平台；为提高服务端的响速度和集群模式，使用了redis集群作为数据内存共享工具；为了提高数据之间交互传输的安全性，采用了多种数据加密验证方式，数据之间传输使用了jprotocol buffer二进制数据格式，在传输数据量较大的需求场景下，protocol buffer比xml、json更小(3到10倍)、更快(20到100倍)、使用&维护更简单；而且protocol buffer可以跨平台。服务端接收到数据之后将数据反序列化，得到的是rsa非堆成加密数据，根据时间、随即串、设备id等数据组后解密之后得到实际设备交互数据。将解密之后的数据与加密因子进行再次比对确认。完全匹配之后方可接收数据；为解决设备数据传输丢包问题，每次设备与服务端交互都使用了分布式自增长id，与上一条消息进行比对确认，当没有收到上一条消息的收到确认回复会立刻重发上一条消息，只到重发10次或者收到消息接收通知。为避免出现设备离线数、设备会每5秒向服务端发送一条心跳指令，用来监控设备状态。当设备离线时或者网络超时会自动重新连接并将设备报告发送到服务端；与现有通过http、socket等方案相比，比http服务端的并发量能有100倍的提升，与传统socket相比，终端连接数量和使用便捷度在3倍以上。对服务器的要求会降低只好一般。接入难度较低，能节省一半时间。
78.综上所述：基于非阻塞io模型的设备通讯方法，包括以下步骤：使用spring boot生产jar包方式进行打包；选用redis集群作为数据内存共享工具提高服务端的响应速度；采用的具体的加密验证方法对数据进行加密；使用心跳机制和分布式自增机制对设备数据传输丢包问题进行处理。采用了springboot打jar包运行方式，方便可以快速任意部署在windows和linux等平台；为提高服务端的响速度和集群模式，使用了redis集群作为数据内存共享工具；为了提高数据之间交互传输的安全性，采用了多种数据加密验证方式，数据之间传输使用了jprotocol buffer二进制数据格式，在传输数据量较大的需求场景下，protocol buffer比xml、json更小(3到10倍)、更快(20到100倍)、使用&维护更简单；而且protocol buffer可以跨平台。服务端接收到数据之后将数据反序列化，得到的是rsa非堆成加密数据，根据时间、随即串、设备id等数据组后解密之后得到实际设备交互数据。将解密之后的数据与加密因子进行再次比对确认。完全匹配之后方可接收数据；为解决设备数据传输丢包问题，每次设备与服务端交互都使用了分布式自增长id，与上一条消息进行比对确认，当没有收到上一条消息的收到确认回复会立刻重发上一条消息，只到重发10次或者收到消息接收通知。为避免出现设备离线数、设备会每5秒向服务端发送一条心跳指令，用来监控设备状态。当设备离线时或者网络超时会自动重新连接并将设备报告发送到服务端；与现有通过http、socket等方案相比，比http服务端的并发量能有100倍的提升，与传统socket相比，终端连接数量和使用便捷度在3倍以上。对服务器的要求会降低只好一般。接入难度较低，能节省一半时间。
79.以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的仅为本发明的优选例，并不用来限制本发明，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。