手撸golang etcd raft协议之1
缘起
最近阅读 [云原生分布式存储基石：etcd深入解析] (杜军 , 2019.1)
本系列笔记拟采用golang练习之
gitee: https://gitee.com/ioly/learning.gooop
raft分布式一致性算法
分布式存储系统通常会通过维护多个副本来进行容错，
以提高系统的可用性。
这就引出了分布式存储系统的核心问题——如何保证多个副本的一致性？
Raft算法把问题分解成了领袖选举（leader election）、
日志复制（log replication）、安全性（safety）
和成员关系变化（membership changes）这几个子问题。
Raft算法的基本操作只需2种RPC即可完成。
RequestVote RPC是在选举过程中通过旧的Leader触发的，
AppendEntries RPC是领导人触发的，目的是向其他节点复制日志条目和发送心跳（heartbeat）。
raft节点的有限状态机
raft.png
流程梳理
- 默认以Follower状态启动，租期号term=1
- 启动参数静态配置了集群的节点数和各节点地址
- Follower和Candidate节点不响应客户端请求
- 等待Leader心跳超时， 进入Candidate状态
- 向其他集群节点发起RequestVote RPC请求
- 一个任期内，一个Raft节点最多只能为一个候选人投票，先到先得
- 如果获得N/2+1（含自己那票）票，则进入Leader状态
- Leader开始响应客户端请求，每条写请求都将生成操作日志，并复制给其他节点
- 大多数Follower响应日志复制指令后， 回复客户端OK
- Follower提交操作日志到本地状态机
- Leader租期结束，重新进入Candidate状态
（未完待续）
