CN102882927A - 一种云存储数据同步框架及其实现方法 - Google Patents

Abstract

本发明在分析当前Hadoop框架中HDFS模块存在的中心服务器Namenode节点的单点故障这一缺陷的基础上，提出了一种云存储数据同步框架，所述云存储数据同步框架采用双中心服务器架构，双中心服务器同时在线服务，解决了数据的一致性问题，并基于分布一致性Paxos算法，设计了针对双中心服务器的三机Paxos算法，从而构成数据同步框架Quorum，并规范了该架构上的读写操作。采用本发明的数据同步框架Quorum，将能很好地解决Namenode节点单点故障情况下的服务中断问题，使系统在某一服务器出问题的情况下依然可以对外提供正确的数据读写访问，并保证数据的最终一致性。

Description

一种云存储数据同步框架及其实现方法

技术领域

本发明属于数据云存储领域，特别是涉及数据同步框架的设计与实现。

背景技术

随着互联网产业的飞速发展，海量数据的存储及实时处理成了计算机行业亟待解决的难题。传统的关系型数据库已经不能处理海量数据中非结构化数据日渐增长的特点，而以Hadoop为代表的分布式数据解决方案则开始成为业界关注的焦点。

Hadoop框架已经成为当前进行海量数据处理的首选框架，甚至被誉为“连接21世界海量数据处理的金钥匙”。作为Hadoop的基础模块，HDFS为用户提供了一个分布式的文件系统。HDFS采用经典的master/slave架构，一个搭建了HDFS的集群往往是由一个作为master的Namenode节点和一定数目作为slave的Datanodes节点组成。HDFS的结构可用图1进行说明。

Namenode是HDFS系统的核心。它是一个中心服务器，存储着文件系统的所有元数据（Metadata），包括：名字空间、访问控制信息、文件与数据存储块的映射关系，以及当前系统内所有数据块的位置信息，用来管理文件系统中的命名空间及客户端对文件系统的访问。同时，Namenode节点还管理着系统范围内的活动，包括数据存储块的分配，孤儿存储块的回收，以及数据存储块在不同Datanodes节点之间的迁移。在实现上，Namenode节点使用心跳信息包周期性地与每个Datanode服务器联系，并且维持一个在线Datanode的列表，发送指令到各个Datanode服务器并接收它们的状态信息。

HDFS的master/slave结构具有高容错的特点，可提供高吞吐量的数据访问，非常适合海量数据集的应用。HDFS放宽了对部分POXIS的限制，可方便地实现流式文件系统读取的目的。由于master采用单一的Namenode服务器，优点是容易实现，并且可以使用简单有效的逻辑来管理元数据。然而，HDFS的这种结构也存在缺点：作为其master/slave架构中master的中心服务器，Namenode节点为单一节点意味着，如果Namenode服务器失效，将造成整个文件系统的崩溃。并且，由于所有的访问都要流经Namenode结点，所以该单点也会成为系统的热点，成为效率的瓶颈。

针对Namenode失效的可能，HDFS本身采用了FsImage与EditLog结合备份的方式。当Namenode失效以后，文件系统可以根据硬盘中的映像FsImage及操作日志EditLog进行恢复。根据文件系统的规模，恢复过程所花费的时间也有所不同；更重要的一点是，在Namenode的恢复期间，整个文件系统将处于不可访问的状态。

目前在业界，也存在多种解决HDFS Namenode单点故障的HDFS HA（High Availability，高可用性）方案。如，Facebook公司的AvatarNode项目实际上提供了一种热备方式。它采用Namenode主备切换的方式，当主Namenode节点失效以后，通过人工切换的方式，将所有对Namenode的请求转移到备机上去。而DRBD（Distributed Replicated Block Device）则提供了一种冷备方式。当将数据写入本地DRBD设备上的文件系统时，数据会被同时发送到网络中的另外一台主机上，并以完全相同的形式被记录在其上的文件系统中。本地节点与远程节点的数据可以保证实时同步，并且保证IO的一致性。所以当本地节点的主机出现故障时，远程节点的主机上还会保留着一份完全相同的数据可供使用，从而达到了HA的目的。

这两类方案虽然可以实现Namenode的故障恢复，体现了当前HDFS HA（高可用性）的主要思路，但其缺点也显然易见：

1.         并没有将Namenode从单点中解放，同一时间仍只有一个中心服务器在线，所以它仍是系统的热点。在大规模的集群应用中，仍是系统效率的瓶颈；

2.         由于需要在主机备机之间进行数据的同步，同步的频率从数秒到几分钟不等，则在Namenode失效之后，肯定有部分数据被丢失；

3.         主备切换需要人工的干预，从系统失效报警到人工切换备机，期间必定存在一定时间间隔，那这段时间内，系统同样是不可访问的。

发明内容

本发明针对Hadoop中心服务器节点Namenode的单点故障问题及以上应对方案存在的缺陷，重点围绕提高中心服务器的可用性，提出了一种云存储数据同步框架。该框架能很好地解决Namenode单节点故障情况下的服务中断问题，又不以牺牲系统的效率和部分数据为代价，使系统即使发生服务器节点失效，依然可以高效正确的对外部访问者提供数据访问、管理整个文件系统，而无需人工干预，保证了数据的最终一致性。

为解决上述技术问题，本发明采用的技术方案是：提供一种云存储数据同步框架，包括应用于HDFS的经典的master/slave架构，其中Namenode节点是中心服务器，所述云存储数据同步框架采用双中心服务器架构，双中心服务器同时在线服务。在HDFS架构图中，Namenode节点和Datanodes节点的关系是1：N，这突显了Namenode节点是不可或缺的。Namenode之所以如此重要，还因为HDFS系统中最重要的元数据的唯一一份拷贝在该Namenode服务器中。而Datanodes的请求往往是对Metadata数据的读写访问，因此，倘若Metadata在多台服务器上存在多个副本，那么对Namenode节点的联系就可以分散到不同的机器上去了。基于这样的思想，本发明提出了基于双中心服务器的HDFS架构，改进后的架构可以用图2说明。

在本发明的这个架构中，Namenode节点不再唯一，从而除去了构成单点故障的必要条件。即使在一个Namenode服务器失效离线之后，只要另一个Namenode服务器在线，HDFS系统就可以正常运作。从而解决了HDFS存在的单点问题。在双中心服务器中，它们的内存中都保存着一份最新的元数据，外部请求会依据一定的策略被分发到某个Namenode服务器，这样就缓解了仅有一台中心服务器所带来的热点问题。所以，我们的方案中所述Namenode节点可以有多个，每个Namenode节点都保存有最新的元数据。

另外，需要指出的是，双中心服务器架构并不同于双机热备中双主机的方式。双机热备的双主机方式即指两种不同业务分别在两台服务器上互为主备状态（即Active-Standby和Standby-Active状态）。两者的区别在于，双主机方式即服务器上两种不同的服务分别在两台服务器上互为主备，言外之意就是该方式下，两台服务器虽然会同时在线，响应外界的请求，但对某项功能（或服务）而言，却是只有一台服务器可以提供的，因此将粒度细分到服务上，就会发现它其实也是Active-Standby方式。而双中心服务器的特点是两台中心服务器的地位完全对等，无论从粗粒度角度把它当个黑盒来对待，还是细化到单个功能服务上，两个服务器对外界而言是完全对等的。在该架构下，客户端对一个服务器提出的请求实际上也可以由另一服务器来进行处理。

上述基于多Namenode节点的方案还面临着一个显而易见的问题：即如何保持这多个Namenode节点之间数据的一致性，杜绝脏数据的出现。这是属于分布式一致性范畴领域研究的问题。

分布一致性问题是分布式算法中的一个经典问题。在一个分布式系统中，存在一组Process，它们需要确定一个Value。于是每个Process都提出了一个Value，一致性是指只有其中的一个Value能够被选中作为最后确定的值，并且当这个值被选出来以后，所有的Process都需要被通知到。

在分布式系统中，可能存在各种各样的问题。例如，某台服务器崩溃了怎么办，所以我们可能需要有几台服务器共同决定。此外，Process提交Value的时间都不一样，网络传输过程中由于延迟这些Value到达server的顺序也都没有保证。

为了解决此类问题，我们进一步提出数据一致性的设计。经过对多种分布式一致性算法的对比，本发明最终选择了经典算法Paxos作为本方案的分布一致性算法的基础。Paxos算法被业界视为该领域中最经典的算法。

本发明将复杂的Paxos算法进行了简化，将适应于多机选举的Paxos算法改造为三机Paxos算法。改造的三机Paxos算法设定存在三个结点A、B和C，这三个节点都具备acceptor和learner角色，其中A和B还具有proposer的角色。

 对于A（B），它提出的提案，只要B（A）或C中任意一个accept了，加上它自己就足够构成多数派，因此选举的关键在于让B（A）或C中任意一个acceptor通过（accept）提案。假设A选择一个提案编号n，并向B和C发送prepare请求，此时B有三种情况：

1.         B没有accept任何请求，也没有prepare比n编号更大的请求，则B会承诺不再批准小于n的提案。A和B构成多数派，A继续提出（propose）这个提案。

2.         B已经prepare编号为m（m>n）的请求，则这个prepare请求一定是B提出的。此时，C的prepare结果决定了A和B谁会提议（propose）议案。

3.         B已经accept了编号为m（m>n）的请求，则这个请求一定是B提出的，而且C必然也已经prepare了编号为m的请求，则A不能再提出任何请求，它必须accept这个编号为m的请求。

对于C也有三种情况：

1.         C没有accept任何请求，也没有prepare比n编号更大的请求，则C会承诺不再批准小于n的提案。A加上C构成多数派，A继续提出（propose）这个提案。

2.         C已经prepare编号为m（m>n）的请求， 则这个prepare请求一定是B提出的，并且B和C已构成多数派，B会提出（propose）提案。此时A需要再选择一个更大的编号。

3.         C已经accept了编号为m的请求，此时B和C都已accept该请求，构成多数派，A必须服从这个决定，accept这个请求。

也就是说，无论如何，经过至多2次提议（propose），A、B和C之间一定会得到一个多数派，A和B可以继续提议(propose)，并且该议案会被最终批准。

本发明结合双中心服务器架构以及改造的Paxos算法实现了数据同步框架Quorum。它从避免全局单点入手，实现双机可写，并保证数据的最终一致性。利用该数据同步框架Quorum，本发明提出了基于双中心服务器的HDFS高可用方案。即将HDFS的中心服务器进行复制，建立关系对等的两个中心服务器，同时对外提供相同的功能，并使用Quorum框架保持数据一致性。使得即便在某个Namenode服务器出现故障的情况下，HDFS照样能维持良好运作。

本发明所述的云存储数据同步框架的实现方法，包括写操作、读操作和同步操作。

所述写操作包括以下步骤：

步骤5.1，客户端写操作请求发送到结点A；

步骤5.2，结点A请求提升本地版本号；

 步骤5.3，结点B/C接收请求，提升本地版本号；

步骤5.4，结点A等待结点B/C返回结果；

步骤5.5，结点A更新本地数据。

所述读操作包括以下步骤：

步骤6.1，客户端读操作请求发送到结点A；

步骤6.2，结点A自检本地数据是否是正确的数据；

步骤6.3，向结点B请求版本号信息，询问B是否同自己的意见一致；

步骤6.4，结点A等待结点B返回结果；

步骤6.5，结点A向结点C请求版本信息；

步骤6.6，结点A允许读出数据。

所述同步操作包括以下步骤：

步骤7.1，扫描结点A（B）的流水日志，取出对Key的操作；

步骤7.2，确定系统中的多数派；

步骤7.3，数据复制，假定结点A数据较新，需要将结点A的数据复制到结点B，并更新A/B/C三结点的版本号。

与现有技术相比，有益效果是：

1.         避免全局单点，将重要的数据保存多份副本，置放在不同的服务器之上。这样即使一台中心服务器主机出现网络割裂、物理宕机等故障而造成服务不可访问时，还有其它的中心服务器可以代替故障服务器，提供相同的服务。在本发明的方案设计中，提供双中心服务器来保存核心数据。

2.         实现双机可写，两台服务器才可能处于对等的位置，保证最终数据一致性。

3.         在某台主机发生故障时，应尽量减少对读写服务的影响。在传统的双机热备方式下，当主机不可访问后，备机会用来对外界提供可读服务，却往往是不可写的，这样的目的是为了保证主机数据的最新。然而Quorum框架则应当保证即使在某台主机出现故障后，另外一台主机仍然可以对外提供受限的可读可写服务。

4.         由于同时有两台服务器对外提供服务，通过有效的负载方案，将使客户端请求在两台服务器上进行负载平衡，从而提高了系统效率。

附图说明

图1为Hadoop的模块组成图；

图2为本发明的双中心服务器架构图；

图3为本发明的同步数据框架Quorum的模块组成图；

图4为本发明的同步数据框架Quorum写操作的程序流程图；

图5为本发明的同步数据框架Quorum读操作的程序流程图；

图6 为本发明的同步数据框架Quorum的同步程序流程图。

具体实施方式

本发明提出了针对HDFS的高可用性方案——双中心服务器Namenodes节点。为解决该结构存在的数据分布式一致性问题而构造了数据同步框架Quorum。其理论基础是在经典Paxos算法上进行改造，实现三机Paxos算法。下面结合附图对本发明的实现做进一步的说明。

为避免单点故障，实现双机可写，保证中心服务器状态的最终一致性，并且当某台中心服务器发生故障时仍框架仍可对外提供读写服务，本发明设计了数据同步框架Quorum，其模块图如图3所示。

在本发明的模块图中存在两个中心服务器结点A和B，它们是关系对等的实体。A（B）两个中心服务器对外提供访问本机数据的接口，这是为了避免单点故障而设计的双中心服务器。Quorum框架还包含一个仲裁结点C，该仲裁结点与结点A、B一起构成了三机Paxos算法的基本成员。

数据结点A（B）在保存数据的同时，以键值对(Key, Value)的形式保存。而结点会为每个数据项的键Key，维持一个版本号，表示本地这个键值对应的版本信息。例如，结点A会为键Key记录版本对{VerAa, VerAb}，结点B会记录版本对{VerBa, VerBb}，仲裁结点C会记录版本对{VerCa, VerCb}。以结点A的{ VerAa, VerAb}为例，它表示结点A认为键值Key在结点A中的版本号为VerAa，在结点B中的版本号为VerAb。用这样的数据结构来记录版本信息的优点在于，当向结点A请求对Key所对应的数据进行读写时，结点A会先进行自检，若VerAa < VerAb，即结点A认为结点B上的数据比本地结点A上的数据更新，它会直接向请求方返回请求无效，让请求方向结点B发请求。这样可以直接提高对脏数据处理时的效率。

仲裁结点C是当结点A、B出现版本冲突时，对冲突进行仲裁的结点。因为结点C记录的版本信息无论是同结点A、B中的哪一方一致，结点C都会与一致的一方构成多数派，从而决定结点A、B中谁的数据正确的可能性更高。因此结点C只需要记录Key对应的版本即可，而Key所对应的值Value则由A（B）记录。

为了减少A、B两个数据结点之间的数据不一致所造成的冲突，本发明的Quorum框架提供了一个同步工具。在Quorum系统中，因为请求会散布到不同的结点A或B上，所以双机数据会出现短时间的不一致，这需要由该同步工具进行数据和版本号的同步。

数据同步框架Quorum的理论基础是三机Paxos算法。对一个分布式系统而言，利用经典Paxos算法就某个值（决议）达成一致将会经历咨询（prepare）->提案（propose）->承诺（promise）->通过（accept）->批准（chosen）等一系列状态，因此经典Paxos算法的实现是相当复杂的。三机Paxos算法对它进行了改造，在本质上仍然遵循Paxos算法的流程，但是将应用场景局限在双机结点中，从而使处理逻辑变得简单易懂。

显而易见，数据结点A（B）分别扮演了Paxos算法中proposer、acceptor及learner的角色，而仲裁结点C只扮演了acceptor及learner的角色。

本发明对数据同步框架Quorum的数据流程进行了设计。客户端对数据结点的操作请求包括读请求和写请求。此外，Quorum框架还包括同步操作。

图4是数据同步框架Quorum处理写请求操作的过程。假设结点A收到客户端请求（因为数据结点A、B是完全对等的关系，即使是结点B收到请求，其写请求的操作过程也类似）。写操作的流程大致如下：

1.         客户端写操作请求发送到结点A。

2.         因为是更新操作，所以结点A请求提升本地版本号：

1)        首先检查本地版本号信息，判断ver_a与ver_b的大小关系，提升版本条件为 A.ver_a >= A.ver_b；

2)        若条件成立，则提升A.ver_a = A.ver_a + 1，并继续执行；否则说明结点A通过自查发现持有的是脏数据，不能进行更新，因此返回写操作失败，说明这种情况下需要同步工具修复；

3)        向结点B/C广播提升版本号请求，要求在条件成立的前提下将ver_a自加。

3.         结点B（C）接收请求，提升本地版本号：

1)        检查本地版本号信息，判断B(C).ver_a >= B(C).ver_b；

2)        若条件成立，则提升 B(C).ver_a = B(C).ver_a + 1；

3)        将检查结果返回给结点A。

4.         结点A等待结点B/C返回结果：

1)        若收到结点B或C的提升成功信息，则继续执行；

2)        若两结点均返回提升失败，或提升请求超时，则返回写请求失败。

5.         结点A更新本地数据。

上述流程中涉及需要同步工具的修复会在稍后同步操作中进行详细的说明。在第4步中，结点A等待B/C的返回结果，只有收到结点B或C提升成功的返回信息，才表示写操作的前提成立，因为这表示多数派已经存在，没必要达成全体版本的一致。

写操作的流程首先检测版本号，然后提升版本号，上述所有过程完成之后才会进行实质的数据写入。才流程采纳了两段事务提交的思想（two-phase commit）。若先写入数据再提升A、B、C的版本号，而此期间如出现网络问题等导致操作失败，版本号没有得到及时更新，则这些写入的数据就会成为脏数据，并同时抹去了之前的数据。而提升版本号后，再写入数据，即使写入数据失败，A、B、C中所有的版本都提升1，对判断多数派是没有影响的。上述的先判断版本号，然后再将版本号加1的操作应当是原子性、不可中断的，否则就会出现脏数据。

写操作的有三个可能的返回点，一是写操作成功，数据被成功的写入数据结点A（或B）；二是写操作失败，原因是结点A通过自查发现本地的数据是脏数据，需要同步工具的修复；第三种返回结果是写操作失败，原因是结点B及C都没能成功提升版本号，结点B与C组成了一个多数派，认为结点A持有的是脏数据，不能进行更新。

相较写操作而言，读操作较为简单，可用图5表示。对一个数据结点而言，它自己本身是没有办法确定自己持有数据的正确性（或者是否是最新数据）的，因此它至少要与结点B（或C）发生一次通讯，来判断版本信息是否有冲突，这个通讯过程其实是Paxos算法中确定多数派的一个过程。读操作的流程大致如下：

1.         客户端读操作请求发送到结点A。

2.         结点A首先根据{VerAa, VerAb}自检本地数据是否是正确的数据：

1)        首先检查本地版本号信息，判断ver_a与ver_b的大小关系，条件为 A.ver_a >= A.ver_b；

2)        若条件成立，则说明结点A认为自己持有的是最新数据，它需要再联系一个同盟，继续执行；否则说明本地数据是过期的脏数据，返回读操作失败，让客户端向结点B申请读操作。

3.         向结点B请求版本号信息，询问B是否同自己的意见一致：

1)        结点B检查本地版本号信息，判断B.ver_a >= B.ver_b；

2)        若条件成立，则说明结点A持有的是最新信息，结点B与A组成多数派，可以不用再考虑仲裁结点C的意见；若条件不成立，则说明结点A与B发生版本冲突，还需要由结点C进行裁决；

3)        将检查结果返回给结点A。

4.         结点A等待结点B返回结果：

1)        若结点B返回B.ver_a < B.ver_b，则需再同结点C发生一次通讯，继续执行；

2)        若结点B返回B.ver_a >= B.ver_b的结果，则A、B已经通过查询请求，允许读出数据，返回读操作成功。

5.         结点A向结点C请求版本信息：

1)        仲裁结点C检查自己的版本号，判断本地C.ver_a >= C.ver_b；

2)        若条件成立，则说明结点A与C组成了多数派，继续执行；若条件不成立，则结点C与B组成了多数派，返回读失败；

3)        结点C将检查结果返回给结点A。

6.         结点A允许读出数据，返回读操作成功。

从效率上考虑，数据同步框架Quorum提供的读操作至少需要通过一次通讯，如果第一次通讯不能组成多数派，则需要再进行第二次通讯，因此在效率上确实会有所降低。然而这个过程却是必不可少的，因此只有当结点确认自己持有的是最新数据之后，才可以负责任地交给客户端，这个通讯过程是Paxos算法中组成多数派必需的。

读操作的返回结果只有两种可能：一种结果是结点A持有的是最新数据，允许读出，读操作成功；另外一种可能的结果是结点A持有的是脏数据，这样并非只单纯地返回读操作失败，而是让客户端去向结点B索取数据，而这个过程是无需再次进行通信的，因为已经可以肯定结点B持有的是正确的数据。因此读操作也分为尝试读及肯定读两种可能。

在最坏情况下，读一次数据至少要发生4次通信。通信次数是算法必需的，不可减少，因此改善这种问题只能从减少最坏情况出现的次数入手。

在数据同步框架Quorum系统中，双机数据会出现短时间的不一致，因此需要同步工具进行数据和版本号的同步。假设这样一种情况，客户端的一条对与Key对应的数据项的写请求被转发到了结点A，并且经过Quorum内部的通信之后，该写请求被允许，结点A的数据成为最新，稍后客户端又有一条关于该Key的读请求被转发到了数据结点B，但结点B的数据是脏数据，经过内部通信后，该读请求会被拒绝，要求客户端去向结点A申请数据。前面已经讨论过，这样的一个读请求至少要通过4次通信。然而倘若在客户端的读请求被发送之前，B结点的版本号与数据就已经被同步工具进行过同步，同结点A一样保持最新，那显然读请求会得到执行，而非拒绝。因此，同步操作是减少数据不一致，提高读写操作效率的一个重要步骤。同步操作的流程可用图6表示，以结点A为例，其具体的操作流程如下：

1.         扫描结点A（B）的流水日志，取出对Key的操作。

2.         确定系统中的多数派。

1)        广播询问A/B/C三结点，获得三结点各自版本号关系rA, rB和rC（rX = X.ver_a - X.ver_b)；

2)        根据版本号关系中多数派的结果，得到结点A还是结点B数据较新。

3.         数据复制。假定结点A数据较新，需要将结点A的数据复制到结点B，并更新A/B/C三结点的版本号（若结点B数据较新，采用相同的逻辑进行处理）：

1)        从结点A读出curr_data=A.data和curr_ver=A.ver_a，PUSH到B和C；

2)        结点B：若curr_ver < B.ver_a，则放弃；否则，先更新数据B.data = curr_data，再更新版本号 B.ver_a = B.ver_b = curr_ver；

3)        结点C：若curr_ver < C.ver_a，则放弃，否则更新版本号 C.ver_a = C.ver_b =curr_ver；

4)        最后结点A更新版本号，A.ver_b = curr_ver。

上述流程中所指的本地流水日志用来记录数据结点A（或B）上对某Key进行写操作的记录，因为读操作不涉及到数据的更新，因此不用记录到日志中。本地流水日志只是一个抽象的概念，具体实现因应用场景及需求而有所不同，Quorum框架本身不指定流水日志的格式。

在进行数据复制的过程中，如结点A的数据较新，PUSH到结点B进行更新，则应要求先更新数据，当数据更新成功后再更新版本号。因为在Quorum系统中，版本号直接决定了一个数据项的有效性，即使原始数据为脏数据，通过版本号也可以正确地识别，而不进行采纳。而版本号是不允许出现脏数据的，因为没有针对版本号的查错机制。

Claims (8)

1.一种云存储数据同步框架，包括应用于HDFS的经典的master/slave架构，其中Namenode节点是中心服务器，其特征是，所述云存储数据同步框架采用双中心服务器架构，双中心服务器同时在线服务。

2.根据权利要求1所述的云存储数据同步框架，所述Namenode节点有多个，每个Namenode节点都保存有最新的元数据。

3.根据权利要求1所述的云存储数据同步框架，所述云存储数据同步框架采用适应于三机Paxos算法。

4.根据权利要求1-3任一项所述的云存储数据同步框架的实现方法，包括写操作、读操作和同步操作。

5.根据权利要求4所述的实现方法，其特征是，所述写操作包括以下步骤：

步骤5.1，客户端写操作请求发送到结点A；

步骤5.2，结点A请求提升本地版本号；

步骤5.3，结点B/C接收请求，提升本地版本号；

步骤5.4，结点A等待结点B/C返回结果；

步骤5.5，结点A更新本地数据。

6.根据权利要求4所述的实现方法，其特征是，所述读操作包括以下步骤：

步骤6.1，客户端读操作请求发送到结点A；

步骤6.2，结点A自检本地数据是否是正确的数据；

步骤6.3，向结点B请求版本号信息，询问B是否同自己的意见一致；

步骤6.4，结点A等待结点B返回结果；

步骤6.5，结点A向结点C请求版本信息；

步骤6.6，结点A允许读出数据。

7.根据权利要求4所述的实现方法，其特征是，所述同步操作包括以下步骤：

步骤7.1，扫描结点A（B）的流水日志，取出对Key的操作；

步骤7.2，确定系统中的多数派；

步骤7.3，数据复制，假定结点A数据较新，需要将结点A的数据复制到结点B，并更新A/B/C三结点的版本号。

8.根据权利要求7所述的实现方法，其特征是，所述流水日志为数据结点上对Key进行写操作的记录。

Images