物联网操作系统中基于iLink协议的云边双向数据同步方法与流程

物联网操作系统中基于ilink协议的云边双向数据同步方法
技术领域
1.本发明涉及一种云边同步方法，更具体的说是涉及一种物联网操作系统中基于ilink协议的云边双向数据同步方法。


背景技术：

2.通常的数据同步指的是主从节点之间的同步，比如redis在集群模式下master节点通过psync指令向slave节点同步数据，mysql通过binlog进行同步，这些同步方式均只能进行单向同步，它们更多的是一种技术手段，因此无法直接拿来用于业务场景。
3.如最接近的场景是手机的固件更新，手机可以理解为是具有一定边缘计算能力的边缘服务，开发商会通过固件更新的方式向手机推送升级指令，以此来修复问题或增加新功能，在升级过程中，手机主动向开发商服务器请求下载升级包，但是这样的场景也只是单向的过程。
4.又如专利号为2020108481289，名称为一种云边协同方法及系统，公开了步骤s1至步骤s5，通过上述步骤的设置，以此实现边云同步，然而上述方式实现的数据同步基本都是单向的，在物联网需要云边协同的场景下无法满足对应的需求，而场景比较相似的手机固件更新方案，发起更新的一端必须处于公网环境下，这样被更新端才能正常下载到升级包，因此如果将这种方法拿来改造，云端服务器也无法解决网络问题从边缘侧下载到数据包。除此之外，手机的固件更新一般都会在网络较好的家庭wifi环境中进行，而物联网边缘侧服务网络环境较差，基本只能使用4g甚至3g的信号，所以可能存在数据丢失的情形，并且对于数据包大小比较敏感。


技术实现要素：

5.针对现有技术存在的不足，本发明的目的在于提供一种物联网操作系统中基于ilink协议的云边双向数据同步方法，以此来解决上述问题。
6.为实现上述目的，本发明提供了如下技术方案：一种物联网操作系统中基于ilink协议的云边双向数据同步方法，包括如下步骤：
7.步骤一，发送方暂停服务发送同步请求至接收方；
8.步骤二，接收方接收到同步请求后，暂停服务后接收方响应同步就绪；
9.步骤三，发送方同步开始；
10.步骤四，接收方确认同步开始；
11.步骤五，发送方进入同步中状态，传输数据至接收方；
12.步骤六，接收方确认收到同步指令，开始同步，并在接收方出现同步冲突的时候，则发送同步冲突指令至发送方，发送方处理同步冲突；
13.步骤七，接收方在接收到数据后进行事务提交，从暂停服务状态恢复运行，发送方等待同步完成指令，并在接收到同步完成指令和超时后发送方同步结束；
14.步骤八，接收方响应同步成功，完成发送方和接收方同步操作；
15.其中，在同步中出现任何异常，包括发送方以及接收方，通过发送同步中断指令终止同步，发送方发送指令收到响应前不能接着发下一阶段指令，在发送方发送同步中断指令后，结束同步任务，无需等待回应，从暂停状态恢复，接收方发送同步中断指令后，直到收到同步结束指令，其他指令均回应中断，最终从暂停状态恢复，发送方收到同步中断后，停止同步，立即发送同步结束指令，从暂停状态恢复，接收方收到同步中断后，结束同步，回滚事务，从暂停状态恢复。
16.作为本发明的进一步改进，所述同步中出现的异常情况包括发送方超时未收到响应、接收方超时未收到指令、接收方收到错误期望的指令、发送方收到错误期望的响应和接收方无法处理同步任务。
17.作为本发明的进一步改进，所述发送方与接收方之间通信的基础格式包括：当前指令的类型、当前指令的唯一id、当前指令的版本、当前指令的具体内容和响应字符。
18.作为本发明的进一步改进，所述同步中断指令格式为在基础格式的基础上还包括有当前进行中的同步任务id、失败的错误码以及失败的相关提示信息。
19.作为本发明的进一步改进，所述发送方发送的同步请求指令格式为在基础格式的基础上还包括有当前进行中的同步任务id。
20.作为本发明的进一步改进，所述发送方同步中的指令格式为在基础格式的基础上还包括有本次同步实体类别名称、当前第几页、每页有多少、总共多少页、总数据量和对应同步实体的具体数据结构。
21.作为本发明的进一步改进，所述接收方的同步冲突的指令格式为在基础格式的基础上还包括有需要解决冲突的实体类别和表示哪些id的数据需要解决冲突。作为本发明的进一步改进，所述发送方发送的每一条指令都会有接收方对应的一条回应，而在发送方超过等待响应超时时间还未受到响应时，发送方进行重发，并在重发次数超过最大重发次数时则判定同步失败，判断为发送方超时未收到响应异常，发送方发送同步中断指令，而在接收方在收到最初的同步指令后，为当前同步任务开启一个定时器，在收到同步任务完成指令前，如果超过等待同步时间未收到同步指令时，则判定同步失败，判断为接收方超时未收到指令异常，接收方发送同步中断指令。
22.本发明的有益效果，通过步骤一至步骤八的设置，便可有效的实现发送方与接收方之间数据同步，而在同步中出现异常的时候，采用了发送方发送指令收到响应前不能接着发下一阶段指令的方式，可以使得发送方具有足够的处理资源，然后通过后续处理方式有效的对同步冲突进行处理，相比于现有技术中的方式，数据更不容易丢失，对于数据包大小更不会敏感。
附图说明
23.图1为本发明的物联网操作系统中基于ilink协议的云边双向数据同步方法的同步流程图。
具体实施方式
24.下面将结合附图所给出的实施例对本发明做进一步的详述。
25.术语解释：
26.ilink：ilink协议是指令集智能科技有限公司针对物联网开发领域设计的一种数据交换协议，采用json格式，用于设备端和物联网操作系统的双向通信。设备端按照规范组织数据，发送给isyscore os物联网操作系统，isyscore os可以直接处理该数据，实现设备端与isyscore os之间的数据交互。
27.云边：云指部署在公网或者私有化部署在局域网内的中心计算服务，一般拥有较大的硬件资源，拥有处理海量数据的能力，在此发明中特指isyscore os物联网操作系统；边指部署在靠近设备侧现场的边缘计算服务，用于处理设备端的数据，通常来说硬件资源受限，网路环境偶尔会出现波动，在此发明中特指指令集边缘网关。
28.双向数据同步：在物联网使用场景下，经常会遇到需要使用云边协同的能力，在中央服务器上对不同区域的边缘设备进行查看、管控、运维等，由于边缘服务通常部署在现场，这就需要通过一种方法将云端的计算规则同步给边缘服务；另外在现场有价值的数据也需要能够同步给云端，这样的一种方法就称为双向数据同步。
29.参照图1所示，本实施例的一种物联网操作系统中基于ilink协议的云边双向数据同步方法，包括如下步骤：
30.步骤一，发送方暂停服务发送同步请求至接收方；
31.步骤二，接收方接收到同步请求后，暂停服务后接收方响应同步就绪；
32.步骤三，发送方同步开始；
33.步骤四，接收方确认同步开始；
34.步骤五，发送方进入同步中状态，传输数据至接收方；
35.步骤六，接收方确认收到同步指令，开始同步，并在接收方出现同步冲突的时候，则发送同步冲突指令至发送方，发送方处理同步冲突；
36.步骤七，接收方在接收到数据后进行事务提交，从暂停服务状态恢复运行，发送方等待同步完成指令，并在接收到同步完成指令和超时后发送方同步结束；
37.步骤八，接收方响应同步成功，完成发送方和接收方同步操作；
38.其中，在同步中出现任何异常，包括发送方以及接收方，通过发送同步中断指令终止同步，发送方发送指令收到响应前不能接着发下一阶段指令，在发送方发送同步中断指令后，结束同步任务，无需等待回应，从暂停状态恢复，接收方发送同步中断指令后，直到收到同步结束指令，其他指令均回应中断，最终从暂停状态恢复，发送方收到同步中断后，停止同步，立即发送同步结束指令，从暂停状态恢复，接收方收到同步中断后，结束同步，回滚事务，从暂停状态恢复，在本实施例中，发送方和接收方既可以是云端服务也可以是边缘端服务，它们之间的角色可以互换，它们使用同一套算法来实现双向数据同步方法，唯一较大的区别是当同步的发送方是云端服务时，同步的过程不会出现冲突，因为对于边缘计算服务，它只会从一个云端服务接受指令。
39.云端服务与边缘端服务之间通过ilink协议来保证数据包传输过程中的压缩，来达到高效通信的目的，同时isyscore os操作系统还能进行消息追踪，为消息溯源提供了便利。
40.具体的本实施例的数据结构如下：
41.发送方与接收方之间通信的消息遵循以下基本格式，当消息发送时将内容以json形式进行序列化
[0042][0043]
同步中断指令同步过程中出现任何异常，包括发送方以及接收方，用这个消息终止同步
[0044][0045][0046]
发送方同步请求指令
[0047]
发送方进入暂停状态，接收方接收到数据后进入暂停状态，如果是边缘端向云端同步，边缘端需要通过ilink协议，fetch_sync_id先向云端获取同步id，由云端保证id唯一性，如果是云端向边缘端同步，则不需要这一步
[0048][0049]
接收方响应同步就绪指令
[0050]
当前无法处理同步，则响应同步中断，operateid与sync_ask对应
[0051][0052]
发送方同步开始指令
[0053]
data包含需同步的实体类及数量，接收方收到后开始事务
[0054][0055]
接收方确认同步开始指令
[0056][0057]
发送方同步中指令
[0058]
需要注意控制报文体大小和依赖关系，每次只能发一种类型的数据，current、size、pages、total为辅助理解分片过程的字段
[0059]
[0060][0061]
接收方确认收到同步消息指令operateid与对应sync_ing相同，或者与sync_confirm相同
[0062][0063]
接收方同步冲突指令
[0064]
operateid与对应sync_ing相同，冲突发生的逻辑是，实体类对应业务id已存在
[0065][0066]
发送方处理同步冲突指令
[0067]
operateid与对应sync_conflict相同(也就与最初的sync_ing相同了，即冲突处理全流程operateid不变)，用户选择修改业务id还是覆盖，如果需要中断回滚，则发送方发送中断消息，override集合内的是需要覆盖的，update内key为原来的主键，value为需要修改成的新主键；响应后如果还有冲突，重复sync_conflict与sync_confirm过程
[0068][0069]
发送方同步结束指令
[0070]
接收方在接收到数据后进行事务提交，从暂停状态恢复运行，发送方等待sync_ok，超时后结束
[0071][0072]
接收方响应同步成功指令
[0073]
operateid与sync_end对应，如果数量对不上则接收方回滚并发送同步中断，syncid与最初的sync_ask对应
[0074][0075]
规则
[0076]
一.发送方必须顺序发送指令
[0077]
发送方发送指令收到响应前不能接着发下一阶段指令
[0078]
二.发送方发送同步中断后
[0079]
结束同步任务，无需等待回应，从暂停状态恢复
[0080]
三.接收方发送同步中断后
[0081]
直到收到sync_end指令，其他消息均回应中断，最终从暂停状态恢复
[0082]
四.发送方收到同步中断后
[0083]
停止同步，立即发送sync_end，从暂停状态恢复
[0084]
五.接收方收到同步中断后
[0085]
结束同步，回滚事务，从暂停状态恢复
[0086]
异常处理
[0087]
发送方超时未收到响应异常
[0088]
发送方发送的每一条指令都会有接收方对应的一条回应，它们的operateid相同，其对应关系如下所示
[0089]
指令响应sync_asksync_readysync_startsync_acksync_ingsync_recv或sync_conflictsync_confirmsync_recvsync_endsync_ok
[0090]
由于规则一，如果超过ack_timeout(等待响应超时时间)还未收到响应，则发送方进行重发，重试次数如果超过max_retry(最大重试次数)则判定同步失败，发送方发送同步中断指令。
[0091]
由于存在重发机制，对接收方来说每次可能会遇到三种情况，第一种是下一阶段
的指令，也就是正常的流程；第二种是当前阶段的指令，也就是重发的流程，因此接收方需要临时保存当前阶段的operateid以便比较；第三种是同步中断的指令，发送方主动终止了同步流程。
[0092]
接收方超时未收到指令异常
[0093]
接收方在收到sync_ask指令，即最初的同步指令后，就会为当前同步任务开启一个定时器，在收到sync_end前，即同步任务完成前，如果超过sync_timeout未收到同步指令，则判定同步失败，接收方发送同步中断指令。sync_timeout理论上应大于发送方配置的ack_timeout*max_retry。如遇其他指令，重置定时器。
[0094]
其中如果接收方遇到冲突需要用户手动决定如何处理，即回应了sync_conflict后，应当将定时器延长至一个较长的值，让用户有充足时间处理，用户处理完成，即接收方发送sync_confirm指令后重置并恢复定时器。
[0095]
由于需要用户处理冲突的情形目前只存在与边缘端向云端发起同步，因此等待云端用户处理的过程中，如果边缘端崩溃或其他原因中断了连接，云端能够感知到边缘端离线，就可以中断同步任务了。
[0096]
接收方收到错误期望的指令异常
[0097]
由于规则一的存在，理论上不会出现这种情况，它只会遇到6.4.1列举的三种情况，如果遇到了，接收方无法正常处理，所以直接丢弃即可。
[0098]
这种异常更大概率出现在云端，因为云端可能会同时处理多个同步任务，那么可能在逻辑处理时，不同边缘端的指令分配“错位”了，那么丢弃了的话，边缘端超时未收到响应重发即可。
[0099]
发送方收到错误期望的响应异常
[0100]
这里说的错误期望，主要指的是响应的operateid与当前发出去指令的operateid对应不上，发送方需要消耗重试次数进行当前指令的重发。
[0101]
由于是接收方发来的响应，所以不能直接丢弃，必须得处理，不然接收方超时终止同步任务了，所以如果是operate对不上，也需要进行重发。
[0102]
接收方无法处理同步任务异常
[0103]
对应sync_ready，可以开始同步的对立情况，这种场景应该比较少见，边缘端如果正在进行固件更新等情况的话会无法处理同步任务，那么接收方需要发送同步中断指令，终止同步。
[0104]
综上所述，本实施例的物联网操作系统中基于ilink协议的云边双向数据同步方法，在数据同步的过程中，可实现对于同步冲突的处理，能够有效的解决现有技术中所存在的数据容易丢失，且对于数据包大小比较敏感的问题。
[0105]
以上所述仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

技术特征：
1.一种物联网操作系统中基于ilink协议的云边双向数据同步方法，其特征在于：包括如下步骤：步骤一，发送方暂停服务发送同步请求至接收方；步骤二，接收方接收到同步请求后，暂停服务后接收方响应同步就绪；步骤三，发送方同步开始；步骤四，接收方确认同步开始；步骤五，发送方进入同步中状态，传输数据至接收方；步骤六，接收方确认收到同步指令，开始同步，并在接收方出现同步冲突的时候，则发送同步冲突指令至发送方，发送方处理同步冲突；步骤七，接收方在接收到数据后进行事务提交，从暂停服务状态恢复运行，发送方等待同步完成指令，并在接收到同步完成指令和超时后发送方同步结束；步骤八，接收方响应同步成功，完成发送方和接收方同步操作；其中，在同步中出现任何异常，包括发送方以及接收方，通过发送同步中断指令终止同步，发送方发送指令收到响应前不能接着发下一阶段指令，在发送方发送同步中断指令后，结束同步任务，无需等待回应，从暂停状态恢复，接收方发送同步中断指令后，直到收到同步结束指令，其他指令均回应中断，最终从暂停状态恢复，发送方收到同步中断后，停止同步，立即发送同步结束指令，从暂停状态恢复，接收方收到同步中断后，结束同步，回滚事务，从暂停状态恢复。2.根据权利要求1所述的物联网操作系统中基于ilink协议的云边双向数据同步方法，其特征在于：所述同步中出现的异常情况包括发送方超时未收到响应、接收方超时未收到指令、接收方收到错误期望的指令、发送方收到错误期望的响应和接收方无法处理同步任务。3.根据权利要求2所述的物联网操作系统中基于ilink协议的云边双向数据同步方法，其特征在于：所述发送方与接收方之间通信的基础格式包括：当前指令的类型、当前指令的唯一id、当前指令的版本、当前指令的具体内容和响应字符。4.根据权利要求3所述的物联网操作系统中基于ilink协议的云边双向数据同步方法，其特征在于：所述同步中断指令格式为在基础格式的基础上还包括有当前进行中的同步任务id、失败的错误码以及失败的相关提示信息。5.根据权利要求3所述的物联网操作系统中基于ilink协议的云边双向数据同步方法，其特征在于：所述发送方发送的同步请求指令格式为在基础格式的基础上还包括有当前进行中的同步任务id。6.根据权利要求3所述的物联网操作系统中基于ilink协议的云边双向数据同步方法，其特征在于：所述发送方同步中的指令格式为在基础格式的基础上还包括有本次同步实体类别名称、当前第几页、每页有多少、总共多少页、总数据量和对应同步实体的具体数据结构。7.根据权利要求3所述的物联网操作系统中基于ilink协议的云边双向数据同步方法，其特征在于：所述接收方的同步冲突的指令格式为在基础格式的基础上还包括有需要解决冲突的实体类别和表示哪些id的数据需要解决冲突。8.根据权利要求2所述的物联网操作系统中基于ilink协议的云边双向数据同步方法，
其特征在于：所述发送方发送的每一条指令都会有接收方对应的一条回应，而在发送方超过等待响应超时时间还未受到响应时，发送方进行重发，并在重发次数超过最大重发次数时则判定同步失败，判断为发送方超时未收到响应异常，发送方发送同步中断指令，而在接收方在收到最初的同步指令后，为当前同步任务开启一个定时器，在收到同步任务完成指令前，如果超过等待同步时间未收到同步指令时，则判定同步失败，判断为接收方超时未收到指令异常，接收方发送同步中断指令。

技术总结
本发明公开了一种物联网操作系统中基于iLink协议的云边双向数据同步方法，包括如下步骤：步骤一，发送方暂停服务发送同步请求至接收方；步骤二，接收方接收到同步请求后；步骤三，发送方同步开始；步骤四，接收方确认同步开始；步骤五，发送方进入同步中状态；步骤六，接收方确认收到同步指令；步骤七，接收方在接收到数据后进行事务提交；步骤八，接收方响应同步成功，完成发送方和接收方同步操作。本发明的数据同步方法，通过步骤一至步骤八的设置，便可有效的实现发送方与接收方之间数据同步，并且能够有效的对同步冲突进行处理操作。并且能够有效的对同步冲突进行处理操作。并且能够有效的对同步冲突进行处理操作。


技术研发人员：周垤飞 陈波 宋杨 秦钢 许飞 韩鹏
受保护的技术使用者：杭州指令集智能科技有限公司
技术研发日：2023.01.31
技术公布日：2023/9/25