基于外部观察者组的分布式数据库节点同步的方法和装置

摘要

本申请提供了用于基于外部观察者进行分布式数据库节点同步的方法。所述方法包括：当分布式数据库集群出故障时，所述外部观察者组对整个数据库集群进行统一的存活判决；基于所述外部观察者组，对所述分布式数据库集群中的存活节点进行投票，选举出主节点，其余的存活节点为备节点；将所述主节点的数据复制到所述备节点，进行同步。本申请实现了在一半数量的节点存活的情况下，通过外部观察者组仍然能够选举出主节点。

说明书

技术领域

本申请涉及分布式数据库，更具体地说，涉及基于外部观察者组进行分布式数据库节点同步的方法和装置。

背景技术

分布式数据库的数据高可靠通常基于数据副本冗余来实现，通过将业务数据同时存储在多个数据副本中，确保在数据主副本故障场景下，分布式数据库集群依然可用并且数据安全。

目前主流的节点强一致同步协议是基于多数派的分布式一致性协议，例如，Paxos协议和Raft协议等。

Raft协议是目前使用比较广泛的分布式一致性协议。在Raft协议中，每个节点都有状态，且状态机是确定的，不同状态对应于不同的一系列操作。在状态机的基础上增加同步复制的功能，在同步复制的时候，每个节点可以在缓存或者磁盘保存同步复制的位置和顺序。简言之，多个节点从相同的初始状态开始，执行相同的一串命令，产生相同的最终状态。

在Raft协议中的节点状态有以下三种：候选者(candidate)、领导者(leader)、追随者(follower)。其中，候选者表示该节点是投票选举主节点的候选人，候选人既有可能成为领导者，也有可能成为追随者；领导者表示该节点是选举出的主节点，主要处理与客户端的通讯和交互，还有与追随者的数据同步与心跳机制的维护；追随者表示该节点是备节点，主要负责转发客户端的请求给主节点，然后保持与主节点的数据同步。

Raft协议采用“过半选举”的机制来选举领导者和追随者。以部署三个节点(N＝3)为例，起初，这三个节点首先进入候选者状态，各自创建一个Term周期；然后，三个节点在Term周期内投票，根据“过半选举”机制，当某个节点得到大于N/2的票数才能成为领导者；成为领导者的节点向其余节点发送心跳，其余节点从候选者转变为追随者。同样采用“过半选举”机制的还有例如zookeeper集群，在此不再赘述。

假设节点B是领导者，节点A和C是追随者，客户端向节点B发送数据，节点B在收到指令的时候开始进行数据存储和数据同步，这个时候并不是直接存储，而是采用两阶段提交。所述两阶段提交的具体过程包括：在第一阶段，领导者节点B收到客户端数据请求，对所有追随者节点A和C发起请求；追随者节点A和C收到领导者节点B的请求，确认自己可以执行数据存储，回复Ack响应给领导者节点B；领导者节点B收到Ack响应之后判断，如果有超过一半数量的节点返回了可以执行的Ack，则领导者节点B存储数据并记录日志，返回给客户端成功的响应；然后，在第二阶段，领导者节点B再次向所有追随者节点A和C发送确认执行的请求，追随者节点A和C存储数据，并记录日志。需要注意，追随者节点A和C也接受客户端请求，但不处理请求，而是将请求转发给领导者节点B处理。

传统上，通过多数派(包括领导者和追随者)数据写入确认和多数派节点故障选主，从协议层面确保在故障节点的数量小于节点总数一半的情况下，数据副本间数据强一致高可靠。但这种传统技术通常有如下弊端：

(1)严格要求只有在超过一半的节点存活的情况下才能选主，导致分布式数据库集群进行跨机房多中心部署时必须要求至少3个机房，成本高昂；

(2)如果在同城双活部署的情况下，主机房A中的节点数量多于备机房B的节点数量，当机房A故障时，整个数据库集群将不可用，并且可能丢失数据。

因此，需要提供允许在一半数量节点出故障的情况下依然保证数据库集群数据强一致，保证高度的数据完整性和数据零丢失。此外，期望分布式数据库集群可以构建同城双活单一大集群，无需3机房就可实现分布式数据库集群跨机房多活高可靠，大幅降低成本，同时依然确保了数据库集群数据的高可靠与强一致。

发明内容

提供本申请内容以便介绍一组概念，这组概念将在以下的具体实施方式中做进一步描述。本申请内容并非旨在标识所保护主题的关键特征或必要特征，也不旨在用于限制所保护主题的范围。

针对传统分布式协议存在的成本高昂且不适用通常双活部署的问题，本申请提出了基于外部观察者进行分布式数据库的节点强一致同步的方法和装置。本申请在确保分布式数据库集群多个节点强一致的前提下，通过引入外部观察者组的调度节点，允许当一半数量的节点出故障的情况下依然保证分布式数据库集群中的节点数据强一致、故障切换数据零丢失。分布式数据库集群可以基于本申请提供的技术方案构建同城双活单一大集群，在无需三个机房的情况下就可以实现分布式数据库集群跨机房多活高可靠性，大幅降低成本，同时依然确保了分布式数据库集群的数据高可靠性与强一致性。

本申请的目的包括：支持在分布式数据库集群中的一半数量的节点出故障的情况下，基于外部观察者组自动进行一半数量的节点投票选举主节点，并且确保数据零丢失，非常适用于通常同城双活单一大集群部署。

根据本申请实施例的一个方面，提供一种用于基于外部观察者进行分布式数据库集群节点同步的方法，包括：当分布式数据库集群出故障时，所述外部观察者组对整个分布式数据库集群进行统一的存活判决；基于所述外部观察者组，对所述分布式数据库集群中的存活节点进行投票，选举出主节点，其余的存活节点为备节点；将所述主节点的数据复制到所述备节点，进行同步。

可选地，在上述方法的一个示例中，所述存活判决包括：判断所述分布式数据库集群中的机房或节点是否可用。

可选地，在上述方法的一个示例中，所述主节点到所述备节点的数据同步是基于半同步复制协议来实现的。

可选地，在上述方法的一个示例中，所述主节点到所述备节点的数据同步是基于附加条目(AppendEntries)远程过程调用(RPC)来实现的。

可选地，在上述方法的一个示例中，还包括：所述主节点会等待所述主节点和所述备节点对AppendEntries RPC请求做出响应后完成提交。

可选地，在上述方法的一个示例中，还包括：优化所述AppendEntries RPC的两阶段过程为一阶段过程。

可选地，在上述方法的一个示例中，所述优化包括：省略AppendEntries RPC的两个阶段中的第二阶段，直接在第一阶段完成时在所述备节点进行本地提交。

可选地，在上述方法的一个示例中，包括：如果所述主节点没有达成所述主节点所述备节点的一致变更，则将通过数据闪回操作回退。

根据本申请的实施例的另一方面，提供一种用于基于外部观察者组进行分布式数据库集群的节点同步的装置，包括：用于当分布式数据库集群出故障时，所述外部观察者组对整个数据库集群进行统一的存活判决的单元；用于基于所述外部观察者组，对所述分布式数据库集群中的存活节点进行投票，选举出主节点，其余的存活节点为备节点的单元；用于将所述主节点的数据复制到所述备节点，进行同步的单元。

可选地，在上述装置的一个示例中，所述存活判决包括：判断所述分布式数据库集群中的机房或节点是否可用。

可选地，在上述装置的一个示例中，所述主节点到所述备节点的数据同步是基于半同步复制协议来实现的。

可选地，在上述装置的一个示例中，所述主节点到所述备节点的数据同步是基于附加条目(AppendEntries)远程过程调用(RPC)来实现的。

可选地，在上述装置的一个示例中，所述主节点会等待所述主节点和所述备节点对AppendEntries RPC请求做出响应后完成提交。

可选地，在上述装置的一个示例中，用于优化所述AppendEntries RPC的两阶段过程为一阶段过程的单元。

可选地，在上述装置的一个示例中，用于优化的所述单元包括：用于省略AppendEntries RPC的两个阶段中的第二阶段，直接在第一阶段完成时在所述备节点进行本地提交的单元。

可选地，在上述装置的一个示例中，所述装置包括：用于如果所述主节点没有达成所述主节点所述备节点的一致变更，则将通过数据闪回操作回退的单元。

按照本申请实施例的一种电子设备，包括：存储器，用于存储可执行指令；处理器，耦合至所述存储器，用于在执行所述可执行指令时使得所述电子设备执行本文所述的方法。

按照本申请实施例的一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序在被计算机执行时能够执行本文所述的方法。

按照本申请实施例的一种计算机程序产品，其包括计算机指令，所述计算机指令在被计算机执行时能够执行本文所述的方法。

应当注意，以上一个或多个方面包括以下详细描述以及在权利要求中具体指出的特征。下面的说明书及附图详细阐述了所述一个或多个方面的某些说明性特征。这些特征仅仅指示可以实施各个方面的原理的多种方式，并且本公开内容旨在包括所有这些方面和其等同变换。

附图说明

以下将结合附图描述所公开的多个方面，这些附图被提供用以说明而非限制所公开的多个方面。

图1示出了基于外部观察者组的调度节点对分布式数据库集群中的节点进行同步的流程图100。

图2示出了在同城双活部署时，基于外部观察者组来进行跨机房脑裂判定和同步的框图200。

图3示出了基于外部观察者组对分布式数据库集群进行存活判定、投票选举和同步的方法流程图。

图4示出了基于外部观察者组对分布式数据库集群进行存活判定、投票选举和同步的装置400。

图5示出了用于对存储器装置中的存储单元进行编程的电子设备500。

具体实施方式

现在将参考多种示例性实施方式来讨论本公开内容。应当理解，这些实施方式的讨论仅仅用于使得本领域技术人员能够更好地理解并从而实施本公开内容的实施例，而并非教导对本公开内容的范围的任何限制。

同城双活是在同城或相近区域内建立两个机房。这两个机房各承担一部分用户业务，每个机房部署一个分布式数据库集群(例如，zookeeper集群)，并且进行实时同步。在同城双活部署场景中，同城的其中一个机房可能会出现故障，例如，该机房的对外网络断开，致使外部无法访问该机房；或者该机房整体断电。

一个分布式数据库集群可能有众多的节点组，每个节点组在发生故障时都需要选举主节点，由于一半数量的节点发生故障时需要进行一次脑裂的存活判决，所以需要对众多节点组进行存活判决，并且这些节点组是与业务数据相关的，手动判决并进行一半数量的节点强制恢复操作复杂度高、生产实现难度大。

当一个节点组中的一半数量的节点出故障时，无法通过传统的“过半选举”机制来选举领导者和追随者。本申请通过引入集群全局统一的外部观察者组，当节点组中的半数节点出故障时，通过外部观察者组实现统一的存活判决、选举投票，实现类“过半选举”，确保数据零丢失。针对外部观察者组本身的机房故障判决可以由人工介入，因为其非常轻量，不涉及业务数据并且只有一个外部观察者组，所以非常容易集成到运维管理平台中，实现生产落地。

下面将结合附图来详细描述具体实施例。

图1示出了基于外部观察者组的调度节点对分布式数据库集群中的节点进行同步的流程图100。

下面参照Raft协议，描述在节点同步层面进行对等实现方式。针对Raft协议中的各个节点角色，领导者(leader)对应于图1中的主节点102，而追随者(follower)对应图1中的备节点103、104；对于Raft的协议日志，在图1中由基于节点的binlog来实现；对于Raft的状态机，在图1中是在数据表引擎innodb层实现的。

首先，存活判决是“选主”的前置步骤。所谓“选主”是指当主节点出故障后，由存活的候选者节点进行投票选举新的主节点。

在现有的Raft协议中，使用远程过程调用(RPC)进行各节点之间的通信，并且基本的一致性算法只需要两种类型的RPCs。Raft协议的两类RPC调用分别为：请求投票(RequestVote)RPC和附加条目(AppendEntries)RPC。在Raft协议中，先由候选人(candidate)在选举期间发起RequestVote RPC，进行“选主”；然后，由领导人(leader)发起AppendEntries RPCs，用于复制日志和提供心跳机制。

在本申请的一个实施例中，使用RequestVote RPC进行“选主”的操作是基于外部观察者组的调度节点101探测后端数据节点的主备复制关系来生成RequestVote RPC进行投票的，票数最多的候选者节点将被选为主节点102。一个候选者节点得到的投票数越多，表明从该节点进行数据同步的备节点越多，所以该候选者节点越应当被选为主节点。拥有最多备节点的主节点将获得最多的投票，成为主节点。

根据本申请的一个实施例，当判定一半数量的节点存活时，投票的行为是由外部观察者组驱动，外部观察者组通过检查各节点间的副本复制关系来进行驱动节点把票投给它的主节点。更具体地说，外部观察者可以通过候选者节点提供的接口获取状态信息，检查在出现本次故障之前的候选者节点之间的最近一次的主备复制关系；如果无法得知上一次的主备复制关系，或者出现主备复制关系均等的情形，则基于类Raft日志的进度进行“选主”，候选者节点都投票给Raft日志进度最新的节点；如果所有候选者节点的Raft日志进度都是最新的，则通过随机机制选择一个候选者节点作为主节点。

通过设置本地的master version信息来标记当前term周期。在一个term周期内，主节点将会一直是主节点，直到它出故障不可用之后，才重新开始“选主”过程。

根据本申请的一个实施例，AppendEntries RPC用于同步主数据节点的复制变更到备数据节点。例如，可以基于半同步复制协议来实现主节点与备节点之间的数据的同步。

根据本申请的另一个实施例，可以从工程实现角度优化AppendEntries RPC的两阶段过程为一阶段过程。也就是，省略AppendEntries RPC的两个阶段中的第二阶段，直接在第一阶段完成时在备节点进行本地提交。

根据本申请的又一个实施例，如果主节点102没有达成多数派(包括主节点和备节点)一致的变更，则将通过数据闪回操作将其回退。更具体地说，如果备节点本地提交的内容最后在主节点没有达成多数派一致的变更，那么后续在与主节点的数据比对中，通过数据闪回操作将其恢复(recover)回退。例如，基于备节点本地的操作日志，将需要回退的事务内逆序反向操作，将发生的变更再改回来。例如，一个事务的顺序是：插入1——>3更新到2——>删除4；那么执行的数据闪回操作是：插入4——>2更新到3——>删除1。

主节点会等待多数派节点(包括主节点和备节点)对AppendEntries RPC请求做出响应后完成提交。此处的完成提交就是确定事务完成，并进行持久化。例如，常用的实现持久化的方式是日志。

主节点的多数派视图(view)会随着节点的增减进行维护，每次提交所需等待的多数派节点数也将自动进行变更和维护。

图2示出了在同城双活部署时，基于外部观察者组来进行跨机房脑裂判定和同步的框图200。

在本申请的一个实施例中，当进行同城双活部署时，对于每一片数据的节点组将至少包含4个节点，并且两个机房的节点数量是相同的。节点之上是外部观察者组202。外部观察者组202包括一个或多个调度节点204-1、204-2、……、204-n。外部观察者组的调度节点将均匀分布到2个机房中，与所有的节点相连，可以参与节点的脑裂存活判定。

根据本申请的一个实施例，在同城双活部署中，传统的众多raft组的判定被简化为了基于外部观察者组202的zookeeper集群206的机房脑裂存活判定。具体而言，外部观察者组202的调度节点204-1、204-2、……、204-n本身是无状态的，通过zookeeper集群206进行跨机房脑裂判定和元数据同步。zookeeper集群206负责所有调度节点的跨机房脑裂判定。例如，能够联通zookeeper集群206的调度节点被判定为存活，不能联通zookeeper集群206的调度节点将自动退出。所以，存活的调度节点所在的机房就是存活的机房，从而实现了跨机房的脑裂判定。

根据本申请的一个实施例，zookeeper集群部署了奇数个节点，主机房中的zookeeper节点数量多于备机房中的zookeeper节点数量。如果主机房和备机房之间的连接线路发生故障，但这两个机房本身无故障，只要主机房存活，则默认主机房是存活的。如果备机房出故障，则主机房可以直接完成故障切换(failover)。如果主机房出故障，则备机房的zookeeper节点将不可用，但可以通过简单步骤强制恢复为一个缩小的新zookeeper集群。由于zookeeper是无任何业务数据的，并且只存储运行态临时数据，非常轻量，所以这个过程将非常的快速，且不会对业务数据的一致性造成任何影响。

接下来，被判定存活的调度节点自动参与它能联通的节点的“选主”过程。

如上所述，在两个机房中的节点数量相同的情况下，如果一个机房出故障，则存活的另一机房所包含的节点数量是两个机房的节点总数的一半。外部观察者组的调度节点参与“选主”过程后，就可以激活存活的一半数量的节点进行投票，实现类“过半选举”，其中，所述外部观察者组为得票最多的节点额外再投一票，从而实现在一半数量的节点出故障的情况下完成“选主”。

这样，通过外部观察者组投票推动节点进行“选主”，由于要求严格达到超过一半的节点写入数据，每次写入数据都在两个机房的至少1个节点完成同步，所以两个机房都存在同步数据，从而实现了重新选主后的业务数据零丢失，数据强一致。

本申请允许在分布式数据库集群同城双活时的单一集群部署，确保多数派写入的同时，确保半数节点故障情况下集群能快速恢复并且数据零丢失。基于全局统一的外部观察者组简化集群同城双活场景的脑裂判定，该过程只需要进行一次，无论集群大小，并且不涉及用户数据复制组，大幅增强了操作的数据安全性。

图3示出了基于外部观察者组对分布式数据库集群进行存活判定、投票选举和同步的方法流程图300。

在框302处，在分布式数据库集群出故障时，外部观察者组对整个分布式数据库集群进行统一的存活判决。存活判决用于判断节点或机房是否可用。例如，在同城双活部署中，两个机房中的一个机房出故障后，判断另一个机房是否存活。因为两个机房场景可能存在脑裂，当机房1无法访问机房2的时候，需要确认机房1是否存活，机房2是否出故障。

在框304处，基于外部观察者组，对分布式数据库集群中的存活节点(即，候选者)进行投票，选举出主节点(即，领导者)。其余存活的节点成为备节点(即，追随者)。

在框306处，将主节点的数据复制到备节点，进行同步。可选地，可以基于半同步复制协议来实现主节点到备节点的数据同步。

图4示出了基于外部观察者组对分布式数据库集群进行存活判定、投票选举和同步的装置400。

所述装置400包括：用于在分布式数据库集群出故障时，外部观察者组对整个分布式数据库集群进行统一的存活判决的单元402。存活判决用于判断节点或机房是否可用。例如，在同城双活部署中，两个机房中的一个机房出故障后，判断另一个机房是否存活。因为两个机房场景是可能存在脑裂的，当机房1无法访问机房2的时候，需要确认机房1是否存活，机房2是否出故障。

所述装置400包括：用于基于外部观察者组，对分布式数据库集群中的存活节点(即，候选者)进行投票，选举出主节点(即，领导者)。其余存活的节点成为备节点(即，追随者)的单元404。

所述装置400包括：用于将主节点的数据复制到备节点，进行同步的单元406。可选地，所述单元406可以包括：用于基于半同步复制协议来实现主节点到备节点的数据同步的单元。

图5示出了用于对存储器装置中的存储单元进行编程的电子设备500。图5所示的电子设备500可以利用软件、硬件或软硬件结合的方式来实现。

如图5所示，电子设备500可以包括处理器501和存储器502，其中，存储器502用于存储可执行指令，所述可执行指令当被执行时使得处理器902执行本文所述的方法。

本申请的实施例还提供一种计算机可读存储介质，其上存储有计算机程序，当计算机程序被执行时，使得计算机执行本文所述的方法。

本申请的实施例还提供一种计算机程序产品，其包括计算机指令，当计算机指令被执行时，使得计算机执行本文所述的方法。

应当理解，以上描述的方法中的所有操作都仅仅是示例性的，本公开内容并不限制于方法中的任何操作或这些操作的顺序，而是应当涵盖在相同或相似构思下的所有其它等同变换。

已经结合各种装置和方法描述了处理器。这些处理器可以使用电子硬件、计算机软件或其任意组合来实施。这些处理器是实施为硬件还是软件将取决于具体的应用以及施加在系统上的总体设计约束。作为示例，本公开中给出的处理器、处理器的任意部分、或者处理器的任意组合可以实施为微处理器、微控制器、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑器件(PLD)、状态机、门逻辑、分立硬件电路、以及配置用于执行在本公开中描述的各种功能的其它适合的处理部件。本公开给出的处理器、处理器的任意部分、或者处理器的任意组合的功能可以实施为由微处理器、微控制器、DSP或其它适合的平台所执行的软件。

提供前述描述以使本领域任何技术人员能够实践本申请中描述的各个方面。对这些方面的各种修改对于本领域技术人员将是显而易见的，并且本文中定义的一般原理可以应用于其它方面。因此，权利要求并非旨在被限定于本文中所示的方面，而是应当依照与权利要求语言相一致的全部范围，其中，除非有具体说明，提到单数的元素并不旨在表示“一个且仅一个”，而是“一个或多个”。除非另有具体说明，术语“一些”是指一个或多个。本领域普通技术人员已知或以后将知道的，贯穿本公开内容所描述的各个方面的元素的所有结构和功能等同物均通过引用而明确地合并入本文，并且旨在由权利要求涵盖。而且，本文中公开的任何内容都不旨在奉献给公众，无论在权利要求书是否明确叙述了这样的公开内容。

本领域技术人员应当理解，以上公开的各个实施例可以在不偏离发明实质的情况下做出各种修改和变形，这些修改和变形都应当落入本申请的保护范围之内，并且，本申请的保护范围应当由权利要求书来限定。