一种保证分布式系统中数据强一致性的方法与流程

1.本发明属于证券交易技术领域，具体涉及一种保证分布式系统中数据强一致性的方法。


背景技术：

2.在证券、期货、机构交易等多条产品线中得到成功应用。但随着金融市场交易品种、成交量的飞速增长，对交易系统的性能和容量提出了更高的要求。而原有交易系统存在诸多方面的限制，使得在现有版本基础上改进及提高显得十分困难，进而提出了对新一代交易系统的要求。
3.例如，原有交易系统并不是完全意义上的分布式架构，业务集群仅支持简单的主备模型，而且主备切换机制本身由单个仲裁进程控制。
4.这本身就意味着单点失败的可能。主备模型本身行之有效，但是除本地主备之外，无法支持异地备份之类的水平扩展方式。为了增强交易系统的水平扩展能力和健壮性。本发明在业务数据的分发方式和业务集群同步方式上有所创新，以满足未来客户对交易速度、健壮性和扩展能力等核心需求，目前存在两个问题如下：
5.(1)单个业务集群仅由3个节点组成：主节点/备节点/仲裁节点。主节点从原有消息中间件接收负责进行业务处理并对外分发处理后的业务数据，备节点也从原有的消息中间件接收进行业务处理但不向外分发业务数据。仲裁节点与主备节点间皆有心跳连接，若检测到主节点失败，备节点将接到来自仲裁节点的通知，将身份由备节点切换为主节点。切换完成后新主节点负责向外分发处理后的数据。上述方案的缺陷在于仲裁节点本身仅运行一个进程，作为事实上的单点并未带来分布式系统的可靠性。当仲裁节点失败，也就意味着主备节点切换功能不可用，在主节点故障无法提供交易服务时是个集群实际上是失效的，业务稳定性和可靠性表现不佳。
6.(2)业务集群仅有主备两个节点，水平扩展能力受限，如客户要求增加交易节点并保持数据一致性、随时进行灾备切换，显然该架构不能满足客户对容错能力的进一步需求。


技术实现要素：

7.本发明的目的在于提供一种保证分布式系统中数据强一致性的方法，在本发明所描述的交易系统中，业务集群任何时候均存在一个称为主节点的逻辑角色，该角色负责分发定序消息至备节点和向外发送响应，此时主节点视为潜在的单点失败。为了保证交易系统的可靠性和健壮性，需要一个方法保证在主节点故障的情况下，能够迅速另行选出新的主节点继续负责消息处理的问题。
8.本发明的技术方案是：
9.本发明提供了一种保证分布式系统中数据强一致性的方法，包括如下步骤：
10.1)引入udp组播，使得源业务主节点向目标业务集群发送数据时向预设的组播地址上发送数据，且每个udp消息头部加上应用层帧号；
11.2)目标业务集群主节点信息为一个写入etc的租约，其过期时间很短且小于2秒，需要主节点定时更新以保证在etcd中始终存在这一租约，所有备节点均待租约状态；
12.3)当主节点故障，租约到期后被etcd删除，备节点均可得到主节点故障的通知；此时业务集群不向外提供服务；
13.4)在获知目标业务集群当前无主节点后，多个备节点均开始选举流程；
14.5)由多个备节点选出一个节点为主节点，将接手业务消息的定序和处理工作，业务集群转入可用状态。
15.进一步地，所述业务集群中节点数为x个，且x＝2n 1。
16.进一步地，租约过期时间与备节点接收到主节点故障通知到重新选主完成为止的时间值小于5秒。
17.更进一步地，在步骤5中，当所有备节点认可后正式晋升为主节点，而所有认可前者的节点转为备节点。
18.进一步地，当所有其它节点认可后正式晋升为主节点，而所有认可前者的节点转为备节点。
19.进一步地，节点启动后从etcd集群获知当前已有业务集群存在，则转入加入流程，需要向主节点发起请求要求加入集群。当业务集群就绪后即可接收消息；如某节点在集群开始处理业务消息后要求加入集群，则被拒绝。
20.更进一步地，每一种业务消息均在报文头中包含传输层序号，该序号是一个单调递增的整数；且报文生成后源业务集群中的主节点将报文发送至事先约定的组播地址；每种业务消息定义为一个单向流，每个流的接收组播地址必须不同。
21.本发明还提供了一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述方法的步骤。
22.与现有技术的有益效果是
23.1.考虑金融交易系统对处理主机健壮性要求极高，设计了一个任何时刻均保证数据强一致性的方案，该方案牺牲了cap理论中的可用性，但满足一致性和分区容错性要求，在主备切换时会出现服务不可用问题，但通过可靠组播机制加以弥补；
24.2.在水平扩展需求方面，引入etcd作为主节点选举工具，实现了竞争选主机制，极大提高业务集群的健壮性；
25.3.业务数据分发速度方面，采用无连接的可靠组播取代原有tcp点对点传输方式，摒弃了中间转发节点，数据传输速度有了极大的飞跃，同时也明显增加了业务集群所能容纳的节点数量。
附图说明
26.图1为本实施例提供的工作流程图。
实施例
27.下面结合实施例对本发明的具体实施方式进行描述，以便更好的理解本发明。
28.如图1所示，本实施例提供了一种保证分布式系统中数据强一致性的方法，具体包括如下步骤：
29.可靠组播引入udp报文
30.可靠组播的实现方式以udp报文头中携带的传输层序号为基础，每个业务流的序号均从1开始。接收组播组播时解析每个业务消息头的序号，此时有3种情况：
31.新序号为上次接收的消息序号 1，接收正常可以解析，并更新自身持有的该业务流消息序号。
32.新序号与上次接收的消息序号差值大于1，说明发生了udp消息丢失。udp消息丢失后，接收方需要向已知的消息发送方组播地址发送一个控制面的请求消息，该消息含有缺失的所有序号，要求后者补发丢失的消息。等待补发的业务消息期间，接收方缓存接收到的后续业务消息，接收到源业务节点补发的业务消息后与已经缓存的业务消息一并解析处理。
33.新序号小于上次接收的消息序号，说明该业务消息已被接收，并被网络不适当的复制并产生了传输延迟，应丢弃。
34.在实际应用中，使用可靠组播的通信双方应定义两类流：业务流和控制流，业务流可以是单向的，但控制流应成对配置，它们都使用各自的组播组地址。
35.业务流用于承载某种类型的业务消息及该业务最大序号通知消息：
36.1)发送方业务流：组播地址为224.0.1.0:23022，接收方应加入此组播地址，其它发送业务流也可定义自身的组播地址；
37.2)接收方响应流：组播地址为224.0.2.0:23022，发送方应加入此组播地址用于接收前者的响应。
38.发送方控制流用于承载补齐消息的特定业务流。该业务流也有自己的组播组地址，所有的业务流补齐缺失消息时都通过这条业务流发送，无论其业务类型如何。这个设计是为了在补齐消息时不干扰所有正常发送的业务流，避免造成人为的报文乱序问题。
39.1)发送方控制流：组播地址为224.0.1.0:23023，接收方应加入此组播地址接收自己要求补齐的业务消息；
40.2)接收方控制流：组播地址为224.0.2.0:23023，发送方应加入此组播地址接收前者的消息补齐请求和对已排序消息的确认。
41.本实施例的交易系统中，由于接收方有两种角色(主、备节点)，对于可靠组播目标集群中的节点处理业务消息丢失分为两种情形：
42.当目标业务集群中的节点启动后，等待一段时间，目的是等待其它节点向etcd集群上报自身信息，如时间到集群仍有半数以下(x-1)/2个未上报信息(也就是表示未上线服务)则集群无法启动；如在该时间内有半数以上节点启动，且当前无主节点，则进入选举流程，声明自身为主节点并上报至etcd集群；
43.当所有其它节点认可后正式晋升为主节点，而所有认可前者的节点转为备节点。如节点启动后从etcd集群获知当前已有业务集群存在，则转入加入流程，需要向主节点发起请求要求加入集群。当业务集群就绪后即可接收消息。如某节点在集群开始处理业务消息后要求加入集群，应被拒绝，这一做法是为了避免在生产状态下进行节点间消息同步，导致集群停止服务。
44.每一种业务消息均在报文头中包含传输层序号，该序号是一个单调递增的整数；当报文生成后源业务集群中的主节点将报文发送至事先约定的组播地址。每种业务消息称
为一个单向流，每个流的接收组播地址必须不同。
45.目标集群中的所有节点(接收方)都应加入所有感兴趣的组播组，以接收源业务集群的消息流。它们均应事先配置源集群信息以获得它预定义的业务消息流id和其组播地址。反之，如果源业务集群需要接收目标业务集群的响应，也应加入后者的相关组播组。
46.源业务集群开始发送业务消息后，将已发送的每个业务消息保存至内部发送数据缓存。
47.目标集群中所有节点都从指定组播地址接收业务消息，但只有主节点接收并保存至内部接收数据缓存，随后进行排队定序；备节点接收并保存至内部消息缓存但不处理，并在一定时间后丢弃。该时间与主节点切换时间等长，用于在选主期间保存来自源业务集群的消息以防丢失。随后主节点向本集群内部组播地址发送所有已定序业务消息，随后等待来自其它备节点的确认响应。收集确认响应的目的是保证目标集群内所有节点均已接收到此消息并等待进行处理。
48.对于某个备节点而言，接收到已定序业务消息后，需要向主节点发出确认响应。与此同时，它也需要接收除自己外其它备节点的响应。对主节点而言，响应消息数与在线备节点数相同；对备节点而言，响应消息数为备节点个数-1。
49.当所有节点均接收到确认响应后，说明目标集群内其它节点均接收到了当前消息，主、备节点同时将已确认的所有消息一次性提交至应用程序进行处理。但只有主节点可以从应用程序接收并向外发出该消息的响应，如果是备节点不需要向外发出该消息的响应。也就是说，外部接收者(包括源业务集群)只能接收到来自主节点的消息响应。
50.通过主节点分发业务消息的方式，保证了消息接收的全局一致性和处理结果的全局唯一性。在所有在线节点内部处理顺序一致的前提下，应用程序的状态也能严格保持一致。任何时刻访问任一节点上的应用程序，可以获得相同的处理结果，从而实现了分布式系统的强一致性。
51.主节点检测到业务消息丢失：
52.它向源业务集群发送消息补齐请求，源业务集群主节点接收到后应从已发送的业务消息中根据对方请求的序号检索出其所需的若干个，并向双方约定的专用于补齐消息流的组播地址发送。维持处理简洁起见，主节点不修改报文格式。目的业务集群主节点接收到之后可以合并入内部消息缓存，再次排序后提交给应用程序进行处理。在实际生产过程中，由于金融交易消息流量极大，单个节点在内存中保存所有已发送的业务消息不太可行。而且1》在绝大多数情况下，局域网中的udp组播是较为稳定可靠的，报文乱序和丢失极少发生；2》消息接收方检测到消息丢失后也能很快发起补齐请求，因此已发送消息保存一分钟(该时间值可设置)后删除，以节约内存空间。
53.备节点检测到业务消息丢失：
54.备节点只能向主节点发出消息补齐请求，在接收到所需消息之前它停止向主节点发出对已排序消息的确认。此时主节点由于未接到所有备节点的消息确认，也将停止向所有备节点发送已排序业务消息，但是仍然继续接收并排序来自源集群的业务消息。当备节点接收到缺失的业务消息之后向主节点发出确认，随后主节点继续向本集群广播已排序业务消息。
55.可靠组播在本发明所涉及的交易系统中，用于满足目标集群各节点的数据接收一
致性和各节点应用状态机同时进行处理和转换的需求，提供了分布式系统的数据强一致性保证。
56.以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围。