如何保证分布式系统数据的一致性

缺乏、安全感 2021-11-05 02:52 399阅读 0赞

分布式系统CAP理论

此章节重点介绍：C/一致性(分布式一致性协议实现算法Raft)

Raft算法的集群中的三种角色：

*  Leader（领袖）
 *  Follower（群众）
 *  Candidate（候选人）

每个节点都会且只能处于以上三种角色中的一种

算法的主体大致可分为2个过程 ：1、选举 2、日志同步（数据同步）

**选举**

选举和现实社会中的民主选举制度很像，刚开始没有 Leader，所有集群中的参与者都是 Follower, 当 Follower 超过选举超时时间 ( election timeout ) 没收到来自 Leader 的心跳报文，则成为 Candidate，增加任期 ( Term ) 并向其他节点发起新的选举请求。接收到请求的节点如果还没投票，则投票给该节点，并重置自己的超时时间。如果某个 Candidate 节点接收到的选票的个数占大多数（超过 1/2）， 它就会成为 Leader 节点，这就是所谓的 Leader election 的过程。每隔一定时间向 Follower 发送心跳报文来维持自己的 『统治』地位。

集群中的每个节点都处于以上三种角色中的一种，其状态转换图可以总结如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70][]

下面通过几个例子来帮助我们理解这个选举过程：

**1. ****可以正常选举出 Leader 的例子** ：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 1][]

在此例子中，一共有三个节点，复现流程如下：

*  节点 B 首先出现心跳超时，然后变成 Candidate 角色。
 *  节点 B 首先把自己宝贵的一票投给自己，然后请求其他节点也将赞同票投给自己。
 *  节点 A 和 C 此时还未出现超时，仍然处于 Follower 角色，接收到请求后，投票给了 节点 B。
 *  节点 B 接收到的赞同票超过半数，成为 Leader 节点。

**2. ****平分选票的情况**

由于 Raft 协议并不要求集群中的节点个数为奇数，于是在四个节点的集群中，可能出现如下的情况：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 2][]

复现流程如下：

*  节点 B 和 C 几乎同时心跳超时，成为 Candidate 角色。
 *  节点 B 和 C 均将自己的赞同票投给自己。
 *  节点 A 投给了节点 B，而 节点 D 则投给了节点 C。
 *  出现两个 Candidate 的选票相同的情况。

当出现这种情况的时候，没有任何一个节点接收到的赞同票超过半数，于是此选举过程不会有 Leader 角色出现。大家各自等待超时，然后开启下一轮的选举流程。

疑问：那有没有可能在下一轮的选举过程依然出现平分选票的情况？答案是有的，可是 Raft 有一个机制可以避免此种情况持续发生： **每个节点的超时时间都是随机的** ，这样就可以尽量避免多次出现以上的情况。

**3. ****选举流程要点总结**

「1」Leader 角色通过发送心跳报文来维护自己的统治地位。「2」Follower 角色接收不到心跳报文，则超时开始下一轮的选举。「3」每个节点的超时时间都是随机的。「4」成为 Leader 节点需要赞同票超过半数。「5」选举结束，所有除 Leader 的候选人又变回 Follower 服从 Leader。

**日志同步**

当选举完成后，客户端进行的操作都要通过 Leader 来进行。Leader 接受到客户端发来的操作请求后，首先记录到日志中，此时为 uncommitted 状态。然后在下一个心跳报文中通知所有 Follower，当大多数 Follower 响应 ACK 后，Leader 响应客户端，进入 committed 阶段，并向 Follower 发送 commit 通知应用( apply )操作。

日志同步流程如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 3][]

上图中的序号对应一个存储的步骤， **日志同步** 流程总结如下：「1」client 给 Leader 发送一个操作请求，假设为 SET X=8。「2」Leader 会把 SET X=8 这个操作记录到本地 log，此时为 uncommited 状态，同时将这个操作发送给所有的 Follower。「3」Follower 接收到操作请求后，也将 SET X=8 这个操作记录到本地 log（uncommited 状态），然后给 Leader 回复 ACK 信息。「4」Leader 节点当接收到的 ACK 超过半数后，给 client 回复 ACK 信息，进入 commited 阶段。「5」Leader 节点首先应用自己的 log，然后将 commit 消息发送给 Follower, 让 Follower 也 应用自己存储的日志信息。

**Raft 中的异常处理**

我们已经介绍了 Raft 算法的正常处理流程，然而现实总是很骨感，会出现各种异常的情况。client 和 Leader 之间的通信异常，不会影响到集群内部状态的一致性，不再赘述；如果在一个任期内，Follower 角色宕机，处理流程比较简单。其呈现出来的现象就是 步骤「3」异常，然而只要 Leader 能够接收到超过半数的 ACK，就不会影响到正常的存储流程。但是 Leader 角色会针对该 Follower 节点，持续进行步骤 「2」 的动作，直到接收到步骤 「3」的回应信息或者我们把该 Follower 节点从集群中拿掉；Raft 协议强依赖 Leader 节点的可用性来确保集群数据的一致性。下面重点介绍在各种情况下 Leader 节点出现故障时，Raft 协议是如何保障数据一致性的。

**1. **写操作 到达 Leader 节点，但尚未同步到 Follower 节点

此刻集群的状态如下，用方框中的灰色表示当前处于 uncommited 状态。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 4][]

如果集群在此状态，Leader 节点宕机，则 Raft 的处理流程如下：「1」Follower 节点超时，然后选举出新一任期的 Leader，然后它并没有处于 uncommited 状态的日志。「2」Client 节点由于 Ack 超时，可安全发起重试。「3」原来的 Leader 节点恢复后以 Follower 角色重新加入集群。并从当前任期的新 Leader 处同步数据，可能会覆盖原来处于 uncommited 状态的日志。

**2. **写操作 到达 Leader 节点，且将写操作同步到 Follower 节点，但还未向 Leader 回复 ACK 信息。

此刻集群的状态如下，用方框中的灰色表示当前处于 uncommited 状态。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 5][]

如果集群在此状态，Leader 节点宕机，则 Raft 的处理流程如下：「1」Follower 节点超时，然后选举出新一任期的 Leader，并且它存在处于 uncommited 状态的日志。「2」新的 Leader 节点假装没有刚才的选举过程，继续从步骤（2）开始执行，以完成数据的提交。「3」Client 节点由于 ACK 超时，可安全发起重试。「4」原来的 Leader 节点恢复后以 Follower 角色重新加入集群。并从当前任期的新 Leader 处同步数据。

此时，在上面步骤「1」中选举新的 Leader 节点时，需要满足一个限制条件，即新的 Leader 节点需要具有最新的日志信息，所谓的最新是通过任期和日志的偏移量两个参数来判定的，这个限制是为了解决只有部分 Follower 节点接收到写操作请求的情况。

**3. **Leader 节点接收到写操作的 ACK 信息，处于 commited 状态，然而 Follower 处于 uncommited 状态。

此种情况是由于，在步骤（5）执行过程中，Leader 宕机导致的，此刻集群的状态如下，用方框中的灰色表示当前处于 uncommited 状态，用方框中的黑色表示当前处于 commited 状态，同时圆圈中的值表示操作已经生效。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 6][]

对于此种情况，Raft 协议的处理流程和上面情况2的处理流程是一样的。

4. **脑裂**

由于网络故障，产生分区将原先的 Leader 节点和 Follower 节点分隔开，Follower 收不到 Leader 的心跳将发起选举，产生新的 Leader，这时就产生了双 Leader，这就是所谓的脑裂。这种情况下某些 Leader 由于获取不到大多数的投票，所以数据永远不会提交成功。当网络故障恢复后，旧的 Leader 发现有 Term 更新的 Leader 存在，则自动降级为 Follower 并从最新的 Leader 同步数据达成集群一致。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70]: /images/20211104/62b18064c3d14338a4872cf3ed714544.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 1]: /images/20211104/2d1dc6e89b854c27a4a07fb0f0906f26.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 2]: /images/20211104/8d02e692787f44ee926e0e3dd644f28f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 3]: /images/20211104/7b2f0c3e8dff4e3fb1b41653dd7aa3f6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 4]: /images/20211104/8e1cb3e426f14fd696d58a431a301d3e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 5]: /images/20211104/0cd1891455c2460ea7b2c09306652b8e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW45Nzg2MTY2NDk_size_16_color_FFFFFF_t_70 6]: /images/20211104/0d22063dc5db41e78e4d7cc70f00f666.png