1. 理解分布式一致性问题

• 假设我们的分布式系统只有一个节点，我们可以认为他是一个数据库服务端，存储了一个整型数据
• 我们还有一个客户端，用于访问系统该数据库的数据（读/写）

one-node-system.png

显然，对已只有一个节点的系统，我们写操作很简单的得到满足

multi-node-system.png

这就是分布式系统的一致性问题。

在分布式环境中， 一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作之后， 应该能够保证系统的数据仍然处于一致的状态。

对于一个将数据副本分别在不同分布式节点上的系统来说，如果对于第一个节点的数据进行了更新操作，并且成功更新之后，却没有使得其他节点上的数据得到相应的更新，于是在对第二个节点的数据进行读操作时，获取的是老数据（脏数据），这就是典型的分布式数据不一致的情况。

在一个分布式系统中，如果能够做到针对一个数据项的更新操作执行成功之后，所有的用户都可以读取到其中的最新值，那么这样的系统就被认为是具有强一致性（严格一致性）。

当然，在有些分布式系统实现中，并不需要实时保证系统数据的强一致性，它允许数据存在中间状态，并认为该中间状态不会影响系统的整体可用性（允许数据在不同节点之间的同步存在延时），在经过一段时间之后，最终能够达到一个一致的状态，这就是最终一致性（弱一致性）。

2. Raft过程概述

• 在raft中，一个节点可以有三种状态

status.png

• 所有的节点初始状态都是Follower状态
• 如果没有收到来之Leader的消息，则节点自举为Candidate状态
• Candidate节点然后向其他节点广播投票请求，参考下图
• 假如Candidate获取到超过半数的选票，当然，自动升级成Leader了
  选举过程要求节点为奇数（包括自身节点），否则可能出现选票无法超过一半的情况，无法选举出Leader
  以上过程就是Leader Election

leader-election.png

• Leader选择出来之后，所有对分布式系统的修订操作都直接作用于Leader节点上了。
• 所有操作都会向节点添加log（redo/undo等）
• Log并不立即提交，因此节点的值并不会立即更新
• Leader通告Follower操作，Follower也添加log，但是未提交

log.png

• Follower反馈
• Leader收到Follower反馈之后，执行提交操作，节点值更新
• Leader更新之后，通告Follower更新
• 整个过程完成

report.png commit.png

3. Leader Election

status-machine.png

• 所有节点初始状态为Follower
• Follower等待Election timeout（150ms～300ms），超时将自举成Candidate
• Election timeout之后，node成为Candidate，开始新的周期
• Candidate vote for itself and send vote request to other nodes

vote-1.png

• Follower收到vote request之后，开启新的周期，同时反馈vote信息
• Candidate收到Follower的vote反馈之后，就升级成Leader（必须半数以上的反馈才算是选举成功，包括自身）
• Leader开始周期性发送Append Entries消息给Follower，作为保活消息，这个消息发送间隔为heartbeat timeout
• Follower收到append entries消息之后做出回应，然后重置heartbeat timeout
• 以上过程将持续进行，直到某个follower不再收到heartbeats，并且在election timeout之后自举成candidate，开始一个新的周期

vote-2.png vote-3.png

• 假如现在停止Leader的append entries，在heartbeats timeout 和 election timeout之后， B或C将有一个节点自举成candidate
• 开始新一轮的Leader选举过程，结果如下图所示
  在第二个周期，C节点成为了Leader，A节点已经down掉了

注意：奇数个节点参与竞选Leader是个重要的要求，否则，将有可能无法达成多数个节点投票的条件，导致无法选出leader

vote-4.png

4. Log Replication

一旦选出了Leader节点，我们需要将Leader上的修订同步到所有的其他节点上，以满足分布式系统的一致性原则，这个过程是通过Append Entries消息实现的。

• 首先， client对leader写操作， leader生成操作log，但是还没提交
• Leader在下一个心跳周期通告所有的follower操作log
• Follower收到通告之后，生成操作log，同时反馈给leader
• 当Leader收到大多数的Follower反馈成功之后，将进行commit操作，leader上的节点更新成功
• Leader更新成功之后，反馈给Client
• 下一个heartbeat，Follower收到Leader的消息之后，将commit log，更新节点
  以上具体过程可以参考第2小节中的图片描述