Raft 一致性算法

Raft 一致性算法

---

状态机(replicated state machine)

RSM典型实现采用复制log(replicated log)

每一个server上的存储的命令(commands)log都相同，且按相同的顺序执行命令。每个server都具有确定

性，计算同样的状态信息，因此其输出也是一致的。保证复制日志的一致性就是一致性算法的主要任务

实际可用一致性算法特性

1. 确保安全（在网络延迟、分裂、丢包、重复、重排序情况下都不会返回不一致的结果）
2. 在多数节点可以操作的情况下，总体可用
3. 不依赖时间去保证日志的一致性
4. 少数慢节点不影响整体系统性能

raft

https://raft.github.io/

http://thesecretlivesofdata.com/raft/

raft的出现其主要的目的使一致性算法能运用实际的系统当中，而且更具有可理解性，相比于Paxos算法(比

较难理解，需要复杂的改动才能运用实际系统当中)

raft 3种状态

• leader
  一般正常情况下只有一个leader，其他的都是follower。
  leader处理所有客户端调用请求，如果客户端连的是follower，由follower转给leader
• follower
  follower 是个被动角色：只对leader以及candidate的请求进行响应
• candidate
  作为leader的候选

terms：关键作用是确定过期信息

Terms：Raft将时间分成任意长度的，连续不断的整数。terms在raft中作为Logical clock，使所有server发现过期信息如废弃的leader等。每一个server存储当前的term，且随着时间单调递增。server的当前term可以被

改变，在server之间通信(RPCs)当中：

如果一个server当前的term小于其他server的，会用最大的term替换当前的term；

如果一个候选server或leader的当前term已经过期，它们会立即转化成follower的状态；

如果server收到过期term的请求，将会被拒绝。

RPCs

Raft server之间通信采用远程调用方式

1. RequestVote
   在选举阶段由所有候选者初始化
2. AppendEntries
   由leader初始在复制log到其他server和做heartbeat（没有log entries）
3. Transferring snapshots

server如果没有收到RPC的回复，会及时重试，RPC请求都是并行发出已确保最好的性能。

leader 选举(leader election)

raft采用心跳的机制去触发leader选举。

server 已 follower的状态启动。server会一直处于follower状态，在能收到从leader或候选者来的正常RPCs请求。