etcd的raft选取机制

etcd 是一个分布式的k/V存储系统。核心使用了RAFT分布式一致性协议。一致性这个概念，它是指多个服务器在状态达成一致，但是在一个分布式系统中，因为各种意外可能，有的服务器可能会崩溃或变得不可靠，它就不能和其他服务器达成一致状态。这样就需要一种Consensus协议，一致性协议是为了确保容错性，也就是即使系统中有一两个服务器当机，也不会影响其处理过程。

为了以容错方式达成一致，我们不可能要求所有服务器100%都达成一致状态，只要超过半数的大多数服务器达成一致就可以了，假设有N台服务器，N/2 +1 就超过半数，代表大多数了。

raft协议核心要点：

• Leader选举（Leader Election）

• 日志同步 （Log Replication）

  • leader收到client的更新请求后，会讲更新的内容同步给所有follower。

• 集群状态的正确性 （Safety）

  • 保证日志的一致性
  • 保证选举的正确性

服务器状态：

• leader
  处理所有客户端交互，日志复制等，一个任期只有一个。

• follower
  完全被动的选民，是只读的。

• candidate
  候选人，可以被选举为新领导。

状态之间的转换：

 

任期（terms）

 

如上图，蓝色代表 Election 模式，绿色代表 Operation 模式

• 在每个任期内最多一个leader
• 有些可能没有leader
• 每一个服务会维护当前的任期值
  • 每一个rpc请求中都会携带term值
  • 如果一个peer实例拥有老的term值，则更新为最新的term值并状态变为follower
• 一旦一个服务选举为leader，就会进入 operation 模式

Leader选举

etcd服务启动后，会进入 follower 状态，leader 心跳超时后会进入选举状态。
选举总体流程图如下：

 

选举流程分解

• 初始状态都是Follower

   

  

• S1 超时, 变为Candidate，开始选举, 发起投票请求

   

  

• S1 变为Leader

  • S2 和 S3 同意投票给S1

     

    

• Leader S1开始接受客户端写请求

  • Leader接受到客户端写请求后，会将数据更新写入到log中
  • 如果S2和S3收到客户端写请求，会将请求转发到Leader S1
  • Leader会异步的将更新的log同步到Follower S2和S3

  • 超过多数的Follower将数据成功同步到log后，Leader会将该条数据更新为Committed状态，Committed index会随着增长。

     

    
     

    

---

选举的正确性

1. 在每一任期内，最多允许一个服务被选举为leader
   • 在一个任期内，一个服务只能投一票
   • 只有获得大多数投票才能作为leader
2. 如果有多个candidate，最终一定会有一个被选举为leader
   • 如果多个candidate同时发起了选举，导致都没有获得大多数选票时，每一个candidate会随机等待一段时间后重新发起新一轮投票（一般是随机等待150-300ms）

日志的一致性

1. 客户端写入数据到 leader：

• • leader 将数据写入到 log
  • leader将更新的数据广播到所有的followers
  • 多数follower成功写入log后，leader会将该数据提交到状态机
  • leader 把数据提交后，返回给client结果
  • 在下一个心跳中，leader 通知follower更新已经提交的数据Crashed/slow followers ？

2. leader会一直重试同步数据到follower，直到成功