一种单点异构数据存储的高可用框架系统及其实现方法与流程

本发明属于计算机领域，涉及一种数据存储的高可用框架，特别是涉及单点异构数据存储的高可用框架系统；此外，本发明还涉及该单点异构数据存储的高可用框架系统的实现方法。

背景技术：

现有技术是由国外团队开发的一款单点部署数据储存的高可用框架(见图1)。

图1中，各模块说明如下：

1.dyno：现有的单点存储高可用框架。

2.dyno-client：现有框架的客户端类库。

3.dyno-proxy：现有框架的数据存储代理服务。

4.Single Server DataStore：单点部署的同构数据存储服务。

5.Rack A/B：单点部署存储服务器，由dyno-proxy和Single Server DataStore组成。该框架可以让只能单点部署的同构数据储存做到集群部署，通过该框架的客户端(dyno-client)在对某一节点进行数据写入操作时(write request)，框架的代理服务(dyno-proxy)会将写操作同步到集群中其他节点完成数据同步写入(sync write request)。写入操作时单个节点出现故障，客户端和代理服务会选择其他可用节点完成数据写入。单个节点故障不会影响其他节点的数据写入，从而实现单点数据存储的高可用写入功能。

同样，依赖现有框架的数据读取节点选择功能，通过框架客户端发起数据读取操作时(read request)，该客户端会从集群中找出一个可用节点，并从该节点进行数据读取，如果节点无需要的数据，代理服务会将读取请求转发到数据所在节点(forward read request)。读取操作时单个节点出现故障，客户端和代理服务会跳过该节点选择下一个可用节点进行数据读取，通过这种方式实现了单点数据存储的高可用读取功能。

现有框架目前存在如下几个缺点：

1.现有框架仅支持两个主流NoSQL数据库的同构数据同步，不支持异构数据同步，现有框架在设计之初就并未将异构数据同步纳入实现目标之中。

2.现有框架不支持故障数据恢复功能，现有框架是为了解决单点数据存储的高可用问题，故障恢复并未作为核心功能列入实现列表中。目前只能靠人工方式手工从其他节点拷贝数据到故障节点恢复数据，每个数据存储的恢复方式都有所不同，数据恢复的复杂性可见一斑。

3.现有框架仅支持部署在Linux/Unix操作系统，跨平台性稍弱。框架的所有构建脚本使用shell命令，限制其在windows平台上无法进行构建和编译。

技术实现要素：

本发明要解决的技术问题在于提供一种单点异构数据存储的高可用框架系统，可支持更多数据存储类型，支持异构数据之间的数据同步，还可支持节点故障时的数据备份和数据恢复功能。为此，本发明还提供该系统的实现方法。

为解决上述技术问题，本发明提供一种单点异构数据存储的高可用框架系统，包括：

客户端类库ti-a59-client，提供单点异构数据的高可用读写操作；

异构数据转换和存储服务模块ti-a59-builder，用于接收由客户端类库ti-a59-client提交的写入数据，转换为异构数据存储支持的格式并写入到单点数据存储中；

数据写操作日志服务模块ti-a59-log-srv，用于存储节点故障后的数据恢复和新增节点时的数据初始化；

数据队列框架ti-queue，为数据写操作提供高可用性支持；

消息队列服务模块MQ Server，为系统提供数据写请求的路由、复制和持久化功能；

单点部署的异构数据存储服务器Single Server DataStore，负责异构数据的存储，并提供数据写入和读取接口；

写请求日志服务数据存储模块Write Log DataStore，保存数据写操作日志服务模块ti-a59-log-srv收到的数据写操作，用于故障后或新增a59存储节点时的数据同步；

写请求控制日志数据存储模块Ctrl Log DataStore，保存当前a59存储节点的数据写操作的执行日志，确保同一个数据写操作不会被多次执行。

作为本发明优选的技术方案，所述客户端类库ti-a59-client提供数据写操作会将数据进行压缩并经由数据队列框架ti-queue分发到各a59存储节点，所有节点都会收到相同的数据并完成数据写入；所述客户端类库ti-a59-client提供数据读操作是基于单点数据存储原生API，通过TCP/HTTP Proxy代理的负载均衡算法将读请求发送至任意一个可用的a59存储节点完成数据读取。

作为本发明优选的技术方案，所述TCP/HTTP Proxy是提供高可用性、负载均衡以及基于TCP和HTTP应用的代理软件，通过配合HA软件实现对于a59存储节点数据的高可用读取操作；所述TCP/HTTP Proxy软件使用HAProxy+Keepalived实现，HAProxy是一款开源，完全免费的TCP/HTTP Proxy代理软件，Keepalived是集群管理中保证集群高可用的一个开源服务软件，能避免HAProxy出现单点故障，确保HAProxy自身的高可用性；基于TCP/HTTP Proxy，业务服务便能实现对于a59存储节点数据的高可用读取操作。

作为本发明优选的技术方案，一个所述异构数据转换和存储服务模块ti-a59-builder与一个所述单点部署的异构数据存储服务器Single Server DataStore一起构成一个所述a59存储节点；为了确保数据读写的高可用性，一套环境中需要搭建2个以上的a59存储节点；所述异构数据转换和存储服务模块ti-a59-builder为了确保写数据请求的幂等性，在每次写数据之前会通过访问所述写请求控制日志数据存储模块Ctrl Log DataStore确保相同的数据数据不会被重复写入。

作为本发明优选的技术方案，所述客户端类库ti-a59-client提交的数据写请求通过所述数据队列框架ti-queue复制到各a59实例存储节点的同时也会复制一份数据到所述数据写操作日志服务模块ti-a59-log-srv，ti-a59-log-srv会将写操作序列化到日志存储，日志数据用于后续节点故障或新增时的数据恢复；ti-a59-log-srv默认策略是保留7天内的数据日志，每天会清理掉7天以前的数据。

作为本发明优选的技术方案，所述数据队列框架ti-queue与ti-a59集成时主要基于所述消息队列服务模块MQ Server完成消息复制，将所述客户端类库ti-a59-client提交的数据复制到每个a59存储节点以及所述数据写操作日志服务模块ti-a59-log-srv日志节点。

作为本发明优选的技术方案，所述消息队列服务模块MQ Server采用RabbitMQ服务作为a59消息中间件；当异构数据转换和存储服务模块ti-a59-builder或数据写操作日志服务模块ti-a59-log-srv故障未正常连接时，将数据存储在消息队列服务模块中，确保消息不丢失，等到ti-a59-builder或ti-a59-log-srv重连后继续处理队列中的数据；由多台所述消息队列服务模块MQ Server组建的集群构成MQ Server Cluster，确保MQ Server自身的高可用性。

此外，本发明还提供一种采用上述系统实现异步数据写入的方法，包括如下步骤：

1)应用程序在发起异步数据写入操作时，通过调用ti-a59-client的Writer将数据写入各a59存储节点；

2)Writer为数据添加写入时间戳和唯一标识后调用ti-queue的Queue将数据加入队列；

3)ti-queue将入队数据进行序列化并组装成消息对象；

4)ti-queue将消息对象发送到MQ Server中对应的MQ Broker上；ti-a59-client在初始化时需要指定a59存储节点的组号，一个组号对应一个MQ Broker；

5)MQ Broker收到消息后，依靠消息复制分发机制，将消息写入所有绑定的所有queue中；

6)ti-a59-builder在收到消息后，会进行反序列化和解压缩得到原始数据；

7)ti-a59-builder会根据数据的写入时间和唯一标识到Ctrl Log DataStore中进行检查；

8)如果写入操作并未执行过，则调用Builder发起数据写入操作；

9)ti-a59-Builder收到数据后，调用用户指定的数据转换代码并通过调用Single Server DataStore的标准API完成数据写入；

10)写入成功后，ti-a59-builder记录一条写操作日志到Ctrl Log DataStore。

为此，本发明还提供一种上述系统实现同步写数据的方法，包括如下步骤：

1)应用程序在发起数据同步写入操作时，需要先调用ti-a59-client的Scenario启动一个场景，场景的作用是用于和一个a59数据存储进行关联；

2)场景创建完毕后，通过调用ti-a59-client的Writer将数据写入各a59存储节点；

3)Writer收到同步写请求时，会从Scenario中读取当前绑定a59存储节点，如果指定则会等待指定节点的写操作返回结果，如果不指定，则等待第一个返回的写操作结果；

4)Writer为数据添加写入时间戳和唯一标识后调用ti-queue的Queue将数据加入队列；

5)ti-queue将入队数据进行序列化并组装成消息对象；

6)ti-queue将消息对象发送到对应的MQ Broker上；ti-a59-client在初始化时需要指定a59存储节点的组号，一个组号对应一个MQ Broker；

7)MQ Broker收到消息后，依靠消息复制分发机制，将消息写入所有绑定的所有queue中；

8)ti-a59-builder在收到消息后，会进行反序列化和解压缩得到原始数据；

9)ti-a59-builder会根据数据的写入时间和唯一标识到Ctrl Log DataStore中进行检查；

10)如果写入操作并未执行过，则调用Builder发起数据写入操作；

11)ti-a59-Builder收到数据后，调用用户指定的数据转换代码并通过调用Single Server DataStore的标准API完成数据写入；

12)写入成功后，ti-a59-builder记录一条写操作日志到Ctrl Log DataStore；

13)ti-a59-builder会将写操作的结果通过MQ Server、ti-queue发送到由发起写请求的ti-a59-client监听的指定队列中，最终由当时发起写操作的Writer收到写操作应答；

14)如果步骤1)创建场景时未指定节点，那么会将返回的节点编号更新到场景中，以便后续写操作能锁定在同一个节点上；

15)调用Scenario整个同步调用过程。

为此，本发明还提供一种上述系统实现数据读取的方法，ti-a59的数据读取是基于单点数据存储原生API，通过TCP/HTTP Proxy代理的负载均衡算法将读请求发送至任意一个可用的a59存储节点完成数据读取，具体包括如下步骤：

1)应用程序调用Single Server DataStore的原生API发起数据读取操作；原生API指向ti-a59的TCP/HTTP Proxy所在地址；

2)TCP/HTTP Proxy根据负载均衡算法，将读取请求转发到一台可用的单点数据存储服务器上完成读取操作，并原路将读取结果返回给应用程序。

与现有技术相比，本发明的有益效果在于：

1、本发明除了包含现有框架的单点部署存储的高可用性支持的特性之外，还有具备了更强的跨平台部署能力，以及异构数据同步和故障数据恢复等现有框架无法支持的重要特性。提供了一套更为完善，数据可靠性更高，框架可扩展性更强的单点部署数据存储高可用化实现方案。

2.本发明为单点数据存储提供通用的高可用性支持，支持多节点同时写入、负载均衡策略下的数据读取和并保证数据的一致性。相比现有技术仅支持Linux/Unix操作系统，而本发明的框架可以部署在几乎所有主流操作系统上。现有技术支持2种数据存储类型，本发明的框架则支持更多数据存储类型。

3.支持异构数据之间的数据同步，比如将关系型数据库的数据同步到图数据库中，或将关系数据同时写入NoSQL数据库中，现有技术目前不支持异构数据之间的同步。

4.支持节点故障时的数据备份和数据恢复功能，现有技术目前不具备故障后数据恢复功能。

附图说明

下面结合附图和实施例对本发明进一步说明。

图1是现有单点部署数据储存的高可用框架的结构示意图；其中，dyno：现行的单点存储高可用框架；dyno-client：现行框架的客户端类库；dyno-proxy：现行框架的数据存储代理服务；Single Server DataStore：单点部署的同构数据存储服务；Rack A/B：单点部署存储服务器，由dyno-proxy和Single Server DataStore组成。

图2是本发明单点异构数据存储的高可用框架系统的结构示意图；其中，ti-a59：本专利申请的单点异构存储高可用框架；ti-a59-client：ti-a59的客户端类库；ti-a59-builder：ti-a59的异构数据转换和存储服务；ti-a59-log-srv：ti-a59的数据写操作日志服务；ti-queue：ti-59内置通用的数据队列框架；MQ Server：消息队列服务；MQ Server Cluster：由多台MQ Server组建的集群；TCP/HTTP Proxy(HA)：提供高可用性、负载均衡以及基于TCP/HTTP的代理软件,并通过集群管理软件保证代理软件的高可用；Single Server DataStore：单点部署的异构数据存储服务；Write Log DataStore(HA)：ti-a59的写请求日志服务数据存储；Ctrl Log DataStore(HA)：ti-a59的写请求控制日志数据存储；A59Log Server：a59日志服务器，由ti-a59-log-srv与Write Log DataStore组成；A59Instance A/B：a59存储节点，由ti-a59-builder与Single Server DataStore组成。

图3是本发明中异步写数据的流程图；其中，Application：应用程序，调用ti-a59框架完成数据写入；ti-a59-client.Writer：ti-a59-client中提供的Writer接口；ti-queue.AmqpQueue:基于AMQP高级消息队列协议的ti-a59实现类；MQ Broker：消息队列的消息控制器；ti-a59-builder.QueueWithReplyListener：ti-a59-builder的消息队列监听器；Ctrl Log DataStore：保存写操作控制日志的数据存储；ti-a59-builder.Builder：ti-a59-builder的内置数据构建器；Single Server DataStore：单点部署的数据存储。

图4是本发明中同步写数据的流程图；其中，Application：应用程序，调用ti-a59框架完成数据写入；ti-a59-client.Scenairo：ti-a59-client中调用场景，同步调用时需要开启和关闭场景；ti-a59-client.Writer：ti-a59-client中提供的Writer接口；ti-queue.AmqpQueue:基于AMQP高级消息队列协议的ti-a59实现类；MQ Broker：消息队列的消息控制器；ti-a59-builder.QueueWithReplyListener：ti-a59-builder的消息队列监听器；Ctrl Log DataStore：保存写操作控制日志的数据存储；ti-a59-builder.Builder：ti-a59-builder的内置数据构建器；Single Server DataStore：单点部署的数据存储。

图5是本发明中数据读取的流程图；其中，Application：应用程序，调用ti-a59框架的TCP/HTTP Proxy组件完成数据读取；DataStore Native API：单点数据存储提供的标准数据访问接口；TCP/HTTP Proxy：提供高可用性、负载均衡以及基于TCP/HTTP应用代理软件；Single Server DataStore：单点部署的异构数据存储。

具体实施方式

现在结合附图对本发明作进一步详细的说明。这些附图均为简化的示意图，仅以示意方式说明本发明的基本结构，因此其仅显示与本发明有关的构成。

一、如图2所示，本发明单点异构数据存储的高可用框架系统的内部组件介绍如下：

本发明的单点异构数据存储的高可用框架系统名为ti-a59。

ti-a59框架包含四个子项目ti-a59-client、ti-a59-builder、ti-a59-log-srv、ti-a59-share以及一个通用数据队列实现框架ti-queue，所有项目代码采用Java语言实现。

依赖Java语言的跨平台性，本框架系统可以部署在几乎所有主流操作系统中，而现有技术框架只能部署在Linux/Unix平台之上。

1.下面对ti-a59整体方案中涉及的各组件和模块进行介绍(请参考图2)。

1.1 ti-a59-client

ti-a59的客户端类库，提供单点异构数据的高可用读写操作。

数据写操作会将数据进行压缩并经由ti-queue框架分发到各a59存储节点，所有节点都会收到相同的数据并完成数据写入。

数据读操作是基于单点数据存储原生API，通过TCP/HTTP Proxy代理的负载均衡算法将读请求发送至任意一个可用的a59存储节点完成数据读取。

TCP/HTTP Proxy代理支持的复杂均衡算法一般有如下几种：

1)RoundRobin：简单的轮询，每个服务器根据权重轮流使用，在服务器的处理时间平均分配的情况下这是最流畅和公平的算法。

2)LeastConn：连接数最少的服务器优先接收连接。

3)Source：对请求源IP地址进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个客户端IP地址总是访问同一个服务器。如果哈希的结果随可用服务器数量而变化，那么客户端会定向到不同的服务器。

1.2 ti-a59-builder

ti-a59的异构数据转换和存储服务模块，负责接收由ti-a59-client提交的写入数据，转换为异构数据存储支持的格式并写入到单点数据存储中。

一个ti-a59-builder与单点部署的异构数据存储(Single Server DataStore)一起构成一个a59存储节点(Instance)。为了确保数据读写的高可用性，一套环境中至少需要搭建2个或以上的a59存储节点。

ti-a59-builder为了确保写数据请求的幂等性，在每次写数据之前会通过访问控制日志(CtrlLog)确保相同的数据数据不会被重复写入。

1.3 ti-a59-log-srv

ti-a59的数据写操作日志服务模块，用于a59存储节点故障后的数据恢复和新增节点时的数据初始化。

ti-a59-client提交的数据写请求通过ti-queue复制到各a59实例存储节点的同时也会复制一份数据到ti-a59-log-srv，ti-a59-log-srv会将写操作序列化到日志存储，日志数据可以用于后续节点故障或新增时的数据恢复。

ti-a59-log-srv默认策略是保留7天内的数据日志，每天会清理掉7天以前的数据。

1.4 ti-queue

ti-queue是一个通用的数据队列框架，为ti-a59数据写操作提供高可用性支持。与ti-a59集成时主要基于MQ Server完成消息复制，将ti-a59-client提交的数据复制到每个a59存储节点以及ti-a59-log-srv日志节点。

2.ti-a59框架搭建时使用的中间件：

2.1 MQ Server

MQ Server是消息队列服务模块，为a59框架提供数据写请求的路由、复制和持久化等功能。MQ Server有很多可选的开源实现，作者比较推荐RabbitMQ服务作为a59消息中间件。

RabbitMQ是一个开源的消息队列系统，用elrang语言开发，是AMQP(高级消息队列协议)的标准实现，支持消息的持久化。

当ti-a59-builder或ti-a59-log-srv故障未正常连接时，可将数据可以存储在消息队列服务模块MQ Server中，确保消息不丢失，等到ti-a59-builder或ti-a59-log-srv重连后可继续处理队列中的数据。

MQ Server Cluster(图2中采用RabbitMQ Cluster)是由多台MQ Server组建的集群，确保MQ Server自身的高可用性。

2.2 TCP/HTTP Proxy(HA)

TCP/HTTP Proxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理软件，通过配合HA软件实现代理服务高可用性。

本实施例优选使用HAProxy+Keepalived作为TCP/HTTP Proxy(HA)的实现。

HAProxy是一款开源，完全免费的TCP/HTTP Proxy代理软件。

Keepalived是集群管理中保证集群高可用的一个开源服务软件，可避免HAProxy出现单点故障，确保HAProxy自身的高可用性。、

基于TCP/HTTP Proxy，业务服务便可实现对于a59存储节点数据的高可用读取操作。

3.ti-a59框架涉及的数据存储：

3.1 Single Server DataStore

单点部署的异构数据存储服务器，负责异构数据的存储，并提供数据写入和读取接口。这些数据存储自身没有高可用的支持，也不支持异构数据的同步功能。

ti-a59的目标就是为了提供高可用的数据访问以及异构数据同步功能。

在一个a59存储节点集群中，可以同时部署不同类型的异构数据存储节点，而现有框架的一个集群中所有存储节点存储类型必须相同。

3.2 Write Log DataStore(HA)

ti-a59的写请求日志服务数据存储，保存ti-a59-log-srv收到的数据写操作，用于故障后或新增a59存储节点时的数据同步。

本实施例优选采用MySQL数据库作为数据存储，并采用Master+Slave+Keepalived部署方式确保日志存储的高可用性(HA)。

3.3 Ctrl Log DataStore(HA)

ti-a59的写请求控制日志数据存储，保存当前a59存储节点的数据写操作的执行日志，确保同一个数据写操作不会被多次执行。

本实施例优选采用MySQL数据库作为数据存储，并采用Master+Slave+Keepalived部署方式确保日志存储的高可用性(HA)。

4.ti-a59的高可用数据读写支持

可以为单点部署的数据存储提供高可用读写的能力，是ti-a59的主要特色和创新点之一。

应用程序调用ti-a59-client发起的一次数据写操作，这份数据会被同时写入一组a59存储节点的所有可用节点中，每个节点都会写入相同的数据。这些可用节点的数据类型可以相同，也可以不相同，依靠a59的异构数据同步的功能，ti-a59-client的一次数据写操作可以同时写入不同类型的数据存储中。

即使当时有一个节点出现故障无法写入时，只要有至少一个可用节点，可以保证本次写入操作能正确执行。

应用程序发起的一次数据读操作时，ti-a59框架中的TCP/HTTP Proxy组件可以为本次读取选择一个可用a59存储节点，如果存在多个可用节点，则会根据负载均衡算法选择一个最佳访问节点。所以即使发起读取操作某个节点出现故障，只要有至少一个可用节点，就不会影响本次数据读取操作。

对于写操作，ti-a59支持异步和同步两种不同的数据高可用数据写入方式。对于读操作，ti-a59提供了支持负载均衡方式的高可用数据读取方式。

5.异构数据同步

异构数据同步作为ti-a59的重要特性之一，是现有技术目前所不支持的。

一组a59存储节点集群支持部署不同数据类型的单点数据存储服务，支持异构数据同步正是a59框架的特色之一，而现有框架的一个存储集群中只支持部署相同类型的数据存储。

ti-a59在进行数据写入的过程中(参考图3和图4)，可以通过ti-a59-builder.Builder(ti-a59-builder的内置数据构建器)类完成异构数据转换和组装。

不同的Builder实现了从Java类型数据到不同数据类型的转换和数据写入操作，通过在ti-a59-builder中配置不同的Builder实现，就可以完成诸如在Neo4j、MemSQL、Redis，MemSQL、MySQL等各类数据库之间的异构数据同步。

6.存储节点的故障数据恢复

ti-a59支持对于存储节点故障数据恢复功能，这是现有框架所不支持的另一个重要特性。

由ti-a59-log-srv和Write Log DataStore一起构建的数据写入操作备份服务，在每次数据写入时会从MQ Server队列中复制一份数据并进行备份。

当某个a59存储节点出现故障重启后，未写入的数据请求会持久化保存在组件队列中，当节点重启之后会自动从队列中获取从故障时点之后的所有数据。

如果组件队列中的数据意外丢失，还可以通过ti-a59-log-srv将故障时间点至今所有的数据批量导入至故障节点的ti-a59-builder中，ti-a59-builder会在保证数据写入一致性的情况下，将所有节点未执行过的数据变更操作全部重放一遍，以达到故障后数据恢复的目的。

同样，故障数据恢复功能也可用于新增节点的数据初始化，新增节点加入a59存储节点组时包含近7天内的某一次数据全量备份，通过指定数据备份时间，ti-a59-log-srv会自动将该时间点以后至今的所有数据批量同步到新增节点中。

二、本发明还提供上述单点异构数据存储的高可用框架系统的实现方法，具体参见图3-图5。

1、ti-a59的高可用数据读写支持，对于写操作，ti-a59支持异步和同步两种不同的数据高可用数据写入方式。对于读操作，ti-a59提供了支持负载均衡方式的高可用数据读取方式。

1.1异步数据写入

下面是一次异步数据写入请求的调用的时序图和内部实现细节说明(参见图3)：

1)应用程序在发起异步数据写入操作时，通过调用ti-a59-client的Writer将数据写入各a59存储节点，因为是异步调用，应用程序无需等待写入操作应答，直接可以执行后续代码。

2)Writer(ti-a59-client.Writer，ti-a59-client中提供的Writer接口)为数据添加写入时间戳和唯一标识后调用ti-queue将数据加入队列。

3)ti-queue将入队数据进行序列化并组装成消息对象，当数据超过指定大小时会进行压缩操作。

4)ti-queue将消息对象发送到MQ Server中对应的MQ Broker(消息队列的消息控制器)上。ti-a59-client在初始化时需要指定a59存储节点的组号，一个组号对应一个MQ Broker。

5)MQ Broker收到消息后，依靠消息复制分发机制，将消息写入所有绑定的所有queue中，每个queue被一个a59存储节点的ti-a59-builder服务监听。只要有消息进入queue，就会被ti-a59-builder的QueueWithReplyListener接收并进行处理。

6)ti-a59-builder在收到消息后，会进行反序列化和解压缩得到原始数据。

7)ti-a59-builder会根据数据的写入时间和唯一标识到Ctrl Log DataStore中进行检查，如果写入操作已存在则忽略本次写操作。

8)如果写入操作并未执行过，则调用Builder发起数据写入操作。

9)ti-a59-Builder收到数据后，调用用户指定的数据转换代码并通过调用单点部署的异构数据存储服务器Single Server DataStore的标准API完成数据写入。

10)写入成功后，ti-a59-builder记录一条写操作日志到Ctrl Log DataStore。

到此为止，一次异步数据写入流程全部结束。

1.2同步写数据流程

同步写操作和异步写操作主要的区别体现在ti-a59-client调用的方式上(时序图请参见图4)。

1)应用程序在发起数据同步写入操作时，需要先调用ti-a59-client.Scenario启动一个场景，场景的作用是用于和一个a59数据存储进行关联，创建场景时可以指定一个a59存储节点，也可以由系统自动选择一个写入速度最快的节点。

2)场景创建完毕后，通过调用ti-a59-client的Writer将数据写入各a59存储节点，因为是同步调用，应用程序需要等待写入操作的应答。

3)Writer收到同步写请求时，会从Scenario中读取当前绑定a59存储节点，如果指定则会等待指定节点的写操作返回结果，如果不指定，则等待第一个返回的写操作结果。

4)第4到第12步与异步写数据请求类似，不同的是ti-a59-client会监听ti-queue的应答队列，接收写操作的返回数据。

5)第13到第15步，ti-a59-builder会将写操作的结果通过MQ Server(图4中RabbitMQ)、ti-queue发送到由发起写请求的ti-a59-client监听的指定队列中，最终由当时发起写操作的Writer收到写操作应答。因为每一个ti-a59-builder完成数据写入并返回自己的写操作应答，当时创建场景时如果指定a59存储节点，那么Writer只会处理指定节点返回的数据，否则处理第一个返回到ti-a59-client的数据。

6)第16步，如果创建场景时未指定节点，那么会将返回的节点编号更新到场景中，以便后续写操作能锁定在同一个节点上。需要注意的是虽然锁定了写入节点，但后续的数据写操作还是在所有a59节点上执行，只是返回结果从指定节点接收。

7)第17步，调用Scenario完成整个同步调用过程。如果程序需要顺序发起多次同步写数据，只需在所有写操作完毕后再调用Scenario。

到此为止，一次同步数据写入流程全部结束。

1.3数据读取流程

ti-a59的数据读取是基于单点数据存储原生API，通过TCP/HTTP Proxy代理的负载均衡算法将读请求发送至任意一个可用的a59存储节点完成数据读取。参见图5，具体包括如下：

1)应用程序调用单点数据存储的原生API发起数据读取操作；原生API指向的目标地址不是单点数据存储所在地址，而是指向ti-a59的TCP/HTTP Proxy所在地址。

2)TCP/HTTP Proxy根据负载均衡算法，将读取请求转发到一台可用的单点数据存储服务器(Single Server DataStore)上完成读取操作，并原路将读取结果返回给应用程序。

到此为止，一次数据读取流程全部结束。

2.异构数据同步

通过实现ti-a59-builder的Builder接口，用户可以自行扩展各类异构数据类型之间的数据同步功能。

ti-a59-builder对于Builder的提供了原生的事务支持，基于Spring的申明式事务定义，保证数据写操作的ACID属性(原子性、一致性、隔离性和持久性)。当数据写入操作出现异常时，会自动触发事务回滚，保证数据写操作不会被持久化到存储中。

用户可以将一次数据写操作，根据实际需求转化为一次甚至多次不同数据的写操作，ti-a59-builder原生的事务支持会保证多次写操作的原子性和一致性。

基于组件的消息复制功能，ti-a59可以支持将一次数据写请求复制到不同类型的异构数据存储节点组，同时完成不同异构数据的写入操作。

2.存储节点的故障数据恢复

当存储节点出现故障时，正在写入的数据因为事务机制的保证所以不会被持久化到存储中。同样因为MQ Server消息队列的事务特性，本次写请求的消息仍然会保留在消息队列中，同后续到达的所有写请求一起持久化在消息队列中。

因为MQ Server Cluster的存在，即使当时负责存储消息的MQ Server节点出现故障，a59存储节点仍可以通过其他可用的MQ Server节点获取到所有保存再队列中的待写入数据。

如果MQ Server队列中待写入数据被意外清除，用户仍可通过ti-a59-log-srv服务通过文件方式将数据批量同步到待恢复的a59存储节点，由ti-a59-builder负责按顺序重新导入所有未处理数据。这种批量数据恢复方式避免了用户通过人工恢复故障节点的数据，解决了不同异构数据类型的恢复方式不同的问题。

ti-a59-builder在数据恢复时同样会进行数据写入控制检查，已经执行过的写入操作不会被重复执行，保证了当前节点的数据一致性。

故障数据恢复功能同样适用于新增节点的数据初始化，通过指定数据同步的起始时间，采用全备恢复+增量同步的方式保证新增节点能够快速与其他存储节点的数据保持同步。

以上述依据本发明的理想实施例为启示，通过上述的说明内容，相关工作人员完全可以在不偏离本项发明技术思想的范围内，进行多样的变更以及修改。本项发明的技术性范围并不局限于说明书上的内容，必须要根据权利要求范围来确定其技术性范围。