第七节：X-Paxos 三副本与高可用（一）|学习笔记-阿里云开发者社区

开发者学堂课程【PolarDB-X 开源系列课程：第七节：X-Paxos 三副本与高可用（一）】学习笔记与课程紧密联系，让用户快速学习知识

课程地址：https://developer.aliyun.com/learning/course/1032/detail/15168

第七节：X-Paxos 三副本与高可用（一）

内容介绍：

一、DN 高可用方案

二、X-Paxos 协议

三、DN 高可用体系

PolarDB-X 存储服务的多副本管理以及高可用，分四部分讨论：

第一个是 DN 集群的高可用方案，解释其如何一步步形成现在的模式；

第二个是高可用方案基于 x-paxos 一次性协议；

第三个是 DN 集群如何使用一次性协议从而构建高可用体系；

第四个是 DN 常见的部署与优化。

一、DN 高可用方案

1.PolarDB-X 储存节点 DN

下图为 PolarDB-X 的系统结构，图中 DN 是存储服务，一个 DN 节点即是一个逻辑节点，现在架构中其实有多个副本的，即有多个 MYSQL 节点组成的 X-Paxos 集群来保证高可用。在之前的版本中 DN 集群不是基于 X-Paxos。

存储服务要求:

（1）多副本：即一个副本损坏其余副本依旧可以存储数据。

（2）高可用：并且通过副本的传输方式，其他备份节点可以起到继续服务的能力。

（3）自管理：例如 DN 是 PolarDB-X 的存储组件，它在运行时不希望引入其他组件管理此集群，它是一个自闭环的服务。

这是 PolarDB-X 存储架构对存储服务的要求。

2.MySQL 经典高可用模式

关于高可用以及多副本管理演变了几个形态：如一主一从，一主多从，MySQL社区的MGR，还有其他基于共享存储的部署方案。

这些高可用模式都有其自己的应用场景，但每一种高可用模式关注的问题为：有多少副本，副本组织方式是怎样的形式。

这些决定集群在分区故障的可用性以及全局数据的一致性，还有高可用模式工程的复杂度以及性能（单一的性能最高，如果加上任意一种高可用模式，性能都会打折扣）。

在最开始 DN 集群都是一主一从的结构，用source 半同步构建了主谓的模式，此模式面临的最大问题就是在对数据的一致性要求比较高的场景，比如金融场景，是有丢失数据的风险的。比如说在运行过程中主库挂掉，然后备库去接管。

其实备库去接管的时候与主控之间的数据，两者之间其实没有标准。如果备库去接管以其现有的数据为标准然后再继续提供服务，但此数据在用户的视角，不一定在存储上还有之前已经提交的事物，即其 RPO 不等于0，这是之前模式面临最大的问题。

高可用要关注的问题：

（1）分区故障可用性（副本数）

（2）全局数据一致性（RPO）

（3）服务探活和切换（管理复杂度）

（4）性能

3.DN 集群强一致方案

（1）多副本：现在采用 DN 的方案是采用一个一致性协议来组织的多副本，在这个模式中副本是由2N+1，以及可以容忍最多 N 个节点故障。即只要不超过 N 个节点故障，集群还可以正常提供服务。但是如果超过N个结点故障那此集群就就拒绝服务，就是用牺牲可用性来保证数据的一致性。

（2）当节点数大于N+1个时，节点间，副本间数据的传输是用一致性协议来控制。此方法可以达到 RPO=0。

（3）现在采用这种 X-paxoe 一致性协议的模式，是有一个 leader节点的，因为只有 leader 节点才能提供读写服务，所以 leader 节点一旦挂了，那么剩下的节点如何选主就特别重要。所以故障检测，leader 快速切换这也是一个比较关键问题。

下图为 X-paxos 协议的一个基本的结构图，下面展开看一下协议的运作模型。

二、x-paxos 协议

1.协议简介

x-paxos 协议就是 paxos 协议，理论基础就是那几篇经典的一致性关系 paxos 的论文。

在实现中把模型抽象出下面几个部分：一个节点的数据就是一个状态机，对此节点数据的一次修改把它抽象为一条日志，把此日志应用到状态机上，就说明此节点数据变化了一次。

当此集群正常的运转时，它是有一个 leader 的，集群初始化时状态机是初始化状态然后日志为空，可以是随机选择一个节点作为 leader。接下来系统运行时围绕 leader 来展开。

运转过程：client 对节点数据做修改，并且形成日志。leader 节点将日志写到本地的日志中。

同时把此日志广播到其他 follower 节点，在收到其他 follower 节点应答后，那么说明此日志已经在集群中提交，可以应用状态机给客户端返回应答，这是系统正常运行的过程。在此过程中 leader 是主节点，leader 提供读写服务并且参与选择主；Follower 接收主节点日志，当 leader 挂掉后参与选主，会发送选主请求；另外此图中没有的 Learner 节点也接收主节点日志，但它不参与选主，或者说 Learner 是集群数据的订阅者。可以使用 Learner 来构建只读节点，不参与集群的运作只订阅集群的数据。

在此模型中关键的三部分为：第一个为选主以及如何选主，集群初始化，状态机为空，日志为空可以随机选主，当系统运作一段时间后当前 leader 挂了，其余节点都可以发起选主请求，但只有拥有集群中已经达到一次性状态日志的节点才有可能选为主节点，这是选主的原则；另外是日志复制，即信息进来在集群中如何广播；另外就是节点的维护，向集群中添加节点或者删除节点。

这是协议抽象出的运转模型。

2.工程框架

工程框架在开源的代码中出现过，现在做一个简单的介绍：工程分为四个部分：

第一个是网络层（libeasy），阿里内部实现异步通信的网络框架。

第二个是服务层，提供定时器服务，提供消息的异步传输服务，提供线程池功能；服务层是协议运转的驱动层。

第三个是关键的算法模块，算法层的逻辑是刚刚讲解的选主，日志传输以及集群管理。

最后是日志模块，其实日志模块是算法模块的一部分，因为算法中传输日志维护的是日志；工程中专门把日志模块抽出是为了性能优化，算法中对日志的管理非常简单，把接口定下可以把日志拿出进行深度优化如缓存，异步队列使用这种方式来达到性能优化的目的，这是协议的工程框架。

三、DN高可用体系

1.数据一致性

前面讲解协议的运作，接下来讲解在 MySQL 中如何把协议集成进去。首先在 DN 集群中传输的为 BinLog，现在查看 Binlog 是如何在节点中传输的。

MySQL 的事务提交，在 Binlog 的参与下分为两个阶段，

第一阶段 inner DB prepare，

第二阶段进入有 Binlog 协调的commit，这分为三个流程，也就是所有进来的事物，会进入队列：第一个部分是 flash 阶段，将日志写入 blog；

第二个阶段是 think，think是将队列中所有已经写入 Binlog 的日志、一起刷到盘上；

第三阶段是引擎的commit。引入 x-paxos 协议之后，其过程会发生变化。

在flash阶段，leader 节点日志写入到本地的 Binlog 的同时，会将日志同时广播到所有的 follow 节点，这是网络传输。

然后在 think 阶段，这一组事物的 Binlog 都已经持久化在盘上，会形成一个持久化的 Index 位点，那么这个地方跟协议层同步一下这个位点。接下来就到提交阶段，这时要等协议层的 consensus 协议提及 x-paxos 的模块，等刚才的那一批 Binlog 在大多数节点应答后，才能够进行这组事物的提交，就是它的提交点。

最终这一批事物的提交点，是要根据这批日志在其他节点上的接触情况来决定的，这是最关键的一步。这一步是多数派接到消息后，在 leader 上提交事物。

此过程跟刚才的 pictures 协议的运作抽象的模型差不多，只不过此图显示的是具体的 Binlog 传输的方式。这个是简要的 x-paxos 协议是如何嵌到 Binlog 里面的。

刚才一直强调有 leader，其实在此模型中 Leader 扮演一个很重要的角色。在集群中同一时刻不允许有多个 leader 存在，而 leader 节点挂了后，要迅速选出新的 leader 来提供服务。

2.集群选主

下面看一下在这块做的一些工作：

（1）首先有个概念叫租约，就是对所有节点来讲，例如对 leader 来说，自己就是 leader，而对于 follow 来讲，其认为集群中有一个 leader ，每一个 leader 都有一个任期，在这个任期之内，所有 follow 节点不会再接受其他节点的悬殊请求。

所以正常时，Leader 节点通过向其他 follow 节点发送心跳来保证不断的延长它的任期，这也是大部分的工作状态。但一旦 leader 发生异常，follow 会检测到 leader 不存在了或者服务异常，每个 follow 都会发起选主请求，并选自己为主，那么如果其他大多数节点还健康的话，就能选出新的节点出来。这是对于follow的节点，如果是对于 leader 节点而言，如果在其周期之内发现大部分 follow 节点都失去联系了，那么其就会认为此集群已经不能够再提供服务，会主动把自己降级为 follow，然后从 follow 再重新发起选主请求，这个过程保证了集群中同时只有一个 leader 的存在。而当 leader 发生异常时，集群会自发的进行选主，选出一个新的 leader 出来。这就是选主租约的概念。

（2）第二个是权重选主，当默认情况下，集群中的每个节点当选 leader 的概率是相等的。但在某些情况下，可能会希望集群中某些节点或某个区域的节点，让它具有更高的优先级当选力，这时就可以给每个节点配置一个选主权重。权重高的节点有更高的概率来 leader，这就叫权重选组。

但是这只是当选力概率比较高，并不能保证100%这个节点就是高权重节点，从而使其一定当选 leader。因为选主最基本的一个原则，还是此节点要拥有此集群当时已经达到共识的最新日志，如果其日志不符合要求，也不能当选为主。权重选主是部署方面的一个优化，或者是一个功能项。

3.状态机诊断

（1）复制延迟场景快速恢复服务：刚才提到集群节点间复制的是 Binlog 日志，主节点将 Binlog 传输到 follow 并且收到之后，集群中对日志就达成了共识，说这个日志在集群中存在，但是对于 follow 的节点而言，其并不会要求它把当前日志，一定应用到这个一次性状态位点后才能继续。

所以系统的集群正常运转时，只有 leader 节点保持了集群中最新数据， follow 节点是有最新的日志，但是它的状态机或者说 MySQL 集群的数据不一定是最新的。因为其 Binlog 可能还有一段未应用，这是有间隔的。所以当原 leader 异常后，新 leader 被选出来，那这个新 leader 在对外提供读写服务之前，首先要把 Binlog 应用到最新的位点，也就是追平日志才能服务。

在一些特殊的情况，Binlog 的延迟可能比较大，这时原来的 leader 又起来了，因为其又被后台的 demo 线程拉起来了。其实最新 leader 节点作为服务更加合适，因为它的日子最新，也不需要再去回放，所以这里就是说刚才被选为的新的 follow 的节点，在其还不能及时提供服务时，其也会不断的探测其他现在已经接到集群的节点，如果发现有比它更合适的节点，就会把自己的 leader 节点主动让出去。更合适是指可能别人应用日志速度更快，更新，或者权重更大等等。这样是为了更快的恢复服务。所以这里是对这种复制延迟场景下快速恢复服务的优化，叫状态级的诊断。

4.反向心跳

其实这个集群能否对外服务，也就是 leader 节点能否对外服务，其实还是看 MySQL 能不能对外服务。有时候从集群或者从协议层来看，这个集群是健康的，例如每个节点的心跳，日子复制其实都是健康的。但是很可能因为 leader 的 MySQL 节点因为其他的原因不能对外提供服务。

比如有一些磁盘板或者系统号的情况。这种情况下，如果没有外力干扰，可能会导致此集群一直会僵持在这里，因为协议上没有问题，然后 leader 节点因为其他系统原因，导致无法服务。没有人来终结这个状况，所以在开源的概率和引擎里，在这个协议上有一个反向心跳的功能。也就是说 follow 节点会定期的向 leader 节点发起探测请求，这个探测请求其实就是将自己莫你认为是正常客户端或 APP 的视角来探测 leader 节点数据库服务是不是好的。