Raft算法（拜占庭问题）

拜占庭问题

拜占庭是东罗马帝国的首都，因为国土辽阔，所以需要在各个地方派军守卫，正因为如此才导致各地方的将军之间进行通信需要信使。而进行一次打仗往往需要各位将军一致的意见才可以进行，但是有些军队中存在间谍，可能会半道杀死信使或者修改信件导致情报泄露。那么如何在这种情况下达成一致协议呢？这就是拜占庭问题。
可以类比到分布式中一致性问题，某些机器挂掉，能够还能保证整体系统正常运行呢？

Raft算法

核心主要有2点：
- 选取主节点
- 同步数据

以下都是简单的总结，旨在扫盲，感兴趣可以实践一下。

选择主节点

首先整体系统的节点可以分为3类：
- Leader(主节点)
- Follower(从节点)
- Candidate(参与投票竞争的节点)

节点的进化类型为Follower->Candidate->Leader。
1. 系统中的每个节点初始都为Follower,且都有可能成为Candidate，这主要取决于哪个节点的计时器到达了超时时间（Election TimeOut),首先到达这个时间将会成为Candidate点。
2. 成为Candidate之后,这个点将会给自己投一张票，然后向系统中其余的节点发送投票通知，其余节点收到后将自己的投票结果回馈给该节点，当赞数多于系统中节点的一半数目时，这个节点一跃成为Leader.
3. 成为Leader后，这个节点就要告诉其他节点我是领导了，你们都给我成为我的从属者，什么候选者(Candidate)也要通通变为Follower,且它们的计时器清零，防止再次成为候选。

至此，主节点选择过程结束。当然主节点需要每隔固定时间间隔告诉从节点它没挂掉，国不可一日无王就是这个道理。若主节点挂掉，那么就要开始重新计时了，新的国王即将上任！

同步数据

同步数据流程大多都大同小异：
1. 客户端提交请求，Leader处理请求产生结果
2. 由Leader将处理的结果复制到Follower节点上
3. 复制成功的节点，会反馈给Leader.
4. 这里与选择主节点的过程类似，如果有一半的节点数据赋值成功，那么客户端本次提交的请求有效，主节点上的数据处理commit，同时向客户端返回Response.
5. 之后就是异步化的过程，有Leader通知从节点也进行commit。虽有短短的延迟，但已经很好做到了主从一致性。

应用场景

1. 系统的配置需要统一时
2. K-V系统，比如Redis.

参考

微信公众号《程序员小灰》文章：什么是拜占庭问题？