CN114915577A - 基于非阻塞io模型的设备通讯方法 - Google Patents

基于非阻塞io模型的设备通讯方法 Download PDF

Info

Publication number
CN114915577A
CN114915577A CN202210429983.5A CN202210429983A CN114915577A CN 114915577 A CN114915577 A CN 114915577A CN 202210429983 A CN202210429983 A CN 202210429983A CN 114915577 A CN114915577 A CN 114915577A
Authority
CN
China
Prior art keywords
master
nodes
node
blocking
communication method
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210429983.5A
Other languages
English (en)
Inventor
张祖兴
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wuhan Taiming Hengchuang Information Technology Co Ltd
Original Assignee
Wuhan Taiming Hengchuang Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wuhan Taiming Hengchuang Information Technology Co Ltd filed Critical Wuhan Taiming Hengchuang Information Technology Co Ltd
Priority to CN202210429983.5A priority Critical patent/CN114915577A/zh
Publication of CN114915577A publication Critical patent/CN114915577A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Stored Programmes (AREA)

Abstract

本发明公开了基于非阻塞IO模型的设备通讯方法，属于通讯方法技术领域。采用了springboot打jar包运行方式，方便可以快速任意部署在windows和linux等平台，为提高服务端的响速度和集群模式，使用了redis集群作为数据内存共享工具。与现有通过http、socket等方案相比，比http服务端的并发量能有100倍的提升，与传统socket相比，终端连接数量和使用便捷度在3倍以上。对服务器的要求会降低只好一般。接入难度较低，能节省一半时间。

Description

基于非阻塞IO模型的设备通讯方法
技术领域
本发明涉及通讯方法技术领域，更具体地说，涉及基于非阻塞IO模型的设备通讯方法。
背景技术
在目前智慧社区中的门禁设备交互场景中，设备数据的安全性无法提升，在学校刷脸消费机和自动售货柜设备上无法正常使用，不能支持数百学校学生同时消费，且能够进行设备交互，其问题性和数据实时性以及设备监控方面无法达到最好状态。
专利号CN202011463908.8公开了一种基于VB环境下电测系统多台串口设备通讯方法，包括以下步骤：功能性函数封装，添加报文队列；报文解析函数封装，解析已收到报文并将解析的数据存储至对应的数据结构中；通过状态机函数来完成包括以下功能的任务：功能进度控制、突发上送处理、异常处理、状态刷新、报文解析任务；外部计时器循环调用状态机函数，处理及刷新当前任务进度；状态机判断当前任务状态，如果是处于忙碌状态则等待，优先处理高优先级数据，空闲时发送链路判断通讯报文；每次调用时需要读取串口缓冲池里的数据放入临时缓存区，每次读取到的内容加在后面，先在临时缓存区找到报文帧的报头，根据报头和帧结构找到报文长度字节，通过长度找到报尾并验证是否正确，再根据帧结构验证校验位是否正确，如果任何一个判断出现了否定，则继续找下一个报头，直到找到完整数据帧，找到完整报文帧后，将报文放入解析函数中解析，已找到有效报文后则清除前面无效的报文，没有脏报文，则不处理。
此专利解决了在如果遇到会主动上送的数据，会出现连帧解析问题，处理不好容易丢帧丢数据，对于终端设备响应较慢时，处理不好容易执行错乱当前任务的问题；但无法与现有通过http、socket等方案相比，比http服务端的并发量能有100倍的提升，与传统socket相比，终端连接数量和使用便捷度在3倍以上，对服务器的要求会降低只好一般，接入难度较低，能节省一半时间。
发明内容
1.要解决的技术问题
本发明的目的在于提供基于非阻塞IO模型的设备通讯方法，以解决上述背景技术中提出的问题。
2.技术方案
基于非阻塞IO模型的设备通讯方法，包括以下步骤：
S1：使用Spring Boot生产jar包方式进行打包；
S2：选用redis集群作为数据内存共享工具提高服务端的响应速度；
S3：采用的具体的加密验证方法对数据进行加密；
S4：使用心跳机制和分布式自增机制对设备数据传输丢包问题进行处理。
优选的，所述步骤S1中，结合Spring Boot与Spring Cloud和Docker技术来构建微服务并部署到云端。
优选的，所述S2中，Redis支持三种集群方案，包括主从复制模式、哨兵模式和Cluster模式。
优选的，所述步骤S3中，复制模式：master能自动将数据同步到slave，可以进行读写分离，分担master的读压力。
优选的，所述步骤S3中，哨兵模式：
S31：监控master、slave是否正常运行；
S32:当master出现故障时，能自动将一个slave转换为master；
S33：多个哨兵可以监控同一个Redis，哨兵之间也会自动监控；
S34:哨兵启动后，会与要监控的master建立两条连接。
优选的，所述步骤S3中，Cluster模式：
在Redis的每个节点上，都有一个插槽(slot)，取值范围为0-16383；
当我们存取key的时候，Redis会根据CRC16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作；
为了保证高可用，Cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点；
当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了，那么该集群就无法再提供服务了；
Cluster模式集群节点最小配置6个节点(3主3从，因为需要半数以上)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。
优选的，所述步骤S4中，加密验证方法具有三种方法：BASE64、MD5和AES；
所述BASE64，采用Base64编码具有不可读性，即所编码的数据不会被人用肉眼所直接看到；
所述MD5用大容量信息在用数字签名软件签署私人密钥前被”压缩”成一种保密的格式；
所述AES进行多轮的重复和变换，包括如下步骤：密钥扩展；初始轮；重复轮，每一轮又包括：SubBytes、ShiftRows、MixColumns、AddRoundKey；最终轮，最终轮没有MixColumns。
优选的，所述步骤S4中，心跳机制，分布式系统中，分布在不同主机上的节点需要检测其他节点的状态，如服务器节点需要检测从节点是否失效，为了检测对方节点的有效性，每隔固定时间就发送一个固定信息给对方，对方回复一个固定信息，如果长时间没有收到对方的回复，则断开与对方的连接；
发包方既可以是服务端，也可以是客户端，这要看具体实现，因为是每隔固定时间发送一次，类似心跳，所以发送的固定信息称为心跳包，心跳包一般为比较小的包，可根据具体实现，心跳包主要应用于长连接的保持与短线链接。
优选的，所述步骤S4中，分布式自增机制：为解决设备数据传输丢包问题,每次设备与服务端交互都使用了分布式自增长ID，与上一条消息进行比对确认。
优选的，所述信息对比确认后，当没有收到上一条消息的收到确认回复会立刻重发上一条消息,只到重发10次或者收到消息接收通知。
3.有益效果
相比于现有技术，本发明的优点在于：
1、采用了springboot打jar包运行方式，方便可以快速任意部署在windows和linux等平台。
2、为提高服务端的响速度和集群模式，使用了redis集群作为数据内存共享工具。
3、为了提高数据之间交互传输的安全性，采用了多种数据加密验证方式，数据之间传输使用了jProtocol Buffer二进制数据格式，在传输数据量较大的需求场景下，Protocol Buffer比XML、JSON更小(3到10倍)、更快(20到100倍)、使用&维护更简单；而且Protocol Buffer可以跨平台。服务端接收到数据之后将数据反序列化，得到的是RSA非堆成加密数据，根据时间、随即串、设备ID等数据组后解密之后得到实际设备交互数据。将解密之后的数据与加密因子进行再次比对确认。完全匹配之后方可接收数据。
4、为解决设备数据传输丢包问题，每次设备与服务端交互都使用了分布式自增长ID，与上一条消息进行比对确认，当没有收到上一条消息的收到确认回复会立刻重发上一条消息，只到重发10次或者收到消息接收通知。为避免出现设备离线数、设备会每5秒向服务端发送一条心跳指令，用来监控设备状态。当设备离线时或者网络超时会自动重新连接并将设备报告发送到服务端。
5、与现有通过http、socket等方案相比，比http服务端的并发量能有100倍的提升，与传统socket相比，终端连接数量和使用便捷度在3倍以上。对服务器的要求会降低只好一般。接入难度较低，能节省一半时间。
附图说明
图1为本发明基于非阻塞IO模型的设备通讯方法流程示意图；
图2为本发明基于非阻塞IO模型的设备通讯方法主从复制模式流程示意图；
图3为本发明基于非阻塞IO模型的设备通讯方法哨兵模式流程示意图；
图4为本发明基于非阻塞IO模型的设备通讯方法Cluster模式基本原理示意图。
具体实施方式
在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”、“顺时针”、“逆时针”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的设备或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。
在本发明的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“设置有”、“套设/接”、“连接”等，应做广义理解，例如“连接”，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。
请参阅图1-4,本发明提供一种技术方案：
基于非阻塞IO模型的设备通讯方法，包括以下步骤：
S1：使用Spring Boot生产jar包方式进行打包；
S2：选用redis集群作为数据内存共享工具提高服务端的响应速度；
S3：采用的具体的加密验证方法对数据进行加密；
S4：使用心跳机制和分布式自增机制对设备数据传输丢包问题进行处理。
步骤S1中，结合Spring Boot与Spring Cloud和Docker技术来构建微服务并部署到云端。
S2中，Redis支持三种集群方案，包括主从复制模式、哨兵模式和Cluster模式。
步骤S3中，复制模式：master能自动将数据同步到slave，可以进行读写分离，分担master的读压力。
步骤S3中，哨兵模式：
S31：监控master、slave是否正常运行；
S32:当master出现故障时，能自动将一个slave转换为master；
S33：多个哨兵可以监控同一个Redis，哨兵之间也会自动监控；
S34:哨兵启动后，会与要监控的master建立两条连接。
步骤S3中，Cluster模式：
在Redis的每个节点上，都有一个插槽(slot)，取值范围为0-16383；
当我们存取key的时候，Redis会根据CRC16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作；
为了保证高可用，Cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点；
当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了，那么该集群就无法再提供服务了；
Cluster模式集群节点最小配置6个节点(3主3从，因为需要半数以上)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。
步骤S4中，加密验证方法具有三种方法：BASE64、MD5和AES；
BASE64，采用Base64编码具有不可读性，即所编码的数据不会被人用肉眼所直接看到；
MD5用大容量信息在用数字签名软件签署私人密钥前被”压缩”成一种保密的格式；
AES进行多轮的重复和变换，包括如下步骤：密钥扩展；初始轮；重复轮，每一轮又包括：SubBytes、ShiftRows、MixColumns、AddRoundKey；最终轮，最终轮没有MixColumns。
步骤S4中，心跳机制，分布式系统中，分布在不同主机上的节点需要检测其他节点的状态，如服务器节点需要检测从节点是否失效，为了检测对方节点的有效性，每隔固定时间就发送一个固定信息给对方，对方回复一个固定信息，如果长时间没有收到对方的回复，则断开与对方的连接；
发包方既可以是服务端，也可以是客户端，这要看具体实现，因为是每隔固定时间发送一次，类似心跳，所以发送的固定信息称为心跳包，心跳包一般为比较小的包，可根据具体实现，心跳包主要应用于长连接的保持与短线链接。
步骤S4中，分布式自增机制：为解决设备数据传输丢包问题,每次设备与服务端交互都使用了分布式自增长ID，与上一条消息进行比对确认。
信息对比确认后，当没有收到上一条消息的收到确认回复会立刻重发上一条消息,只到重发10次或者收到消息接收通知。
除此之外，采用了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倍以上。对服务器的要求会降低只好一般。接入难度较低，能节省一半时间。
综上所述：基于非阻塞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倍以上。对服务器的要求会降低只好一般。接入难度较低，能节省一半时间。
以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的仅为本发明的优选例，并不用来限制本发明，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (10)

1.基于非阻塞IO模型的设备通讯方法，其特征在于：包括以下步骤：
S1：使用Spring Boot生产jar包方式进行打包；
S2：选用redis集群作为数据内存共享工具提高服务端的响应速度；
S3：采用的具体的加密验证方法对数据进行加密；
S4：使用心跳机制和分布式自增机制对设备数据传输丢包问题进行处理。
2.根据权利要求1所述的基于非阻塞IO模型的设备通讯方法，其特征在于：所述步骤S1中，结合Spring Boot与Spring Cloud和Docker技术来构建微服务并部署到云端。
3.根据权利要求1所述的基于非阻塞IO模型的设备通讯方法，其特征在于：步骤S2中，Redis支持三种集群方案，包括主从复制模式、哨兵模式和Cluster模式。
4.根据权利要求1所述的基于非阻塞IO模型的设备通讯方法，其特征在于：所述步骤S3中，复制模式：master能自动将数据同步到slave，可以进行读写分离，分担master的读压力。
5.根据权利要求1所述的基于非阻塞IO模型的设备通讯方法，其特征在于：所述步骤S3中，哨兵模式：
S31：监控master、slave是否正常运行；
S32:当master出现故障时，能自动将一个slave转换为master；
S33：多个哨兵可以监控同一个Redis，哨兵之间也会自动监控；
S34:哨兵启动后，会与要监控的master建立两条连接。
6.根据权利要求1所述的基于非阻塞IO模型的设备通讯方法，其特征在于：所述步骤S3中，Cluster模式：
在Redis的每个节点上，都有一个插槽(slot)，取值范围为0-16383；
当我们存取key的时候，Redis会根据CRC16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作；
为了保证高可用，Cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点；
当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了，那么该集群就无法再提供服务了；
Cluster模式集群节点最小配置6个节点(3主3从，因为需要半数以上)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。
7.根据权利要求1所述的基于非阻塞IO模型的设备通讯方法，其特征在于：所述步骤S4中，加密验证方法具有三种方法：BASE64、MD5和AES；
所述BASE64，采用Base64编码具有不可读性，即所编码的数据不会被人用肉眼所直接看到；
所述MD5用大容量信息在用数字签名软件签署私人密钥前被”压缩”成一种保密的格式；
所述AES进行多轮的重复和变换，包括如下步骤：密钥扩展；初始轮；重复轮，每一轮又包括：SubBytes、ShiftRows、MixColumns、AddRoundKey；最终轮，最终轮没有MixColumns。
8.根据权利要求1所述的基于非阻塞IO模型的设备通讯方法，其特征在于：所述步骤S4中，心跳机制，分布式系统中，分布在不同主机上的节点需要检测其他节点的状态，如服务器节点需要检测从节点是否失效，为了检测对方节点的有效性，每隔固定时间就发送一个固定信息给对方，对方回复一个固定信息，如果长时间没有收到对方的回复，则断开与对方的连接；
发包方既可以是服务端，也可以是客户端，这要看具体实现，因为是每隔固定时间发送一次，类似心跳，所以发送的固定信息称为心跳包，心跳包一般为比较小的包，可根据具体实现，心跳包主要应用于长连接的保持与短线链接。
9.根据权利要求1所述的基于非阻塞IO模型的设备通讯方法，其特征在于：所述步骤S4中，分布式自增机制：为解决设备数据传输丢包问题,每次设备与服务端交互都使用了分布式自增长ID，与上一条消息进行比对确认。
10.根据权利要求9所述的基于非阻塞IO模型的设备通讯方法，其特征在于：信息对比确认后，当没有收到上一条消息的收到确认回复会立刻重发上一条消息,只到重发10次或者收到消息接收通知。
CN202210429983.5A 2022-04-22 2022-04-22 基于非阻塞io模型的设备通讯方法 Pending CN114915577A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210429983.5A CN114915577A (zh) 2022-04-22 2022-04-22 基于非阻塞io模型的设备通讯方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210429983.5A CN114915577A (zh) 2022-04-22 2022-04-22 基于非阻塞io模型的设备通讯方法

Publications (1)

Publication Number Publication Date
CN114915577A true CN114915577A (zh) 2022-08-16

Family

ID=82765661

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210429983.5A Pending CN114915577A (zh) 2022-04-22 2022-04-22 基于非阻塞io模型的设备通讯方法

Country Status (1)

Country Link
CN (1) CN114915577A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116095099A (zh) * 2023-01-20 2023-05-09 广东省中山市质量计量监督检测所 一种基于机器视觉的机械零件质检系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009035810A1 (en) * 2007-09-11 2009-03-19 Oracle International Corporation Concurrency in event processing networks for event server
CN106506605A (zh) * 2016-10-14 2017-03-15 华南理工大学 一种基于微服务架构的SaaS应用构建方法
CN107343034A (zh) * 2017-06-26 2017-11-10 杭州铭师堂教育科技发展有限公司 基于QConf的Redis高可用系统及方法
CN109815049A (zh) * 2017-11-21 2019-05-28 北京金山云网络技术有限公司 节点宕机恢复方法、装置、电子设备及存储介质
CN111694638A (zh) * 2020-05-28 2020-09-22 中国平安人寿保险股份有限公司 规则包加载方法、规则包执行方法及终端设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009035810A1 (en) * 2007-09-11 2009-03-19 Oracle International Corporation Concurrency in event processing networks for event server
CN106506605A (zh) * 2016-10-14 2017-03-15 华南理工大学 一种基于微服务架构的SaaS应用构建方法
CN107343034A (zh) * 2017-06-26 2017-11-10 杭州铭师堂教育科技发展有限公司 基于QConf的Redis高可用系统及方法
CN109815049A (zh) * 2017-11-21 2019-05-28 北京金山云网络技术有限公司 节点宕机恢复方法、装置、电子设备及存储介质
CN111694638A (zh) * 2020-05-28 2020-09-22 中国平安人寿保险股份有限公司 规则包加载方法、规则包执行方法及终端设备

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KMING.QIU: ""SPRINGCLOUD之搭建REDIS集群（REDIS-CLUSTER）及主从复制"", Retrieved from the Internet <URL:https://blog.csdn.net/qq_42378797/article/details/112426001> *
熟透的蜗牛: ""REDIS主从复制&哨兵机制&SPRINGBOOT整合哨兵"", Retrieved from the Internet <URL:https://blog.csdn.net/weixin_39555954/article/details/120147401> *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116095099A (zh) * 2023-01-20 2023-05-09 广东省中山市质量计量监督检测所 一种基于机器视觉的机械零件质检系统

Similar Documents

Publication Publication Date Title
CN105516080B (zh) Tcp连接的处理方法、装置及系统
Correia et al. How to tolerate half less one Byzantine nodes in practical distributed systems
US20190116183A1 (en) Fast heartbeat liveness between packet processing engines using media access control security (macsec) communication
CN103475655B (zh) 一种实现IPSecVPN主备链路动态切换的方法
CN101478546B (zh) 一种保护网络安全的方法和网络安全保护设备
US7698556B2 (en) Secure spontaneous associations between networkable devices
CN102859921A (zh) 用于实现加速的吞吐量的系统和方法
CN109561159A (zh) 一种基于Websocket长连接的数据处理方法及系统
CN103259768A (zh) 一种消息认证方法、系统和装置
Gao et al. Toward emulation-based performance assessment of constrained application protocol in dynamic networks
JP2010050958A (ja) 送信端末、受信端末、通信端末および情報配信システム
US20210144130A1 (en) Method for securing communication without management of states
CN101340289A (zh) 防重放攻击方法及其系统
CN114915577A (zh) 基于非阻塞io模型的设备通讯方法
CN109391661A (zh) 物联网终端的区块链组网方法和系统
CN110049027A (zh) 一种用于区块链网络信息的传输平台
CN103795518A (zh) 一种设备间端口模式同步方法、设备及系统
CN104539517A (zh) 一种基于智能终端本地服务器的聊天方法及系统
WO2014183535A1 (zh) 一种用于mtc设备组的小数据安全传输方法和系统
CN102984175A (zh) 一种无ip监控前端设备和一种代理装置
CN103002041A (zh) 一种处于nat环境下的设备的通信方法
CN103379182A (zh) 数据传输方法和客户端
CN107426166A (zh) 一种信息的获取方法、装置及电子设备
US20180351802A1 (en) State Synchronization Between a Controller and a Switch in a Communications Network
CN111711689B (zh) 投顾系统图文直播方法及系统、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20220816