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

说明书

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

技术领域

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

背景技术

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

目前主流的节点强一致同步协议是基于多数派的分布式一致性协议，例如，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机房就可实现分布式数据库集群跨机房多活高可靠，大幅降低成本，同时依然确保了数据库集群数据的高可靠与强一致。