CN105323289A - 一种基于分布式的数据同步方法 - Google Patents

Abstract

本发明公开了一种基于分布式的数据同步方法，其在增量同步时，通过同步结果的依赖关系得到同步原因的依赖关系，并由此得到同步原因的强连通分量，然后进行同步下发；在批量同步和一致性检查时，通过同步对象冻结来保证数据状态的一致性。本方案能够有效解决主控在多核全业务处理中的数据同步问题，实现高速的分布式转发，继而使得主控CPU实现了全业务处理，实现负载均衡，并提高主控的处理能力。

Description

一种基于分布式的数据同步方法

技术领域

本发明涉及通信领域，更具体涉及一种分布式系统单板间的数据同步方法。

背景技术

目前，分布式系统普遍采用“主控集中处理，线卡全功能转发”的架构。而为了提高主控的处理能力，普遍采用多核来实现。但在多核使用上，为了功能实现上简单，使用固定核来处理特定业务，这样数据不需要共享，数据同步简单，但是会带来CPU负载不均的问题，无法充分利用多核的性能。

因此，为了提高性能，势必要求所有核处理全业务，这就需要所有核共享数据，而数据间依赖关系将提高数据同步的难度。

发明内容

针对现有主控在多核处理中因存在数据同步问题，导致主控CPU负载不均，无法充分利用多核性能的问题，本发明的目的在于提供一种数据同步方法，以此来解决主控在多核全业务处理中的数据同步问题，实现高速的分布式转发。

为了达到上述目的，本发明采用如下的技术方案：

本方案中定义说明：

Cause：同步原因，即触发同步的外部条件；

Effect：同步结果，是由同步原因产生的结果，用于保存应用模块向其他板卡同步的信息。

Object：同步对象，对应于每个应用模块的同步对象。

ObjectTree：同步对象树，由同步对象间的结构挂载关系而形成的一棵关系树。

Depend：同步结果之间的依赖关系，必须先同步被依赖的同步结果，然后再同步依赖的同步结果。

本发明提供一种基于分布式的数据同步方法，该数据同步方法在增量同步时，通过同步结果的依赖关系得到同步原因的依赖关系，并由此得到同步原因的强连通分量，然后进行同步下发；

在批量同步和一致性检查时，通过同步对象冻结来保证数据状态的一致性。

在上述数据同步方法中，在增量同步时，利用tarjan算法得到同步原因的强连通分量。

进一步的，在批量同步和一致性检查时，通过将在冻结期间修改同步对象的任务挂起，保证在冻结期间同步对象不被修改，从而保证数据状态的一致性。

进一步的，所述增量同步具体通过如下步骤实现：

1)主控创建cause结构，将causeid记录到当前任务结构中；将cause设为start状态，并将cause结构挂载到cause链表中；

2)应用模块对触发事件进行处理；

3)如果应用模块需要同步，则需要申请effect结构，并将同步结果打包到effect中；否则，执行步骤7；

4)将effect挂载到当前cause结构中，并将causeid记录到当前对象的obj结构中；

5)如果需要依赖其它对象的effect，则根据被依赖对象的obj结构中的causeid，获得到被依赖cause结构；否则，执行步骤7；

6)如果被依赖cause结构存在，则建立当前cause和被依赖cause之间的依赖关系；否则，执行步骤7；

7)如果没有后续应用模块需要处理，则清除当前任务的causeid，并将当前cause设为stop状态；否则，执行步骤2；

8)将cause链表中的所有cause标记为未访问，然后将未stop的cause以及依赖它的cause标记为已访问；

9)任选一个未访问过的cause进行深度优先所有，cause按照访问的顺序入栈；

10)当搜索返回时，如果当前cause是强连通分量的根，则当前cause与之前入栈的cause构成了一个强连通分量；

11)将强连通分量中的cause出栈，并合并成一个cause进行发送；

12)如果仍有未访问过的cause，则执行步骤9；否则，结束。

再进一步的，在上述增量同步过程中，备控/线卡只根据主控发送过来的cause，将每个effect交给对应的应用模块进行同步。

进一步的，所述批量同步具体通过如下步骤实现：

1)当备控/线卡插入后，主控主动与备控/线卡进行通信连接；

2)如果成功建立通信连接，则主控将启动定时器T1，进入freezing状态，等待正在增量同步的Cause结束，并挂起后续发起增量更新的任务；

3)如果在定时器T1超时前，正在增量同步Cause结束，则进入freezed状态，停止定时器T1，通知备控/线卡‘开始批量’，并执行步骤4；否则，执行步骤7；

4)主控将启动定时器T2，遍历同步对象树，按照同步对象依赖关系，从应用模块获取批量数据，每次将若干个同步数据下发给备控/线卡；

5)如果在定时器T2超时前，主控接收到批量确认，将停止定时器T2，并执行步骤6；否则，执行步骤7；

6)如果没有遍历完同步对象树，则将继续执行步骤4；否则，将通知备控/线卡‘批量结束’，并执行步骤7。

7)恢复被挂起的任务，并进入normal状态。

再进一步的，在上述批量同步过程中，备控/线卡的工作过程如下：

1)备控/线卡正常启动后，将启动定时器T3，并等待‘批量开始’；

2)如果在定时器T3超时前，收到主控‘批量开始’消息，则停止定时器T3，启动定时器T4，并执行步骤3；否则，将重启自身板卡；

3)如果收到批量更新，将交由应用模块进行数据更新；更新完毕后，将向主控回复批量确认消息；

4)如果在定时器T4超时前，收到‘批量结束’消息，则进入normal状态；否则，重启自身板卡。

进一步的，所述一致性检查具体通过如下步骤实现：

1)主控进入freezed状态，通知线卡‘开始检查’；

2)主控将启动定时器T5，遍历同步对象树，按照同步对象依赖关系，每次将若干同步对象的effectid打包下发给线卡；

3)如果在定时器T5超时前，主控接收到检查结果，将停止定时器T5，并记录检查结果，并执行步骤4；否则，执行步骤6；

4)如果没有遍历完同步对象树，则将继续执行步骤2；否则，通知线卡‘检查结束’，并执行步骤5；

5)根据检查结果，进行批量同步。

6)恢复被挂起的任务，并进入normal状态。

再进一步的，在上述一致性检查过程中，线卡的工作过程如下：

1)线卡收到‘开始检查’消息，启动定时器T6，等待检查数据；

2)如果在定时器T6超时前，收到了主控的检查数据，则停止定时器T6，并执行步骤3；否则，重启自身板卡；

3)根据检查数据的objid和effectid，判断数据是否一致，并回复检查结果，启动定时器T6；

4)如果收到主控的‘检查结束’消息，则开始等待批量同步；否则，执行步骤2。

通过上述方案能够有效解决主控在多核全业务处理中的数据同步问题，实现高速的分布式转发，继而使得主控CPU实现了全业务处理，实现负载均衡，并提高主控的处理能力。

附图说明

以下结合附图和具体实施方式来进一步说明本发明。

图1为单核处理事件的示意图；

图2为多核并行处理事件的示意图；

图3为本发明实例中进行增量同步过程中同步关系示意图；

图4为本发明实例中进行增量同步的流程示意图；

图5为本发明实例中进行增量同步过程中应用模块的处理流程图；

图6为本发明实例中进行增量同步过程中cause依赖流程图；

图7为本发明实例中进行增量同步过程中cause提交的流程图；

图8为本发明实例中进行批量同步时主控的工作流程图；

图9为本发明实例中进行批量同步时备控/线卡的工作流程图；

图10为本发明实例中进行一致性检查时主控的工作流程图；

图11为本发明实例中进行一致性检查时线卡的工作流程图。

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合具体图示，进一步阐述本发明。

在单核处理中，外部触发条件可以延伸出很多分支事件，分支又可再生分支，形成一个事件树，整个处理是对这棵树的遍历过程。如图1所示，cause触发了obj1产生了effect1，obj2产生了effect2，objn产生了effectn。虽然也存在同步结果的相互依赖，但是只要按照同步结果产生的顺序(即图中虚线标示)收集同步结果，并以cause为单位进行同步，就能保证同步顺序。

但是，在多核上并行处理时，由于同步结果的相互依赖，无法以cause为单位进行简单同步。如图2所示，在核0上，cause1触发obj1产生了effect1，obj2产生了effect2；同时在核1上，cause2触发obj3产生了effect3，obj4产生了effect4。如果effect2依赖于effect3，将形成cause1对cause2的单向依赖，必须等待cause2同步完，才能同步cause1；而如果effect4又依赖于effect1，将形成cause1与cause2的相互依赖，因此必须将cause1和cause2同时下发同步。

存在依赖关系的cause形成了一张有向图，可以利用tarjan算法，找出有向图中的强连通分量，即需要同时同步的cause；，而强连通分量的出栈顺序就是强连通分量的同步顺序，即cause的同步顺序。

基于上述原理，本方案在增量同步时，通过同步结果的依赖关系得到同步原因的依赖关系，并利用tarjan算法得到同步原因的强连通分量，然后进行同步下发；而在批量同步和一致性检查时，通过同步对象冻结来保证数据状态的一致性。由此来理清同步过程，清晰确定依赖关系，最终保证数据的同步顺序。

以下来具体的说明数据同步的过程，数据同步可以分为三个部分：增量同步、批量同步和一致性检查。

一、增量同步过程(如图3至7)：

主控：

1)主控创建cause结构，将causeid记录到当前任务结构中；将cause设为start状态，并将cause结构挂载到cause链表中。

2)应用模块对触发事件进行处理。

3)如果应用模块需要同步，则需要申请effect结构，并将同步结果打包到effect中；否则，执行步骤7。

4)将effect挂载到当前cause结构中，并将causeid记录到当前对象的obj结构中。

5)如果需要依赖其他对象的effect，则根据被依赖对象的obj结构中的causeid，获得到被依赖cause结构；否则，执行步骤7。

6)如果被依赖cause结构存在，则建立当前cause和被依赖cause之间的依赖关系；否则，执行步骤7。

7)如果没有后续应用模块需要处理，则清除当前任务的causeid，并将当前cause设为stop状态；否则，执行步骤2。

8)将cause链表中的所有cause标记为未访问，然后将未stop的cause以及依赖它的cause标记为已访问。

9)任选一个未访问过的cause进行深度优先所有，cause按照访问的顺序入栈。

10)当搜索返回时，如果当前cause是强连通分量的根，则当前cause与之前入栈的cause构成了一个强连通分量。

11)将强连通分量中的cause出栈，并合并成一个cause进行发送。

12)如果仍有未访问过的cause，则执行步骤9；否则，结束。

备控/线卡：

在整个增量同步过程中，备控/线卡只需要根据主控发送过来的cause，将每个effect交给对应的应用模块进行同步，而无需关心具体的同步顺序。

二、批量同步过程(参见图8和图9)：

为了保证批量同步期间，同步对象的状态的一致性。如果采用保存同步对象副本的方式，将消耗很大的内存；因此，本方案中采取冻结同步对象的方式。由于只允许在主控上修改同步对象，通过将主控上修改同步对象的任务挂起，保证在冻结期间同步对象不被修改，从而保证数据状态的一致性。

其中主控的过程如下(参见图8)：

1)当备控/线卡插入后，主控主动备控/线卡进行通信连接。

2)如果成功建立通信连接，则主控将启动T1定时器，进入freezing状态，等待正在增量同步的Cause结束，并挂起后续发起增量更新的任务。

3)如果在T1定时器超时前，正在增量同步Cause结束，则进入freezed状态，停止T1定时器，通知备控/线卡‘开始批量’，并执行步骤4；否则，执行步骤7。

4)主控将启动定时器T2，遍历同步对象树，按照同步对象依赖关系，从应用模块获取批量数据，每次将若干个同步数据下发给备控/线卡。

5)如果在T2定时器超时前，主控接收到批量确认，将停止T2定时器，并执行步骤6；否则，执行步骤7。

6)如果没有遍历完同步对象树，则将继续执行步骤4；否则，将通知备控/线卡‘批量结束’，并执行步骤7。

7)恢复在冻结期间被挂起的任务，主控进入normal状态。

备控/线卡的过程如下(参见图9)：

1)备控/线卡正常启动后，将启动T3定时器，并等待‘批量开始’。

2)如果在T3定时器超时前，收到主控‘批量开始’消息，则停止T3定时器，启动T4定时器，并执行步骤3；否则，将重启自身板卡。

3)如果收到批量更新，将交由应用模块进行数据更新；更新完毕后，将向主控回复批量确认消息。

4)如果在T4定时器超时前，收到‘批量结束’消息，则进入normal状态；否则，重启自身板卡。

三、一致性检查

在主备倒换时，新的主控需要和线卡进行一致性检查，需要保证数据的一致性。同样，为了保证主控和线卡上同步对象状态的一致，需要冻结同步对象。

其中新主控的过程如下(参见图10)：

1)主控进入freezed状态，通知线卡‘开始检查’，并挂起在冻结期间发起增量更新的任务。

2)主控将启动定时器T5，遍历同步对象树，按照同步对象依赖关系，每次将若干同步对象的effectid打包下发给线卡。

3)如果在T5定时器超时前，主控接收到检查结果，将停止T5定时器，并记录检查结果，并执行步骤4；否则，执行步骤6。

4)如果没有遍历完同步对象树，则将继续执行步骤2；否则，通知线卡‘检查结束’，并执行步骤5。

5)根据检查结果，进行批量同步。

6)恢复在冻结期间被挂起的任务，主控进入normal状态。

线卡的过程如下(参见图11)：

1)线卡收到‘开始检查’消息，进入freezed状态，启动T6定时器，等待检查数据。

2)如果在T6定时器超时前，收到了主控的检查数据，则停止T6定时器，并执行步骤3；否则，重启自身板卡。

3)根据检查数据的objid和effectid，判断数据是否一致，并回复检查结果，启动定时器T6。

4)如果收到主控的‘检查结束’消息，则开始等待批量同步；否则，执行步骤2。

以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (9)

1.一种基于分布式的数据同步方法，其特征在于，所述数据同步方法在增量同步时，通过同步结果的依赖关系得到同步原因的依赖关系，并由此得到同步原因的强连通分量，然后进行同步下发；

在批量同步和一致性检查时，通过同步对象冻结来保证数据状态的一致性。

2.根据权利要求1所述的一种基于分布式的数据同步方法，其特征在于，在增量同步时，利用tarjan算法得到同步原因的强连通分量。

3.根据权利要求1所述的一种基于分布式的数据同步方法，其特征在于，在批量同步和一致性检查时，通过将在冻结期间修改同步对象的任务挂起，保证在冻结期间同步对象不被修改，从而保证数据状态的一致性。

4.根据权利要求1至3中任一项所述的一种基于分布式的数据同步方法，其特征在于，所述增量同步具体通过如下步骤实现：

1)主控创建cause结构，将causeid记录到当前任务结构中；将cause设为start状态，并将cause结构挂载到cause链表中；

2)应用模块对触发事件进行处理；

3)如果应用模块需要同步，则需要申请effect结构，并将同步结果打包到effect中；否则，执行步骤7；

4)将effect挂载到当前cause结构中，并将causeid记录到当前对象的obj结构中；

5)如果需要依赖其它对象的effect，则根据被依赖对象的obj结构中的causeid，获得到被依赖cause结构；否则，执行步骤7；

6)如果被依赖cause结构存在，则建立当前cause和被依赖cause之间的依赖关系；否则，执行步骤7；

7)如果没有后续应用模块需要处理，则清除当前任务的causeid，并将当前cause设为stop状态；否则，执行步骤2；

8)将cause链表中的所有cause标记为未访问，然后将未stop的cause以及依赖它的cause标记为已访问；

9)任选一个未访问过的cause进行深度优先所有，cause按照访问的顺序入栈；

10)当搜索返回时，如果当前cause是强连通分量的根，则当前cause与之前入栈的cause构成了一个强连通分量；

11)将强连通分量中的cause出栈，并合并成一个cause进行发送；

12)如果仍有未访问过的cause，则执行步骤9；否则，结束。

5.根据权利要求4所述的一种基于分布式的数据同步方法，其特征在于，在上述增量同步过程中，备控/线卡根据主控发送过来的cause，将每个effect交给对应的应用模块进行同步。

6.根据权利要求1至3中任一项所述的一种基于分布式的数据同步方法，其特征在于，所述批量同步具体通过如下步骤实现：

1)当备控/线卡插入后，主控主动与备控/线卡进行通信连接；

2)如果成功建立通信连接，则主控将启动定时器T1，进入freezing状态，等待正在增量同步的Cause结束，并挂起后续发起增量更新的任务；

3)如果在定时器T1超时前，正在增量同步Cause结束，则进入freezed状态，停止定时器T1，通知备控/线卡‘开始批量’，并执行步骤4；否则，执行步骤7；

4)主控将启动定时器T2，遍历同步对象树，按照同步对象依赖关系，从应用模块获取批量数据，每次将若干个同步数据下发给备控/线卡；

5)如果在定时器T2超时前，主控接收到批量确认，将停止定时器T2，并执行步骤6；否则，执行步骤7；

6)如果没有遍历完同步对象树，则将继续执行步骤4；否则，将通知备控/线卡‘批量结束’，执行步骤7。

7)恢复被挂起的任务，并进入normal状态。

7.根据权利要求6所述的一种基于分布式的数据同步方法，其特征在于，在上述批量同步过程中，备控/线卡的工作过程如下：

1)备控/线卡正常启动后，将启动定时器T3，并等待‘批量开始’；

2)如果在定时器T3超时前，收到主控‘批量开始’消息，则停止定时器T3，启动定时器T4，并执行步骤3；否则，将重启自身板卡；

3)如果收到批量更新，将交由应用模块进行数据更新；更新完毕后，将向主控回复批量确认消息；

4)如果在定时器T4超时前，收到‘批量结束’消息，则进入normal状态；否则，重启自身板卡。

8.根据权利要求1至3中任一项所述的一种基于分布式的数据同步方法，其特征在于，所述一致性检查具体通过如下步骤实现：

1)主控进入freezed状态，通知线卡‘开始检查’,并挂起在冻结期间发起增量更新的任务；

2)主控将启动定时器T5，遍历同步对象树，按照同步对象依赖关系，每次将若干同步对象的effectid打包下发给线卡；

3)如果在定时器T5超时前，主控接收到检查结果，将停止定时器T5，并记录检查结果，并执行步骤4；否则，执行步骤6；

4)如果没有遍历完同步对象树，则将继续执行步骤2；否则，通知线卡‘检查结束’，并执行步骤5；

5)根据检查结果，进行批量同步。

6)恢复被挂起的任务，并进入normal状态。

9.根据权利要求8所述的一种基于分布式的数据同步方法，其特征在于，在上述一致性检查过程中，线卡的工作过程如下：

1)线卡收到‘开始检查’消息，启动定时器T6，等待检查数据；

2)如果在定时器T6超时前，收到了主控的检查数据，则停止定时器T6，并执行步骤3；否则，重启自身板卡；

3)根据检查数据的objid和effectid，判断数据是否一致，并回复检查结果，启动定时器T6；

4)如果收到主控的‘检查结束’消息，则开始等待批量同步；否则，执行步骤2。