数据复制方法、装置、存储节点及可读存储介质与流程

1.本发明涉及分布式存储技术领域，具体而言，涉及一种数据复制方法、装置、存储节点及可读存储介质。


背景技术：

2.分布式存储系统设计，为了提升数据容灾冗余能力，或是扩展系统整体吞吐量，或是降低数据访问时延，通常采用将数据进行跨节点、跨数据中心，甚至是跨地域复制存储。
3.现有的数据复制方式，保证强一致性，在一定程度上以牺牲性能和可用性为代价，这种方式不适用于高副本冗余和跨数据中心、跨地域数据分布的应用场景。


技术实现要素：

4.本发明的目的在于提供了一种数据复制方法、装置、存储节点及可读存储介质，能够在保证强一致性的前提下，可以提供高吞吐量和高可用服务，很好地适用于高副本冗余和跨数据中心、跨地域数据分布的应用场景。
5.为了实现上述目的，本发明采用的技术方案如下：
6.第一方面，本发明提供一种数据复制方法，应用于分布式存储系统中第二从节点，所述第二从节点与第一从节点及主节点均通信连接，所述主节点与客户端通信连接，所述方法包括：接收所述第一从节点发送的数据同步请求，所述数据同步请求所需同步的数据为所述主节点基于所述客户端发送的更新请求同步至所述第一从节点的，所述主节点和所述第一从节点之间为同步复制，所述第一从节点和所述第二从节点之间为异步复制；记录所述数据同步请求的日志；将所述数据同步请求所需同步的数据更新至本地。
7.可选地，所述第一从节点发送的数据同步请求包括按照发送顺序发送的多个请求，所述记录所述数据同步请求的日志的步骤包括：
8.根据接收到的多个请求的接收顺序与所述发送顺序，判断是否存在正常请求或异常请求；
9.若存在所述正常请求，则记录所述正常请求的日志；
10.若存在所述异常请求，则向所述第一从节点发送指示重新发送所述异常请求的重发请求，以便在所述第二从节点接收到正常请求时记录正常请求的日志。
11.可选地，所述根据接收到的多个请求的接收顺序与所述发送顺序，判断是否存在正常请求或异常请求的步骤包括：
12.将接收的多个请求中接收顺序与对应的发送顺序一致的请求，判定为正常请求；
13.将发送的多个请求中除所述正常请求之外的其余请求判定为所述异常请求。
14.可选地，所述主节点存储有所述第二从节点上个周期最后处理的数据同步请求的历史标识；所述方法还包括：
15.获取本周期最后处理的数据同步请求的当前标识；
16.将所述当前标识发送至所述主节点，以使所述主节点将本地存储的所述当前标识
和所述历史标识之间的数据同步请求的日志删除。
17.可选地，所述第二从节点是所述分布式存储系统中多个第二从节点中的目标第二从节点，所述目标第二从节点还与监控节点通信连接，所述目标第二从节点最近一次处理的数据同步请求是最新的，所述方法还包括：
18.接收所述监控节点发送的切换请求，所述切换请求是所述监控节点检测到所述分布式存储系统中存在故障节点时发起的；
19.基于所述切换请求，建立所述目标第二从节点与所述分布式存储系统中非故障节点之间的同步关系。
20.可选地，所述故障节点为所述主节点，所述基于所述切换请求，建立所述目标第二从节点与所述分布式存储系统中非故障节点之间的同步关系的步骤包括：
21.基于所述切换请求，建立与所述第一从节点之间的同步复制关系；
22.接管所述第一从节点，以使所述第一从节点接管所述主节点。
23.可选地，所述故障节点为所述第一从节点，所述基于所述切换请求，建立所述目标第二从节点与所述分布式存储系统中非故障节点之间的同步关系的步骤包括：
24.基于所述切换请求，建立与所述主节点之间的同步复制关系；
25.接管所述第一从节点。
26.可选地，所述故障节点为所述主节点和所述第一从节点，所述基于所述切换请求，建立所述目标第二从节点与所述分布式存储系统中非故障节点之间的同步关系的步骤包括：
27.基于所述切换请求，接管所述主节点；
28.建立与除所述目标第二从节点之外的第二从节点中代理第二从节点之间的同步复制关系，以使所述代理第二从节点接管所述第一从节点，所述代理第二从节点为除所述目标第二从节点之外的第二从节点中最近一次处理的数据同步请求是最新的第二从节点。
29.可选地，所述方法还包括：
30.接收所述监控节点发送的所述分布式存储系统中新增加节点的节点信息；
31.根据所述节点信息，以全量同步方式将本地数据同步至所述新增加节点。
32.第二方面，本发明提供一种数据复制装置，应用于分布式存储系统中第二从节点，所述第二从节点与第一从节点及主节点均通信连接，所述主节点与客户端通信连接，所述装置包括：
33.接收模块，用于接收所述第一从节点发送的数据同步请求，所述数据同步请求所需同步的数据为所述主节点基于所述客户端发送的更新请求同步至所述第一从节点的，所述主节点和所述第一从节点之间为同步复制，所述第一从节点和所述第二从节点之间为异步复制；
34.记录模块，用于记录所述数据同步请求的日志；
35.更新模块，用于将所述数据同步请求所需同步的数据更新至本地。
36.第三方面，本发明提供一种存储节点，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如上述的数据复制方法。
37.第四方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述的数据复制方法。
38.与现有技术相比，本发明将分布式存储系统中的存储节点划分为主节点、第一从节点和第二从节点，客户端发送更新请求至主节点，主节点再将更新同步请求同步至第一从节点，第一从节点向主节点返回同步成功后，主节点向客户端返回更新请求处理成功，第一从节点再通过异步方式将数据同步请求发送至第二从节点，第二从节点将更新同步请求所需同步的数据更新至本地，由此，通过更新请求和数据同步请求相分离，既能实现更新请求得以及时响应，保证高吞吐量，又能实现主节点、第一从节点及第二从节点之间的数据复制，保证强一致性和高可用性。
附图说明
39.为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
40.图1为本发明实施例提供的主/备复制协议的原理示例图。
41.图2为本发明实施例提供的链式复制协议的原理示例图。
42.图3为本发明实施例提供的环形复制协议的原理示例图。
43.图4为本发明实施例提供的扩展后的环形复制协议的原理示例图。
44.图5为本发明实施例提供的存储节点的方框示意图。
45.图6为本发明实施例提供的数据复制方法流程示例图一。
46.图7为本发明实施例提供的数据复制方法流程示例图二。
47.图8为本发明实施例提供的数据复制方法流程示例图三。
48.图9为本发明实施例update请求的处理交互示例图。
49.图10为本发明实施例query请求的处理交互示例图。
50.图11为本发明实施例提供的数据复制方法流程示例图四。
51.图12为本发明实施例提供的数据复制装置的方框示意图。
52.图标：10-第二从节点；20-第一从节点；30-主节点；40-客户端；50-存储节点；51-处理器；52-存储器；53-总线；54-通信接口；100-数据复制装置；110-接收模块；120-记录模块；130-更新模块。
具体实施方式
53.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。
54.因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
55.应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一
个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
56.在本发明的描述中，需要说明的是，若出现术语“上”、“下”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。
57.此外，若出现术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
58.需要说明的是，在不冲突的情况下，本发明的实施例中的特征可以相互结合。
59.在分布式存储系统中，为了提升数据容灾冗余能力，或是扩展系统整体吞吐量，或是降低数据访问时延，通常采用的复制原理包括leader-based复制协议和leaderless复制协议，前者将存储节点分为主备节点，后者的存储节点无主备之分。
60.primary/backup主/备复制协议属于leader-based复制协议，primary/backup主/备复制协议中，primary节点(主节点)负责确定update/query(更新/查询)请求执行顺序，并采用同步/异步复制方式，与backups节点(备节点)保持数据同步，请参照图1，图1为本发明实施例提供的主/备复制协议的原理示例图，图1中，选择一个副本存储节点作为primary节点，其余副本存储节点全部作为backup节点，primary节点主要负责：
61.i)接收并确定客户端client发送的update/query请求的执行顺序；
62.ii)向backup节点分发update请求，并等待正常backup节点响应；
63.iii)响应client请求。
64.primary/backup复制协议中的服务故障恢复分为以下两类：
65.1)primary节点故障恢复
66.primary节点故障会导致client前台业务中断，直到监控节点重新选择并通知某一个backup节点提升为新的primary节点为止，业务中断持续时间在数十秒不等，主要开销在于服务故障检测和消息交互。而且，在primary/backup间采用异步复制的情况下，primary节点故障前已接收、但未分发的update请求，会丢失，导致数据不一致。
67.2)backup节点故障恢复
68.任一backup节点故障会导致update/query请求时延增加，直到监控节点检测到backup节点故障，并通知primary为止。query请求时延增加的原因，在于其需要等待前一个update请求执行完成。update/query请求时延增加数秒不等，主要开销在于服务故障检测和消息交互。特别地，在primary/backup间采用同步复制的情况下，任一backup节点故障，可能会导致前台业务中断。因此，实际应用中，通常配置半同步策略。
69.primary/backup复制协议，具有低复制延迟的优势，复制演示只取决于响应最慢的backup节点，但是，query请求的时延较高，且primary节点宕机存在业务中断和数据丢失的风险。
70.chain replication链式复制协议属于leaderless复制协议，chain replication复制协议中，将多个数据副本的存储节点顺序组成链表，update请求由head存储节点负责处理，并沿着先进先出fifo(first in first out)链串行化传播，query请求和reply响应由tail存储节点负责。请参照图2，图2为本发明实施例提供的链式复制协议的原理示例图，图2中，所有副本存储节点顺序组成fifo链表，链表头节点称为head节点，链表尾节点称为
tail节点，其主要负责的处理为：
71.i)所有reply响应由tail节点负责；
72.ii)head节点负责接收并确认client发送的update请求执行顺序，并沿着fifo链传递，直至tail节点；
73.iii)tail节点负责接收client发送的query请求，并按照一定顺序处理update/query请求。update请求处理完成后，会向其上游节点发送ack消息，该ack消息会沿着反向fifo链传递，直至head节点为止。
74.chain replication协议服务故障恢复，分为以下三类：
75.1)head节点故障恢复
76.head节点故障，query请求不受影响，但update请求业务中断，直到监控节点检测到head节点故障，并通知其下游节点提升为新head为止。
77.2)middle节点(除head节点和tail节点之外的其余节点)故障恢复
78.任一middle节点故障，query请求不受影响，但update请求时延会增加，直到监控节点检测到middle节点故障，并通知其下游节点和上游节点为止。为了保证强一致性，需要保证middle节点故障前已接收、但未传递的update请求，能够继续沿着fifo链表传递，因为这些请求已经在链表前面的所有节点中已完成处理。
79.3)tail节点故障恢复
80.tail节点故障会导致前台业务中断，直到监控节点通知其上游节点提升为新的tail节点为止。update请求业务中断原因，在于新tail节点无法确认哪些请求需要回复reply响应。
81.chain replication链式复制协议，具有强一致性和低query请求时延的优势，允许同时宕机n-1个节点而不影响数据可用性，但复制延迟较高，复制延迟等同于所有副本存储节点的复制时延总和。
82.上述两种方式要么复制延迟低、但query请求的时延较高、要么query请求的时延低、但复制延迟高，两者都不适用于高副本冗余和跨数据中心、跨地域数据分布的应用场景，有鉴于此，本实施例提供一种数据复制方法、装置、存储节点及可读存储介质，在保证强一致性的前提下，可以提供高吞吐量和高可用服务，尤其适用于高副本冗余和跨数据中心、跨地域数据分布的应用场景，下面将对其进行详细描述。
83.与上文描述的primary/backup复制协议和chain replication链式复制协议不同，本实施例提出的数据复制方法、装置、存储节点及可读存储介质是基于本实施例提出了环形复制ring replication协议，其主要创新点在于，将前台update/query请求处理逻辑与后台数据复制逻辑分离，实现对主副本存储节点进行负载缓解offload，最终实现在保证强一致性的前提下，能够提供高吞吐量和高可用服务。请参照图3，图3为本发明实施例提供的环形复制协议的原理示例图一，图3中，任选两个数据副本的存储节点分别作为master节点(主节点30)和first slave节点(第一从节点20)。作为一种较优实现方式，master节点和first slave节点可以位于同一机房或同一数据中心。master节点与first slave节点之间通信连接，采用同步复制方式保持数据同步，其余数据副本的存储节点全部作为second slave节点(第二从节点10)，second slave节点可以位于不同数据中心、不同地域，first slave节点与second slave节点之间通信连接，采用异步复制方式保持数据同步。
84.所有update请求均由master节点处理。master节点接收到client(客户端40)发送的update请求，先记录复制日志，再后台执行修改操作，同时同步复制给first slave节点。直到接收到first slave节点的响应，才回复client请求响应。
85.first slave节点接收到master节点同步的update请求，先记录复制日志，完成后回复master节点同步请求响应。然后，以后台任务执行修改操作，并以异步复制同步给所有的second slave节点。
86.second slave节点接收到first slave节点同步的update请求，同样记录复制日志，再后台执行修改操作。
87.query请求由master节点和first slave节点共同处理。可以根据client选择由master节点或是first slave节点处理query请求。master节点与first slave节点具有完全一致的数据副本，因此，ring replication复制协议具有强一致性。在对强一致性要求不太高、对系统整体吞吐量要求高的场景下，也可以将query请求分发给second slave节点处理，但此时会牺牲强一致性，只提供单调读一致性保证。
88.second slave节点周期性向master节点发送删除日志trim log请求，该请求携带由当前已完成的update请求的标识。master节点记录所有second slave节点当前最新的复制日志的标识，然后删除本地过期的复制日志，并在下一次发送给first slave的同步请求消息中携带该复制日志的标识。
89.图3的环形复制协议的原理还可以根据需要扩展成为多环结构，请参照图4，图4为本发明实施例提供的扩展后的环形复制协议的原理示例图，图4中，其中一个second slave节点进一步做了扩展，该second slave节点同时作为扩展环的master节点，和扩展的第一从节点之间同步复制，扩展的第一从节点和扩展的第二从节点之间进行异步复制。
90.需要说明的是，图4只是一种扩展方式的示例，事实上，可以根据场景需要进行对应的扩展，例如，将second slave节点同时作为扩展的master节点和扩展的第一从节点。
91.还需要说明的是，上述3种复制协议中的数据备份的存储节点不一定包括分布式存储系统中的所有存储节点，可以只包括分布式存储系统中的部分存储节点，当数据副本存在于分布式存储系统中的所有存储节点，此时，数据备份的存储节点为分布式存储系统中的所有存储节点，当数据副本存在于分布式存储系统中的部分存储节点，此时数据备份的存储节点为存储数据副本的存储节点。
92.本实施例还提供了图3和图4中第二从节点的方框示意图，请参照图5，图5为本发明实施例提供的存储节点50的方框示意图，存储节点50可以是图3和图4中的第二从节点。存储节点50包括处理器51、存储器52、总线53、通信接口54。处理器51、存储器52通过总线53连接，处理器51通过通信接口54与第一从节点20或者主节点30通信。
93.处理器51可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器51中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器51可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、网络处理器(network processor，简称np)等；还可以是数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
94.存储器52用于存储程序，例如本发明实施例中的数据复制装置100，数据复制装置
100均包括至少一个可以软件或固件(firmware)的形式存储于存储器52中的软件功能模块，处理器51在接收到执行指令后，执行所述程序以实现本发明实施例中的数据复制方法。
95.存储器52可能包括高速随机存取存储器(ram：random access memory)，也可能还包括非易失存储器(non-volatile memory)。可选地，存储器52可以是内置于处理器51中的存储装置，也可以是独立于处理器51的存储装置。
96.总线53可以是isa总线、pci总线或eisa总线等。图5仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
97.基于图3和图4的环形复制协议的原理，本实施例还提供了利用该环形复制协议的原理实现的数据复制方法，数据复制方法应用于图3和图4中的第二从节点，请参照图6，图6为本发明实施例提供的数据复制方法流程示例图一，该方法包括以下步骤：
98.步骤s100，接收第一从节点发送的数据同步请求，数据同步请求所需同步的数据为主节点基于客户端发送的更新请求同步至第一从节点的，主节点和第一从节点之间为同步复制，第一从节点和第二从节点之间为异步复制。
99.在本实施例中，客户端向主节点发送更新请求，主节点记录日志，向第一从节点发送数据同步请求，该数据同步请求所需同步的数据为主节点需要根据更新请求更新的数据，第一从节点接收数据同步请求后，记录日志后发送响应消息响应主节点，主节点收到第一从节点的响应消息后，响应客户端。此时，该更新请求处理完毕，即，主节点和第一从节点之间是同步复制，此过程是更新请求的处理过程，以确保数据的强一致性。
100.在本实施例中，第一从节点的后台任务异步将所需同步的数据同步至本地，然后，再将数据同步请求发送至第二从节点，以将所需同步的数据同步至第二从节点，即，所需同步的数据写入第一从节点，及从第一从节点同步至第二从节点，这两个过程均是异步复制，此过程是数据同步的处理过程，由此，将更新请求的处理过程和数据同步的数据过程分离，避免了所需同步的数据全部同步至第一从节点和第二从节点之后才能响应客户端导致的高延迟。
101.步骤s101，记录数据同步请求的日志。
102.在本实施例中，记录日志的目的在于在出现节点故障时，可以根据记录的日志将所需同步的数据正确地进行更新。作为一种具体实施方式，可以为每一更新请求设置一个标识id，每一更新请求的日志id及对应的数据同步请求的日志id都是相同的，例如，客户端向主节点发送更新请求a，请求a对应的日志id为1，主节点向第一从节点发送数据同步请求a’以同步a需要同步的数据，第一从节点接收a’后，记录日志，对应的日志id也为1，第一从节点向第二从节点发送同步请求a’，第二从节点接收a’后，记录日志，对应的日志id也为1。
103.步骤s102，将数据同步请求所需同步的数据更新至本地。
104.在本实施例中，当第二从节点将需同步的数据更新至本地后，此时，主节点、第一从节点及第二从节点上均更新了需同步的数据，三者数据是一致的。
105.本实施例提供的上述方法，通过更新请求和数据同步请求相分离，既能实现更新请求得以及时响应，保证高吞吐量，又能实现主节点、第一从节点及第二从节点之间的数据复制，保证强一致性和高可用性。
106.在本实施例中，第一从节点可以批量地向第二从节点发送请求进行数据同步，为了避免第一从节点向第二从节点批量发送请求时出现故障，导致第二从节点无法正确地将
需同步的数据更新至本地，导致第一从节点和第二从节点上的数据不一致，在图6的基础上，本实施例还提供了一种记录数据同步请求的日志的具体实现方式，请参照图7，图7为本发明实施例提供的数据复制方法流程示例图二，步骤s101包括以下子步骤：
107.子步骤s1010，根据接收到的多个请求的接收顺序与发送顺序，判断是否存在正常请求或异常请求。
108.在本实施例中，第一从节点发送的数据同步请求包括按照发送顺序发送的多个请求，该发送顺序也即是第二从节点需要根据数据同步请求进行数据更新的顺序，若第二从节点的接收顺序与发送顺序不一致，则请求发送过程中可能出现异常，此时，需要识别出其中发生异常的请求，以针对异常的请求进行处理，例如，重发异常的请求。
109.作为一种具体实施方式，判断是否存在正常请求或异常请求的过程可以是：
110.将接收的多个请求中接收顺序与对应的发送顺序一致的请求，判定为正常请求；
111.将发送的多个请求中除正常请求之外的其余请求判定为异常请求。
112.在本实施例中，多个请求中可以是所有请求接收顺序与对应的发送顺序一致均一致，此时，多个请求中所有请求都是正常请求，多个请求中也可以是部分请求接收顺序与对应的发送顺序一致，此时，一致的这部分请求为正常请求，其余请求为非正常请求。例如，第一从节点按发送顺序为a、b、c、d发送请求，第二从节点接收的请求为a、b、d，则a、b为正常请求，c、d为异常请求。
113.子步骤s1011，若存在正常请求，则记录正常请求的日志。
114.子步骤s1012，若存在异常请求，则向第一从节点发送指示重新发送异常请求的重发请求，以便在第二从节点接收到正常请求时记录正常请求的日志。
115.在本实施例中，若a、b为正常请求，c、d为异常请求，则记录a、b请求的日志，并且请求第一从节点重新发送c、d请求，当第二从节点接收c、d请求的接收顺序与发送c、d请求的发送顺序一致时，则记录c、d请求的日志。
116.在本实施例中，作为一种具体实施方式，记录正常请求的日志可以预写wal(write-ahead logging，wal)方式实现，wal技术，是指先写日志和内存，等不忙的时候再写硬盘，其作用是将随机写变成顺序写，减少写盘消耗。为每个请求分配一个唯一自增标识id，同一个请求的日志无论是主节点、第一从节点、第二从节点记录的与该请求对应的日志id都是相同的，记录日志的方式均可以是wal方式。
117.在本实施例中，为了及时将主节点上记录的已经同步完成的日志删除，本实施例还提供了一种对应的处理方式，请参照图8，图8为本发明实施例提供的数据复制方法流程示例图三，该方法包括以下步骤：
118.步骤s103，获取本周期最后处理的数据同步请求的当前标识。
119.在本实施例中，第二从节点可以是一个或者多个，每一第二从节点均周期性地向主节点发送日志删除trim log请求，该请求携带有对应第二从节点本周期最后处理的数据同步请求的标识，即当前标识。
120.步骤s104，将当前标识发送至主节点，以使主节点将本地存储的当前标识和历史标识之间的数据同步请求的日志删除。
121.在本实施例中，主节点存储有每一第二从节点上个周期最后处理的数据同步请求的历史标识，当前标识和历史标识之间的日志为已经同步的请求的日志，可以将其删除。
122.在本实施例中，作为一种具体实施方式，主节点可以将日志记录在文件中，文件大小可以预设为64mb，当一个文件写满后，自动创建一个新文件，再将日志记录在新文件中，对于已经同步完成的请求的日志，可以将其删除，在第二从节点为多个时，为了避免频繁操作文件，可以在整个文件的日志对应的请求都已经被所有第二从节点均处理完毕了，再将该文件删除。例如，一个文件可以记录10000条日志，文件1记录的日志是1～10000，当所有第二从节点均已经把第10000条日志需要更新的数据更新完毕后，就可以将文件1删除了。
123.还需要说明的是，主节点在下一次发送给第一从节点的同步请求消息中携带该当前标识，以使第一从节点将该当前标识及其之前的日志删除。
124.本实施例提供的上述方法，通过第二从节点周期性地通知主节点本节点更新的最新的日志，以使主节点及时地将不再需要的日志删除，及时释放其占用的空间。
125.为了更清楚地说明update请求和query请求的处理流程，本实施例以具体例子进行说明。
126.以数据副本的存储节点为5个为例，5个存储节点中1个master节点，1个first slave节点，3个second slave节点。每个节点的后端采用rocksdb存储引擎，所有键值对kv pairs均存储在机械硬盘中。复制日志采用wal方式，按照每个日志文件64mb大小的粒度保存在固态硬盘中。
127.请参照图9，图9为本发明实施例update请求的处理交互示例图，交互过程如下：
128.s11：client向master节点发送update请求r；
129.s12：master节点收到请求r后，为其分配一个唯一的日志id，并记录复制日志；
130.s13：同步复制给first slave节点，并等待响应；
131.s14：first slave节点收到请求r后，直接记录复制日志；
132.s15：first slave节点完成后向master节点回复ack(r)响应；
133.s16：master节点收到ack(r)响应后，响应client请求；
134.s17：master节点以后台任务方式逐条重放复制日志，对后端rocksdb实施修改；
135.s18：first slave节点采用异步复制方式，将复制日志同步给所有的second slave，同时重放复制日志，对后端rocksdb实施修改；
136.s19：second slave节点收到请求r，直接记录复制日志，然后对后端rocksdb实施修改。
137.请参照图10，图10为本发明实施例query请求的处理交互示例图，交互过程如下：
138.s21：client根据自己的id，选择master节点，还是first slave节点，以选择master节点为例，向master节点发送query请求r
‘
；
139.s22：master节点收到请求r
‘
后，在rocksdb中查找，
140.s23：响应client请求。
141.在本实施例中，基于图3和图4的环形复制协议的原理，为了在各节点发生故障的情况下，仍然不中断业务，保证高可靠性，本实施例还提供了针对各种故障进行处理的方法。请参照图11，图11为本发明实施例提供的数据复制方法流程示例图四，该方法包括以下步骤：
142.步骤s105，接收监控节点发送的切换请求，切换请求是监控节点检测到分布式存储系统中存在故障节点时发起的。
143.在本实施例中，利用监控节点可以实现服务故障检测、恢复，监控节点负责于所有节点保持心跳保活。监控节点可以是独立于主节点、第一从节点、第二从节点的独立设备，也可以是部署于主节点、第一从节点、第二从节点的软件，如zookeeper，该软件可以及时地获知各节点的运行情况。
144.在本实施例中，故障节点可以是主节点、第一从节点、第二从节点中的至少一个。
145.步骤s106，基于切换请求，建立目标第二从节点与分布式存储系统中非故障节点之间的同步关系。
146.在本实施例中，目标第二从节点是分布式存储系统中多个第二从节点中的一个，目标第二从节点还与监控节点通信连接，目标第二从节点最近一次处理的数据同步请求是最新的，以每一请求对应一个日志id、且日志id递增为例，目标第二从节点最近一次处理的数据同步请求的日志id是最大的。
147.在本实施例中，非故障节点也可以是主节点、第一从节点、第二从节点中的至少一个。同步关系包括主节点和第一从节点之间的同步复制关系及第一从节点和第二从节点、第二从节点和主节点之间的异步复制关系。
148.服务故障至少包括以下四类：(1)主节点故障；(2)第一从节点故障；(3)主节点和第一从节点均故障；(4)第二从节点故障，下面将对这四种故障处理方式一一介绍。
149.(1)主节点故障的处理方式为：
150.基于切换请求，建立与第一从节点之间的同步复制关系；
151.接管第一从节点，以使第一从节点接管主节点。
152.在本实施例中，监控节点向目标第二从节点发送切换请求，目标第二从节点基于该切换请求建立与第一从节点之间的同步复制关系，目标第二从节点接管第一从节点，目标第二从节点成为新的第一从节点，监控节点向第一从节点发送切换请求，该切换请求携带有新的第一从节点的信息，第一从节点基于该切换请求接管主节点。
153.由上述处理流程可知，主节点故障，query请求不受影响，update请求业务短暂中断，直到监控节点检测到主节点故障，重新挑选目标第二从节点提升为新的第一从节点，并通知原第一从节点提升为新主节点为止。由于第一从节点与主节点拥有完全一致的数据副本，因此，业务中断持续时间非常短，甚至可以做到0中断。
154.(2)第一从节点故障的处理方式为：
155.基于切换请求，建立与主节点之间的同步复制关系；
156.接管第一从节点。
157.监控节点向目标第二从节点发送切换请求，目标第二从节点基于该切换请求建立与主节点之间的同步复制关系，接管第一从节点，目标第二从节点成为新的第一从节点，监控节点向主节点发送新的第一从节点的信息。
158.由上述处理流程可知，第一从节点故障，query请求不受影响，update请求时延增加，直到监控节点检测到第一从节点故障，并重新挑选目标第二从节点提升为新的第一从节点为止。
159.(3)主节点和第一从节点均故障的处理方式为：
160.基于切换请求，接管主节点；
161.建立与除目标第二从节点之外的第二从节点中代理第二从节点之间的同步复制
关系，以使代理第二从节点接管第一从节点，代理第二从节点为除目标第二从节点之外的第二从节点中最近一次处理的数据同步请求是最新的第二从节点。实际上，目标第二从节点和代理第二从节点的最近一次处理的数据同步请求的id可以是相同的，也可以是不同的，例如，第二从节点为3个，分别为节点a、b、c，若其各自最近一次处理的数据同步请求的id为3,3,3，此时，可以从3个第二从节点中任选两个，分别作为目标第二从节点和代理第二从节点，若其各自最近一次处理的数据同步请求的id为3,2,1，则将节点a作为目标第二从节点，将节点b作为代理第二从节点。
162.在本实施例中，代理第二从节点为除目标第二从节点之外的第二从节点中最近一次处理的数据同步请求是最新的第二从节点，监控节点向目标第二从节点发送切换请求，目标第二从节点基于该切换请求接管主节点，目标第二从节点建立与代理第二从节点之间的同步复制关系，成为新的主节点，监控节点向代理第二从节点发送切换请求，代理第二从节点基于该切换请求接管第一从节点，成为新的第一从节点，需要说明的是，监控节点向目标第二从节点发送切换请求时，会携带有新的第一从节点的信息，监控节点向代理第二从节点发送切换请求时，会携带有新的主节点的信息。
163.还需要说明的是，在副本数据的存储节点跨数据中心、跨地域分布的应用场景中，通常是为了支持异地容灾备份，原则上，本地数据中心所有的副本数据的存储节点同时故障的情况下，以手动方式恢复异地副本的存储节点为最佳。若是为了支持异地双活，以降低访问时延，则需要采用完全不同的分布式技术，比如：自动冲突检测技术等。
164.(4)第二从节点故障
165.监控节点在监测到任一第二从节点故障时，通知第一从节点，后续第一从节点不再向该第二从节点发送数据同步请求，以向该第二从节点同步数据。
166.由上述处理流程可知，任一第二从节点故障，update/query请求均不受影响。原因在于，环形复制协议将前台业务处理逻辑与后台数据复制逻辑分离，主节点负责前台业务处理逻辑，第一从节点主要负责后台数据复制逻辑。
167.由上述故障处理流程可知，基于ring replication的数据复制方法与primary/backup协议及chain replication在以下几个方面具有明显优势：
168.1)吞吐量
169.对于primary/backup协议，所有update/query请求均由primary处理，其时延取决于响应最慢的backup节点，且primary节点容易成为瓶颈。对于chain replication协议，update/query请求分离给head、tail节点处理，query时延较短，但update时延较高，等于所有副本节点的时延总和。ring replication协议同样采用分离update/query请求策略，update请求由master节点处理，时延只取决于first slave节点，query请求分发给master节点和first slave节点。因此，ring replication协议整体吞吐量最高(约2倍)，update请求时延略优于primary/backup协议的时延，远低于chain replication协议的时延，而query请求时延与chain replication的相当，优于primary/backup的时延。
170.2)复制拓扑
171.对于primary/backup协议和chain replication协议，前台业务处理逻辑和后台数据复制逻辑完全耦合，且对副本节点的物理拓扑无感知，在副本数据跨数据中心、跨地域分布的应用场景，会严重影响前台业务的整体吞吐量和时延。而ring replication将前台
业务处理逻辑与后台数据复制逻辑分离，可以很好的处理这种应用场景。实际应用中，可以将master和first slave部署在同一数据中心，second slave异地部署，以支持跨数据中心、跨地域容灾备份。
172.3)容错能力
173.对于primary/backup协议，primary节点故障可能会导致数据丢失和业务中断，其安全级别服务可用级别最低。对于chain replication，允许宕机n-1个节点而不影响数据可用性，其安全级别和服务可用级别最高。ring replication介于两者之间，只有在master节点和first slave节点同时故障情况下，才可能影响前台业务。
174.在本实施例中，当故障节点恢复后，为了及时使其恢复正常或者有新的节点作为副本数据的存储节点加入时，使其及时发挥副本备份的作用，本实施例还提供了一种应用于目标第二从节点的具体处理方式：
175.首先，接收监控节点发送的分布式存储系统中新增加节点的节点信息。
176.在本实施例中，新增加节点可以是首次加入分布式存储系统中的节点，也可以是之前发生故障的主节点、第一从节点、第二从节点等，无论是哪种节点，都将其按照首次加入分布式存储系统中的节点进行处理。
177.其次，根据节点信息，以全量同步方式将本地数据同步至新增加节点。
178.在本实施例中，目标第二从节点根据节点信息，以全量同步方式将目标第二从节点的数据同步至新增加节点，以使新增加节点作为一个新的第二从节点加入至分布式存储系统中。
179.为了执行上述实施例及各个可能的实施方式中的相应步骤，下面给出一种数据复制装置100的实现方式。请参照图12，图12为本发明实施例提供的数据复制装置的方框示意图。需要说明的是，本实施例所提供的数据复制装置100，其基本原理及产生的技术效果和上述实施例相同，为简要描述，本实施例部分未提及指出。
180.数据复制装置100包括接收模块110，记录模块120及更新模块130。
181.接收模块110，用于接收第一从节点发送的数据同步请求，数据同步请求所需同步的数据为主节点基于所述客户端发送的更新请求同步至第一从节点的，主节点和第一从节点之间为同步复制，第一从节点和第二从节点之间为异步复制。
182.记录模块120，用于记录数据同步请求的日志。
183.可选地，记录模块120具体用于：根据接收到的多个请求的接收顺序与发送顺序，判断是否存在正常请求或异常请求；若存在正常请求，则记录正常请求的日志；若存在异常请求，则向第一从节点发送指示重新发送异常请求的重发请求，以便在第二从节点接收到正常请求时记录正常请求的日志。
184.可选地，记录模块120在用于根据接收到的多个请求的接收顺序与发送顺序，判断是否存在正常请求或异常请求时，具体用于：将接收的多个请求中接收顺序与对应的发送顺序一致的请求，判定为正常请求；将发送的多个请求中除所述正常请求之外的其余请求判定为异常请求。
185.更新模块130，用于将数据同步请求所需同步的数据更新至本地。
186.可选地，主节点存储有第二从节点上个周期最后处理的数据同步请求的历史标识；更新模块130还用于：获取本周期最后处理的数据同步请求的当前标识；将当前标识发
送至主节点，以使主节点将本地存储的当前标识和历史标识之间的数据同步请求的日志删除。
187.可选地，第二从节点是分布式存储系统中多个第二从节点中的目标第二从节点，目标第二从节点还与监控节点通信连接，目标第二从节点最近一次处理的数据同步请求是最新的，更新模块130还用于：接收监控节点发送的切换请求，切换请求是监控节点检测到分布式存储系统中存在故障节点时发起的；基于切换请求，建立目标第二从节点与分布式存储系统中非故障节点之间的同步关系。
188.可选地，所述故障节点为主节点，更新模块130在用于基于切换请求，建立目标第二从节点与分布式存储系统中非故障节点之间的同步关系时，具体用于：基于切换请求，建立与第一从节点之间的同步复制关系；接管第一从节点，以使第一从节点接管主节点。
189.可选地，故障节点为第一从节点，更新模块130在用于基于切换请求，建立目标第二从节点与分布式存储系统中非故障节点之间的同步关系时，具体用于：基于切换请求，建立与主节点之间的同步复制关系；接管第一从节点。
190.可选地，故障节点为主节点和第一从节点，更新模块130在用于基于切换请求，建立目标第二从节点与分布式存储系统中非故障节点之间的同步关系时，具体用于：基于切换请求，接管主节点；建立与除目标第二从节点之外的第二从节点中代理第二从节点之间的同步复制关系，以使代理第二从节点接管第一从节点，代理第二从节点为除目标第二从节点之外的第二从节点中最近一次处理的数据同步请求是最新的第二从节点。
191.可选地，更新模块130还用于：接收监控节点发送的分布式存储系统中新增加节点的节点信息；根据节点信息，以全量同步方式将本地数据同步至新增加节点。
192.本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述的数据复制方法。
193.综上所述，本发明实施例提供了一种数据复制方法、装置、存储节点及可读存储介质，应用于分布式存储系统中第二从节点，所述第二从节点与第一从节点及主节点均通信连接，主节点与客户端通信连接，所述方法包括：接收第一从节点发送的数据同步请求，数据同步请求所需同步的数据为主节点基于客户端发送的更新请求同步至第一从节点的，主节点和第一从节点之间为同步复制，第一从节点和第二从节点之间为异步复制；记录数据同步请求的日志；将数据同步请求所需同步的数据更新至本地。与现有技术相比，本实施例提供的数据复制方法至少具有以下优势：1)在保证强一致性的前提下，提供更高的吞吐量和更低时延；2)无单点故障，提供更优的容错能力；3)在不牺牲前台业务性能的前提下，能支持更高的副本冗余；4)更好的网络容忍能力，适用于跨数据中心、跨地域分布数据的应用场景。
194.以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。