在实际应用中，对于分布式系统而言，遇到一致性问题，业界产生了许多经典的分布式一致性算法，以前项目中常的分布式一致性算法是2PC和Paxos，对于Raft算法只知其名，从未仔细理解过，直到今天和同事聊天时，突然被问到，Paxos与Raft的区别在哪？为什么我们项目中应用Paxos产生这么多问题，当初是否考虑过采用Raft算法？这一问，我的确没有回答上来，因为我从来没有思考过Raft在分布式数据库存储系统应该怎样应用。
Raft算法虽然是在2013年才发表的，但目前应用非常广泛，甚至成为分布式一致性算法的主流之一。
下面记录下Raft算法的基本原理：
它和Paxos类似，有三种角色，分别是Leader（领导人）、Follower（跟随者）、Candidate（候选人）。其中Leader的作用是负责接收客户端的请求，将日志复制到其他节点并告知其他节点何时应用这些日志是安全的；Candidate的作用是选举Leader的一种角色；Follower的作用是响应Leader或Candidate的请求。
Raft算法存在三个相对独立的子问题：领导人选举；日志复制；安全性机制。
领导人选举
选主策略：Leader会周期性的发送心跳包给Follower。每个Follower都设置了一个随机的竞选超时时间，若在这个时间内Follower未收到 Leader 的心跳（假定Leader所在节点宕机），那么Follower就会变成 Candidate，进入竞选阶段。
若某个节点由Follower变成 Candidate后，则会向其他节点发起投票请求，而收到投票请求的节点也会对其进行响应，对于整个集群中，若有一半以上的节点响应了，那么此节点的角色会由Candidate转变为Leader。此后，Leader仍然会周期性的发送心跳包给Follower。
基于上述策略，对于存在多个Candidate的场景，只需要对获取票数最多且相同的情况进行重新选主。一般来说，各节点的超时时间不一致，出现多节点重新选主的概率不大。
日志复制
Raft算法中的一致性是通过日志复制来保证的，其流程为：
（1）客户端发起的修改操作被集群中Leader记录。对于未提交的修改，记录在日志中。
（2）Leader将日志同步复制到所有Follower节点。Leader收到超过一半的Follower节点响应后，将修改提交。
（3）此时Leader会通知的所有Follower让它们也提交修改，所有节点的值达成一致。
对于异常场景中，日志复制过程会产生日志冲突。
安全性：
可参考下面的论文，待总结。
https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md