CN103647669A - 一种保证分布式数据处理一致性的系统及方法 - Google Patents

Abstract

本发明涉及分布式数据处理技术领域，具体是一种保证分布式数据处理一致性的系统及方法，包括计算机交易系统平台，所述的计算机交易系统平台由若干台负责交易业务处理的交易平台组成，交易主机内部会将一台主机作为主节点，其他节点则成为交易备机，主节点负责所有订单的处理任务，并负责日志记录和维护、触发从节点的基础数据同步，从节点并不进行实时订单处理，但通过同步维护基础数据内存与主节点一致。本发明专利同现有技术相比，其优点在于：采用带有消息执行状态的日志结构，解决了交易系统基础数据的实时读取和更新的时延冲突，降低了交易系统重演的复杂程度，提高了数据在平台间处理和主备机切换时的一致性及系统性能和可靠度。

Description

一种保证分布式数据处理一致性的系统及方法

[技术领域]

本发明涉及分布式数据处理技术领域，具体是一种保证分布式数据处理一致性的系统及方法。

[背景技术]

对于要求高可靠性和实时性的交易系统来说，良好的数据处理方式设计与实现具有重要意义，其中分布式系统中的数据一致性策略历来是数据系统设计中最为复杂的问题，如高度并行带来的问题、本机内多任务并行带来的困难、多机并行带来的困难、网络延迟不可预测、系统中存在多个副本、数据的修改通常会在不同的副本上进行等，而一种设计往往只能解决上面的几个问题而不可能全部覆盖。

目前的分布式系统中用于保证数据一致性的方式有基于锁机制、采用中间件或者使用WS Transaction标准等，但是这些实现都存在一定的不足，如基于锁的机制往往影响了系统的并发处理的实时性，中间件方式则大多需要额外的硬件承载且不能保证高可靠性，WS Transaction标准实现成本较高。此外，分布式系统中大多采用了日志机制来保证系统重演的数据处理结果正确，日志记录往往是在数据处理完成后落地结果，如果在数据处理后异常导致日志记录未完成，那么系统重演时会出现与预期结果不一致。

中国专利号为98101433.X的中国专利公开了一种保证交易一致性的方法，在联机事务处理系统中通过核对和重复提交/撤销来保证数据处理一致性的方法，该发明只有在网络短时故障时引起的传输数据丢失时保证数据处理一致性，并不能解决计算机出现的问题导致数据处理一致性的问题。

[发明内容]

本发明的目的在于解决现有的交易系统中分布式数据处理存在的一致性问题及采用日志机制时数据处理异常导致日志记录未完成导致的系统重演时会出现与预期结果不一致的技术问题，设计一套结合新型的基础数据内存组织结构，完整的用于保证交易系统基础数据处理一致性的机制。

为了实现上述目的，提供一种保证分布式数据处理一致性的系统,包括计算机交易系统平台，所述的计算机交易系统平台由若干台负责交易业务处理的交易平台组成，交易主机内部会将一台主机作为主节点，其他节点则成为交易备机，主节点负责所有订单的处理任务，并负责日志记录和维护、触发从节点的基础数据同步，从节点并不进行实时订单处理，但是能够通过同步维护基础数据内存与主节点一致，所述的主机内设有同步路由器，同步路由器从订单生成软件、前台数据管理软件或其它平台分别获取订单消息和基础数据更新消息，同步路由器分别连接若干应用进程和共享消息队列，所述的若干应用进程分别连接基础数据内存和订单簿内存，所述的共享消息队列连接基础数据管理模块，所述的基础数据管理模块连接基础数据内存；所述的基础数据内存支持一写多读，并支持写操作的撤销指令，所述的基础数据管理模块在处理基础数据日志中增加了日志记录的执行状态信息和索引支持动态定位，数据处理请求到达时将原始请求消息落地日志记录，并在数据处理完毕后更新日志记录中的执行状态信息和执行结果。

所述的若干应用进程通过应用log（日志）连接备机，所述的基础数据管理模块通过数据管理log（日志）连接备机，主机内还设有平台间消息同步通信模块，交易集群中其他平台通过平台间消息同步通信模块连接共享队列。

所述的基础数据内存包括若干条记录，记录头部结构中除了索引用的KEY（密码）值外，还增加了TAG（标签）字段，用于记录当前版本号，TAG（标签）字段的读取和写入皆为原子操作，不产生冲突，基础数据内存支持一写多读，并支持写操作的撤销指令，在基础数据管理模块更新基础数据记录的同时，应用程序的读取操作不受影响。

所述的基础数据管理模块处理的请求包括基础数据变更和基础数据查询消息，请求来源于与同步路由器之间的共享消息队列，基础数据管理模块维护了一个本地消息队列，用于存放从共享消息队列中分拣出的基础数据管理模块消息。

所述的基础数据管理模块在处理基础数据查询请求时不涉及日志操作，基础数据管理模块从共享消息队列中读取出原始请求，放入本地TASK(任务)消息队列中，基础数据管理模块顺序读取本地队列，并进行消息类型判断和有效性校验，基础数据管理模块在查询基础数据内存获得结果后，格式化响应消息，并将响应消息发送至共享消息队列，由同步路由将结果送达前台软件，最后基础数据管理模块根据TASKID(任务验证)将本地队列中的TASK(任务)消息设为处理完毕，即从本地队列中删除，至此，基础数据管理模块完成基础数据查询请求的处理。

所述的基础数据管理模块在处理基础数据变更请求时使用了基础数据日志机制，基础数据管理模块对于基础数据修改请求的TASK(任务)，将分为二阶段进行处理，在第一阶段，基础数据管理模块从共享消息队列获取基础数据更新请求消息，将原始请求落地ORIGINAL_LOG(原始日志)记录并更新RESULT_LOG(结果日志)记录的状态为“执行中”，之后基础数据管理模块生成本地消息队列TASK(任务)消息，并将消息发送到本地消息队列中，等待被处理，第二阶段，基础数据管理模块从本地消息队列中读取出TASK(任务)消息，判断是否为基础数据更新消息类型，然后由TASK（任务）消息记录的原始请求地址读取出ORIGINAL_LOG(原始日志)中原始消息记录，在完成内存更新前，要对原始请求进行有效性验证，内存更新完成后，将本地消息队列中TASK(任务)消息状态设为执行成功，最终基础数据管理模块生成处理结果消息并进行格式转换，发送到共享消息队列，并更新到RESULT_LOG(结果日志)中的结果中。

一种保证分布式数据处理一致性的方法，数据处理过程中涉及的请求消息主要有订单请求和基础数据更新请求，订单消息来自订单生成软件，基础数据更新消息则由前台数据管理软件或其它平台产生，具体方法如下：

a.请求消息到达主机后，由同步路由器根据消息类别送达共享消息队列，交由相应的进程处理；

b.应用进程在订单处理过程中，首先连接到基础数据内存，再根据其中记录的信息对订单进行校验，校验成功后写入订单簿内存，并更新应用日志文件记录中的状态信息，应用进程在处理订单过程中只写一次日志；

c.数据更新请求消息经由同步路由器送达共享消息队列，触发基础数据管理模块，基础数据管理模块首先将原始请求写入基础数据日志，并完成对基础数据内存的更新后，再次更新基础数据日志中的状态消息为执行成功并落地处理结果,基础数据管理模块在处理消息过程中两次写日志,分别是被触发时和处理完毕后,改进的基础数据日志结构和两次更新日志的机制保证了基础数据变更的可靠性；

d.针对步骤b和步骤c中基础数据管理模块和应用进程存在同时读写基础数据内存的情况，基础数据内存中采用了多版本组织形式的支持基础数据管理模块和多应用进程同时读写，有效的降低了数据处理的时延；

所述的基础数据内存读取方法如下：

（1）.应用程序读取基础数据内存方法：

a.通过KEY(密码)值遍历到要读取的内存记录后，先将记录的TAG(标签)值读出；

b.根据KEY(密码)值和TAG(标签)值，定位到记录1的目前最新版本记录1.1，并将记录1.1中内容返回值应用进程；

（2）.基础数据管理模块更新基础数据内存方法：

a.通过KEY（密码）值遍历到要读取的内存记录后，先将记录的TAG（标签）值读出；

b.根据获取到的TAG（标签）值，确定记录1的目前最新版本记录1.1，根据KEY（密码）值和TAG（标签）值，将要修改的记录更新到下一版本记录1.2中，此时，由于步骤a发生在步骤c之前，所以同步进行的应用进程读取到的内存记录仍然为记录1.1；

c.更新记录的TAG（标签）值为1.2，完成数据更新操作；

在步骤c之后，应用进程此后读取的内存为记录1.2；

(3).基础数据管理模块撤销前一条指令方法：

a.通过KEY（密码）值遍历到要读取的内存记录后，先将记录的TAG（标签）值读出；

b.根据获取到的TAG（标签）值，确定记录1的目前最新版本记录1.2，更新TAG（标签）值为当前版本的上一版本号1.1，此时，由于步骤a发生在步骤b之前，所以同步进行的应用进程读取的内存记录仍然为记录1.2；

在步骤b之后，应用进程此后读取的内存为记录1.1。

所述的基础数据管理模块在处理基础数据变更请求时，需要两次更新日志记录，分别是：

a.基础数据管理模块在接收基础数据变更请求时，先将原始请求记录写入ORIGINAL_LOG（原始日志）区中，并在RESULT_LOG（结果日志）中增加新的记录，并将状态信息置为“处理中”，第一次落地日志完成；

b.基础数据管理模块在基础数据变更请求处理完毕时，根据原始请求的TASKID（任务验证）找到RESULT_LOG（结果日志）中的记录，设置执行状态值为“处理成功”，并将返回给前台的结果消息打包记入结果区，第二次日志记录完成。

所述的方法还包括HFM（基础数据管理模块）进程重演和主机重演，分别用于HFM基础数据管理模块进程FAILOVER（失效备援）和主机FAILOVER（失效备援）时的状态恢复：

（1）.HFM（基础数据管理模块）进程若发生FAILOVER（失效备援），但架构没CRASH（死机）的情况下，只需要HFM（基础数据管理模块）进程重启后重演；

重演的过程中HFM（基础数据管理模块）需要进行以下的处理：HFM（基础数据管理模块）进程将遍历日志中所有的记录来重新构建在CRASH（死机）或关闭时所发生的最新状态，通过之前落地的RESULT_LOG（结果日志）中执行状态字段可确定有哪些TASK（任务）记录仍然处于“处理中”的状态，对于“处理中”的状态的记录，则重新提交TASK（任务）消息给HFM（基础数据管理模块）本地消息队列，要求HFM（基础数据管理模块）重新执行该条指令，以便使主机能正确处理和返回前台响应消息，最终主机将RESULT_LOG（结果日志）中状态字段置为“执行成功”，备机在看到该请求后可同步进行更新操作；

对于HFM（基础数据管理模块）进程的重启，不必进行日志记录的全部重演，而只需检查RESULT_LOG（结果日志）的完备性，并提交未完成的TASK（任务）请求，减少了HFM（基础数据管理模块）进程重启后的耗时，同时也增加了可靠度,备机在HFM（基础数据管理模块）进程FAILOVER（失效备援）和重启的过程中不受影响；

（2）.主机FAILOVER（失效备援）时的HFM（基础数据管理模块）接管处理，HFM（基础数据管理模块）所在主机若发生FAILOVER（失效备援），则进行主备机切换；

主机与备机之间共享基础数据日志库,基础数据日志物理文件中一条记录在状态更新为“执行成功”时，会触发备机HFM（基础数据管理模块）同步更新基础数据内存中的内容，所以主备机切换时，除去主机已经完成内存写操作但尚未完成更新日志状态的TASK（任务），备机中的基础数据内存已经保持与主机一致；主备机切换之前，备机应用进程并不实时处理订单消息，当主备机发生切换时，备机根据应用日志中的记录进行重演，应用日志中的订单记录已经包含状态和验证信息，备机重演过程中对于状态为已经处理完毕的订单只加载，并不对订单做检验，避免了因为基础数据变更对重演的影响，主备机切换完毕，备机成为主机，接管之前主机的所有TASK（任务）；在发生切换时，原主HFM（基础数据管理模块）进程处在以下几种状态：

a.在第一阶段的基础数据管理模块获取基础数据更新请求消息并更新RESULT_LOG（结果日志）记录的状态为“执行中”的过程中主机CRASH（死机），请求尚未写入日志物理文件中,在这种情况下，备机接管后可直接进行处理，因为之前提交的所有事物已全部执行完毕，丢失的新请求可通过前台软件重传的方式重新递交；

b.在第一阶段的基础数据管理模块生成本地消息队列TASK（任务）消息等待被处理）的过程中主机CRASH（死机），新的请求已写入日志文件，但未经过第二阶段的处理，在这种情况下，在备机接管后，备机需要检查RESULT_LOG（结果日志）中状态为处理中的记录，将未完成的TASK（任务）重新提交到本地队列中执行；

c.在处理基础数据变更数据请求的第二阶段完成前主机发生CRASH（死机）,在这种情况下，新的请求已写入日志，且第二阶段的业务逻辑已被处理(内存数据也已发生更新)，但是最后TASK（任务）的状态信息仍未更新到磁盘,在备机接管后，会重新提交ORIGINAL_LOG（原始日志）中未执行完成的TASK（任务）至本地消息队列，并重新执行该业务流程，因为原主机HFM进程未完成第二次日志更新,将该TASK（任务）在RESULT_LOG（结果日志）中的执行状态信息设为“执行成功”,所以备机并未开始执行本次基础数据更新操作,所以备机更新此次TASK（任务）仍然可认为是首次更新；

d.在第二阶段的完成后发生CRASH（死机）,在这种情况下，备机直接处理后续新订单并进行主机的业务逻辑即可。

本发明专利同现有技术相比，其优点在于：采用带有消息执行状态的日志结构和数据处理过程中两次更新日志记录的机制，解决了交易系统基础数据的实时读取和更新的时延冲突，降低了交易系统重演的复杂程度，减少了耗时，提高了交易系统数据在平台间处理和主备机切换时的一致性及系统性能和可靠度，从而提高了计算机的内部运行性能；数据记录在内存中使用多版本设计，基础数据内存支持一写多读，并支持写操作的撤销指令，使应用程序的读取操作不受影响，增加了内存读写的可靠性，提高了系统的效率，将参考数据变更产生的系统时延降低到最小。

[附图说明]

图1是本发明中基础数据维护框架图；

图2是本发明中基础数据内存结构图；

图3是本发明中基础数据日志结构示意图；

图4是本发明中HFM基础数据查询请求处理流程图；

图5是本发明中HFM处理基础数据变更流程图；

图6是本发明中HFM进程重演流程图；

图中：1.共享内存  2.文件  3.消息共享列队  4.节点  5.内存访问  6.文件访问  7.逻辑数据流；

指定图1作为本发明的摘要附图。

[具体实施方式]

下面结合附图对本发明作进一步说明，这种系统的结构和原理对本专业的人来说是非常清楚的。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

在发明中有几个重要的方法是提高系统性能和可靠度、保证数据一致性的关键，分别是：

1.对顺序添加式日志进行了改进，增加了日志记录的执行状态信息和索引支持动态定位。数据处理请求到达时将原始请求消息落地日志记录，并在数据处理完毕后更新日志记录中的执行状态信息和执行结果。数据处理事务过程中两次更新日志记录，原始请求消息落地先于数据处理完成，一旦事务执行过程中因意外终止，也能保证重演时信息不丢失；日志结构增加了执行状态，使得备机在重演过程中能够根据状态信息有选择的恢复之前事务，这样使得数据处理在重演过程中一致可靠。

2.基础数据在内存中的组织形式采用了多版本设计，支持一写多读并发执行，提高了交易系统进程间读写的执行效率，有效降低了交易系统的时延。内存记录修改时将版本号的更新操作置于最后，如果内存记录修改过程中发生了业务或者技术错误，这种记录多版本的设计还可以避免写操作失败时的脏数据读取，且不需要额外的数据回滚机制。基础数据内存记录的多版本设计能够很好地支持指令撤销操作，具备可扩展性。

实施例1

如图1所示，图1是本发明中分布式交易系统中基础数据维护框架图，计算机分布式交易系统平台由若干台负责交易业务处理的交易平台组成，交易主机内部会将一台主机作为主节点，其他节点则成为交易备机，主节点负责所有订单的处理任务，并负责日志记录和维护、触发从节点的基础数据同步，从节点并不进行实时订单处理，但是能够通过同步维护基础数据内存与主节点一致，主机内设有同步路由器，同步路由器从订单生成软件、前台数据管理软件或其它平台分别获取订单消息和基础数据更新消息，同步路由器分别连接若干应用进程和共享消息队列，若干应用进程分别连接基础数据内存和订单簿内存，共享消息队列连接基础数据管理模块，基础数据管理模块连接基础数据内存；基础数据内存支持一写多读，并支持写操作的撤销指令，基础数据管理模块在处理基础数据日志中增加了日志记录的执行状态信息和索引支持动态定位，数据处理请求到达时将原始请求消息落地日志记录，并在数据处理完毕后更新日志记录中的执行状态信息和执行结果。

实施例2

基础数据内存组织形式结构图如图2所示，图中的每条记录由多个版本组成，记录头部结构中除了索引用的KEY（密码）值外，还增加了TAG（标签）字段，用于记录当前版本号，其中TAG（标签）字段为INT64类型，对于TAG（标签）字段的读取和写入皆为原子操作，不产生冲突。基础数据内存支持一写多读，并支持写操作的撤销指令，在HFM（基础数据管理模块）更新基础数据记录的同时，应用程序的读取操作不受影响。

实施例3

一种保证分布式数据处理一致性的方法，数据处理过程中涉及的请求消息主要有订单请求和基础数据更新请求，订单消息来自订单生成软件，基础数据更新消息则由前台数据管理软件或其它平台产生，具体方法如下：

a.请求消息到达主机后，由同步路由器根据消息类别送达共享消息队列，交由相应的进程处理；

b.应用进程在订单处理过程中，首先连接到基础数据内存，再根据其中记录的信息对订单进行校验，校验成功后写入订单簿内存，并更新应用日志文件记录中的状态信息，应用进程在处理订单过程中只写一次日志；

c.数据更新请求消息经由同步路由器送达共享消息队列，触发基础数据管理模块，基础数据管理模块首先将原始请求写入基础数据日志，并完成对基础数据内存的更新后，再次更新基础数据日志中的状态消息为执行成功并落地处理结果,基础数据管理模块在处理消息过程中两次写日志,分别是被触发时和处理完毕后,改进的基础数据日志结构和两次更新日志的机制保证了基础数据变更的可靠性；

d.针对步骤b和步骤c中基础数据管理模块和应用进程存在同时读写基础数据内存的情况，基础数据内存中采用了多版本组织形式的支持基础数据管理模块和多应用进程同时读写，有效的降低了数据处理的时延；

基础数据内存读取方法如下：

（1）.应用程序读取基础数据内存方法：

a.通过KEY（密码）值遍历到要读取的内存记录后，先将记录的TAG（标签）值读出；

b.根据KEY（密码）值和TAG（标签）值，定位到记录1的目前最新版本记录1.1，并将记录1.1中内容返回值应用进程；

（2）.基础数据管理模块更新基础数据内存方法：

a.通过KEY（密码）值遍历到要读取的内存记录后，先将记录的TAG（标签）值读出；

b.根据获取到的TAG（标签）值，确定记录1的目前最新版本记录1.1，根据KEY（密码）值和TAG（标签）值，将要修改的记录更新到下一版本记录1.2中，此时，由于步骤a发生在步骤c之前，所以同步进行的应用进程读取到的内存记录仍然为记录1.1；

c.更新记录的TAG（标签）值为1.2，完成数据更新操作；

在步骤c之后，应用进程此后读取的内存为记录1.2；

(3).基础数据管理模块撤销前一条指令方法：

a.通过KEY（密码）值遍历到要读取的内存记录后，先将记录的TAG值读出；

b.根据获取到的TAG（标签）值，确定记录1的目前最新版本记录1.2，更新TAG（标签）值为当前版本的上一版本号1.1，此时，由于步骤a发生在步骤b之前，所以同步进行的应用进程读取的内存记录仍然为记录1.2；

在步骤b之后，应用进程此后读取的内存为记录1.1。

基础数据管理模块在处理基础数据变更请求时，需要两次更新日志记录，分别是：

a.基础数据管理模块在接收基础数据变更请求时，先将原始请求记录写入ORIGINAL_LOG（原始日志）区中，并在RESULT_LOG（结果日志）中增加新的记录，并将状态信息置为“处理中”，第一次落地日志完成；

b.基础数据管理模块在基础数据变更请求处理完毕时，根据原始请求的TASKID（任务验证）找到RESULT_LOG（结果日志）中的记录，设置执行状态值为“处理成功”，并将返回给前台的结果消息打包记入结果区，第二次日志记录完成。

改进后的事务逻辑可靠性：在HFM（基础数据管理模块）更新完成后，应用程序读取的基础数据内存记录即为最新版本，不存在读取到脏数据的可能性。如果执行过程中出现HFM（基础数据管理模块）更新基础数据内存记录失败，那么TAG（标签）字段中的值仍为记录上一版本的值，不需要额外的数据回滚机制。

相较于普通的内存结构，本发明中的基础数据内存的多版本设计摒弃了锁的机制，使得读和写操作同时进行，提高了系统的效率，将参考数据变更产生的系统时延降低到最小，同时，增加了内存读写的可靠性，并扩展了基础数据变更的撤销指令功能。

如图3所示，基础数据日志结构分为两部分ORIGINAL_LOG（原始日志）和RESULT_LOG（结果日志），ORIGINAL_LOG（原始日志）中记录原始请求，而RESULT_LOG（结果日志）记录的是原始请求经过系统处理的状态和结果，ORIGINAL_LOG（原始日志）和RESULT_LOG（结果日志）分别作为系统的输入和输出，其中的内容可以作为系统重演的数据依据。

基础数据管理模块在处理基础数据变更请求时，需要两次更新日志记录，分别是：

a.基础数据管理模块在接收基础数据变更请求时，先将原始请求记录写入ORIGINAL_LOG（原始日志）区中，并在RESULT_LOG（结果日志）中增加新的记录，并将状态信息置为“处理中”，第一次落地日志完成；

b.基础数据管理模块在基础数据变更请求处理完毕时，根据原始请求的TASKID（任务验证）找到RESULT_LOG（结果日志）中的记录，设置执行状态值为“处理成功”，并将返回给前台的结果消息打包记入结果区，第二次日志记录完成。

本发明中改进的日志结构，相较于普通的顺序添加式日志结构，增加了消息执行的状态和消息处理结果。执行信息记录了HFM（基础数据管理模块）执行请求命令的结果，系统重演时，只有日志记录中状态为执行成功的原始请求才被系统重新处理，这种设计保证了系统重演前后数据的一致性；消息处理结果记录了前后台间消息在后台的执行结果，为系统的故障排查和前后台消息一致性提供了保障。

HFM（基础数据管理模块）处理的请求包括基础数据变更和基础数据查询消息。请求来源于与同步路由之间的共享消息队列，HFM（基础数据管理模块）维护了一个本地消息队列，用于存放从共享消息队列中分拣出的HFM（基础数据管理模块）消息。

HFM（基础数据管理模块）在处理基础数据查询请求时相对简单，不涉及日志操作。如图4所示，HFM（基础数据管理模块）从共享消息队列中读取出原始请求，放入本地TASK（任务）消息队列中。HFM（基础数据管理模块）顺序读取本地队列，并进行消息类型判断和有效性校验，HFM（基础数据管理模块）在查询基础数据内存获得结果后，格式化响应消息，并将响应消息发送至共享消息队列，由同步路由将结果送达前台软件，最后HFM（基础数据管理模块）根据TASKID（任务验证）将本地队列中的TASK（任务）消息设为处理完毕，即从本地队列中删除，至此，HFM（基础数据管理模块）完成基础数据查询请求的处理。

HFM（基础数据管理模块）在处理基础数据变更请求时使用了基础数据日志机制，相应的，HFM（基础数据管理模块）对于基础数据修改请求的TASK，将分为二阶段进行处理，如图5所示，在第一阶段，HFM（基础数据管理模块）从共享消息队列获取基础数据更新请求消息，将原始请求落地ORIGINAL_LOG（原始日志）记录并更新RESULT_LOG（结果日志）记录的状态为“执行中”，之后HFM（基础数据管理模块）生成本地消息队列TASK（任务）消息，并将消息发送到本地消息队列中，等待被处理；第二阶段，HFM（基础数据管理模块）从本地消息队列中读取出TASK（任务）消息，判断是否为基础数据更新消息类型，然后由TASK（任务）消息记录的原始请求地址读取出ORIGINAL_LOG（原始日志）中原始消息记录，在完成内存更新前，要对原始请求进行有效性验证，内存更新完成后，将本地消息队列中TASK（任务）消息状态设为执行成功，最终HFM（基础数据管理模块）生成处理结果消息并进行格式转换，发送到共享消息队列，并更新到RESULT_LOG（结果日志）中的结果中。

基础数据变更的重演分为HFM（基础数据管理模块）进程重演和主机重演，分别用于HFM（基础数据管理模块）进程FAILOVER（失效备援）和主机FAILOVER（失效备援）时的状态恢复：

1)HFM（基础数据管理模块）进程若发生FAILOVER（失效备援），但架构没CRASH（死机）的情况下，只需要HFM（基础数据管理模块）进程重启：

进程重演的流程图如图6所示，重演的过程中HFM（基础数据管理模块）需要进行以下的处理：HFM（基础数据管理模块）进程将遍历日志中所有的记录来重新构建在CRASH（死机）或关闭时所发生的最新状态，通过之前落地的RESULT_LOG（结果日志）中执行状态字段可确定有哪些TASK（任务）记录仍然处于“处理中”的状态，对于“处理中”的状态的记录，则重新提交TASK消息给HFM（基础数据管理模块）本地消息队列，要求HFM（基础数据管理模块）重新执行该条指令，以便使主机能正确处理和返回前台响应消息，最终主机将RESULT_LOG（结果日志）中状态字段置为“执行成功”，备机在看到该请求后可同步进行更新操作；

对于HFM（基础数据管理模块）进程的重启，不必进行日志记录的全部重演，而只需检查RESULT_LOG（结果日志）的完备性，并提交未完成的TASK请求，减少了HFM（基础数据管理模块）进程重启的耗时，同时也增加了可靠度，备机在HFM（基础数据管理模块）进程FAILOVER（失效备援）和重启的过程中不受影响；

2)主机FAILOVER（失效备援）时的HFM（基础数据管理模块）接管处理，HFM（基础数据管理模块）所在主机若发生FAILOVER（失效备援），则进行主备机切换：

主机与备机之间共享基础数据日志库，基础数据日志物理文件中一条记录在状态更新为“执行成功”时，会触发备机HFM（基础数据管理模块）同步更新基础数据内存中的内容，所以主备机切换时，除去主机已经完成内存写操作但尚未完成更新日志状态的TASK（任务），备机中的基础数据内存已经保持与主机一致。参照图5，在发生切换时，原主HFM（基础数据管理模块）进程可能处在以下几种状态：

a)在第一阶段的1,2步骤时主机CRASH（死机），请求尚未写入日志物理文件中，在这种情况下，备机接管后可直接进行处理，因为之前提交的所有事物已全部执行完毕，丢失的新请求可通过前台软件重传的方式重新递交；

b)在第一阶段的3步骤时主机CRASH（死机），新的请求已写入日志文件，但未经过第二阶段的处理，在这种情况下，在备机接管后，备机需要检查RESULT_LOG（结果日志）中状态为处理中的记录，将未完成的TASK（任务）重新提交到本地队列中执；

c)在处理基础数据变更数据请求的第二阶段1-5步骤时主机发生CRASH（死机），在这种情况下，新的请求已写入日志，且第二阶段的业务逻辑已被处理(内存数据也已发生更新)，但是最后TASK（任务）的状态信息仍未更新到磁盘。在备机接管后，会重新提交ORIGINAL_LOG（原始日志）中未执行完成的TASK（任务）至本地消息队列，并重新执行该业务流程，因为原主机HFM（基础数据管理模块）进程未完成第二次日志更新（将该TASK（任务）在RESULT_LOG（结果日志）中的执行状态信息设为“执行成功”），所以备机并未开始执行本次基础数据更新操作，备机更新此次TASK（任务）仍然可认为是首次更新；

d)在第二阶段的6步骤完成后发生CRASH（死机），在这种情况下，备机直接处理后续新订单并进行主机的业务逻辑即可。

主备机切换之前，备机应用进程并不实时处理订单消息，当主备机发生切换时，备机根据应用日志中的记录进行重。应用日志中的订单记录已经包含状态和验证信息，备机重演过程中对于状态为已经处理完毕的订单只加载，并不对订单做检验，避免了因为基础数据变更对重演的影响。主备机切换完毕，备机成为主机，接管之前主机的所有TASK（任务）。

Claims (10)

1.一种保证分布式数据处理一致性的系统,包括计算机交易系统平台，其特征在于所述的计算机交易系统平台由若干台负责交易业务处理的交易平台组成，交易主机内部会将一台主机作为主节点，其他节点则成为交易备机，主节点负责所有订单的处理任务，并负责日志记录和维护、触发从节点的基础数据同步，从节点并不进行实时订单处理，但是能够通过同步维护基础数据内存与主节点一致，所述的主机内设有同步路由器，同步路由器从订单生成软件、前台数据管理软件或其它平台分别获取订单消息和基础数据更新消息，同步路由器分别连接若干应用进程和共享消息队列，所述的若干应用进程分别连接基础数据内存和订单簿内存，所述的共享消息队列连接基础数据管理模块，所述的基础数据管理模块连接基础数据内存；所述的基础数据内存支持一写多读，并支持写操作的撤销指令，所述的基础数据管理模块在处理基础数据日志中增加了日志记录的执行状态信息和索引支持动态定位，数据处理请求到达时将原始请求消息落地日志记录，并在数据处理完毕后更新日志记录中的执行状态信息和执行结果。 

2.如权利要求1所述的一种保证分布式数据处理一致性的系统，其特征在于所述的若干应用进程通过应用日志连接备机，所述的基础数据管理模块通过数据管理日志连接备机，主机内还设有平台间消息同步通信模块，交易集群中其他平台通过平台间消息同步通信模块连接共享队列。 

3.如权利要求1所述的一种保证分布式数据处理一致性的系统，其特征在于所述的基础数据内存包括若干条记录，记录头部结构中除了索引用的密码值外，还增加了标签字段，用于记录当前版本号，标签字段的读取和写入皆为原 子操作，不产生冲突，基础数据内存支持一写多读，并支持写操作的撤销指令，在基础数据管理模块更新基础数据记录的同时，应用程序的读取操作不受影响。 

4.如权利要求1所述的一种保证分布式数据处理一致性的系统，其特征在于所述的基础数据管理模块处理的请求包括基础数据变更和基础数据查询消息，请求来源于与同步路由器之间的共享消息队列，基础数据管理模块维护了一个本地消息队列，用于存放从共享消息队列中分拣出的基础数据管理模块消息。 

5.如权利要求4所述的一种保证分布式数据处理一致性的系统，其特征在于所述的基础数据管理模块在处理基础数据查询请求时不涉及日志操作，基础数据管理模块从共享消息队列中读取出原始请求，放入本地任务消息队列中，基础数据管理模块顺序读取本地队列，并进行消息类型判断和有效性校验，基础数据管理模块在查询基础数据内存获得结果后，格式化响应消息，并将响应消息发送至共享消息队列，由同步路由将结果送达前台软件，最后基础数据管理模块根据任务验证将本地队列中的任务消息设为处理完毕，即从本地队列中删除，至此，基础数据管理模块完成基础数据查询请求的处理。 

6.如权利要求4所述的一种保证分布式数据处理一致性的系统，其特征在于所述的基础数据管理模块在处理基础数据变更请求时使用了基础数据日志机制，基础数据管理模块对于基础数据修改请求的任务，将分为二阶段进行处理，在第一阶段，基础数据管理模块从共享消息队列获取基础数据更新请求消息，将原始请求落地原始日志记录并更新结果日志记录的状态为:执行中，之后基础数据管理模块生成本地消息队列任务消息，并将消息发送到本地消息队列中，等待被处理，第二阶段，基础数据管理模块从本地消息队列中读取出任务消息， 判断是否为基础数据更新消息类型，然后由任务消息记录的原始请求地址读取出原始日志中原始消息记录，在完成内存更新前，要对原始请求进行有效性验证，内存更新完成后，将本地消息队列中任务消息状态设为执行成功，最终基础数据管理模块生成处理结果消息并进行格式转换，发送到共享消息队列，并更新到结果日志中的结果中。 

7.一种保证分布式数据处理一致性的方法，数据处理过程中涉及的请求消息主要有订单请求和基础数据更新请求，订单消息来自订单生成软件，基础数据更新消息则由前台数据管理软件或其它平台产生，其特征在于具体方法如下： 

a.请求消息到达主机后，由同步路由器根据消息类别送达共享消息队列，交由相应的进程处理； 

b.应用进程在订单处理过程中，首先连接到基础数据内存，再根据其中记录的信息对订单进行校验，校验成功后写入订单簿内存，并更新应用日志文件记录中的状态信息，应用进程在处理订单过程中只写一次日志； 

c.数据更新请求消息经由同步路由器送达共享消息队列，触发基础数据管理模块，基础数据管理模块首先将原始请求写入基础数据日志，并完成对基础数据内存的更新后，再次更新基础数据日志中的状态消息为执行成功并落地处理结果,基础数据管理模块在处理消息过程中两次写日志,分别是被触发时和处理完毕后,改进的基础数据日志结构和两次更新日志的机制保证了基础数据变更的可靠性； 

d.针对步骤b和步骤c中基础数据管理模块和应用进程存在同时读写基础数据内存的情况，基础数据内存中采用了多版本组织形式的支持基础数据管理模块和多应用进程同时读写，有效的降低了数据处理的时延。 

8.如权利要求7所述的一种保证分布式数据处理一致性的方法，其特征在于所述的基础数据内存读取方法如下： 

（1）.应用程序读取基础数据内存方法： 

a.通过密码值遍历到要读取的内存记录后，先将记录的标签值读出； 

b.根据密码值和标签值，定位到记录1的目前最新版本记录1.1，并将记录1.1中内容返回值应用进程； 

（2）.基础数据管理模块更新基础数据内存方法： 

a.通过密码值遍历到要读取的内存记录后，先将记录的标签值读出； 

b.根据获取到的标签值，确定记录1的目前最新版本记录1.1，根据密码值和标签值，将要修改的记录更新到下一版本记录1.2中，此时，由于步骤a发生在步骤c之前，所以同步进行的应用进程读取到的内存记录仍然为记录1.1； 

c.更新记录的标签值为1.2，完成数据更新操作； 

在步骤c之后，应用进程此后读取的内存为记录1.2； 

(3).基础数据管理模块撤销前一条指令方法： 

a.通过密码值遍历到要读取的内存记录后，先将记录的标签值读出； 

b.根据获取到的标签值，确定记录1的目前最新版本记录1.2，更新标签值为当前版本的上一版本号1.1，此时，由于步骤a发生在步骤b之前，所以同步进行的应用进程读取的内存记录仍然为记录1.2； 

在步骤b之后，应用进程此后读取的内存为记录1.1。 

9.如权利要求7所述的一种保证分布式数据处理一致性的方法，其特征在于所述的基础数据管理模块在处理基础数据变更请求时，需要两次更新日志记录，分别是： 

a.基础数据管理模块在接收基础数据变更请求时，先将原始请求记录写入原始日志区中，并在结果日志中增加新的记录，并将状态信息置为：处理中，第一次落地日志完成； 

b.基础数据管理模块在基础数据变更请求处理完毕时，根据原始请求的任务验证找到结果日志中的记录，设置执行状态值为：处理成功，并将返回给前台的结果消息打包记入结果区，第二次日志记录完成。 

10.如权利要求7所述的一种保证分布式数据处理一致性的方法，其特征在于所述的方法还包括基础数据管理模块进程重演和主机重演，分别用于基础数据管理模块进程失效备援和主机失效备援时的状态恢复： 

（1）.基础数据管理模块进程若发生失效备援，但架构没死机的情况下，只需要基础数据管理模块进程重启； 重演的过程中基础数据管理模块需要进行以下的处理：基础数据管理模块进程将遍历日志中所有的记录来重新构建在死机或关闭时所发生的最新状态，通过之前落地的结果日志中执行状态字段可确定有哪些任务记录仍然处于处理中的状态，对于处理中的状态的记录，则重新提交任务消息给基础数据管理模块本地消息队列，要求基础数据管理模块重新执行该条指令，以便使主机能正确处理和返回前台响应消息，最终主机将结果日志中状态字段置为:执行成功，备机在看到该请求后可同步进行更新操作； 

对于基础数据管理模块进程的重启，不必进行日志记录的全部重演，而只需检查结果日志的完备性，并提交未完成的任务请求，减少了基础数据管理模块进程重启的耗时，同时也增加了可靠度,备机在基础数据管理模块进程失效备援和重启的过程中不受影响； 

（2）.主机失效备援时的基础数据管理模块接管处理，基础数据管理模块所在主机若发生失效备援，则进行主备机切换； 

主机与备机之间共享基础数据日志库,基础数据日志物理文件中一条记录在状态更新为:执行成功时，会触发备机基础数据管理模块同步更新基础数据内存中的内容，所以主备机切换时，除去主机已经完成内存写操作但尚未完成更新日志状态的任务，备机中的基础数据内存已经保持与主机一致；主备机切换之前，备机应用进程并不实时处理订单消息，当主备机发生切换时，备机根据应用日志中的记录进行重演，应用日志中的订单记录已经包含状态和验证信息，备机重演过程中对于状态为已经处理完毕的订单只加载，并不对订单做检验，避免了因为基础数据变更对重演的影响，主备机切换完毕，备 机成为主机，接管之前主机的所有任务；在发生切换时，原主基础数据管理模块进程处在以下几种状态： 

a.在第一阶段的基础数据管理模块获取基础数据更新请求消息并更新结果日志记录的状态为“执行中”的过程中主机死机，请求尚未写入日志物理文件中,在这种情况下，备机接管后可直接进行处理，因为之前提交的所有事物已全部执行完毕，丢失的新请求可通过前台软件重传的方式重新递交； 

b.在第一阶段的基础数据管理模块生成本地消息队列任务消息等待被处理的过程中主机死机，新的请求已写入日志文件，但未经过第二阶段的处理，在这种情况下，在备机接管后，备机需要检查结果日志中状态为处理中的记录，将未完成的任务重新提交到本地队列中执行； 

c.在处理基础数据变更数据请求的第二阶段完成前主机发生死机,在这种情况下，新的请求已写入日志，且第二阶段的业务逻辑已被处理，但是最后任务的状态信息仍未更新到磁盘,在备机接管后，会重新提交原始日志中未执行完成的任务至本地消息队列，并重新执行该业务流程，因为原主机基础数据管理模块进程未完成第二次日志更新,将该任务在结果日志中的执行状态信息设为执行成功,所以备机并未开始执行本次基础数据更新操作,所以备机更新此次任务仍然可认为是首次更新； 

d.在第二阶段完成后发生死机,在这种情况下，备机直接处理后续新订单并进行主机的业务逻辑即可。 

Images