算法包含两个过程：leader 选举和日志复制：
(1) 选举过程：(假设有 5 个节点， S1~S5 )
a、 初始状态下，大家都是平等的 follower ，那么 follow 谁呢，总要选个老大吧。大家都蠢蠢欲动，每个 follower 内部都维护了一个随机的 timer ;
b、 在 timer 时间到了的时候还没有人主动联系它的话，那它就要变成 candidate ，同时发出投票请求( RequestVote )给其他人，假设 S1, S3 成为 candidate
c、 对于相同条件的 candidate ， follower 们采取先来先投票的策略。如果超过半数的 follower 都认为他是合适做领导的，那么恭喜，新的 leader 产生了，假如 S3 变成了新一届的大哥 leader ;
d、 S1 很不幸，没有人愿意选这个悲剧的 candidate ，那它只有老老实实的变回小弟的状态 follower;
e、 同样的，如果在 timer 期间内没有收到大哥的联络，这时很可能大哥已经跪了，如下图，所有小弟又开始蠢蠢欲动，新的一轮 (term) 选举开始了。
(2) 日志复制：(假设有 5 个节点， S1~S5 )
a、 leader 扮演的是分布式事务中的协调者，每次有数据更新的时候产生二阶段提交( two-phase commit )。在 leader 收到数据操作的请求，先不着急更新本地数据(数据是持久化在磁盘上的)，而是生成对应的 log ，然后把生成 log 的请求广播给所有的 follower ;
b、 每个 follower 在收到请求之后有两种选择：一种是听从 leader 的命令，也写入 log ，然后返回 success 回去;另一种情况，在某些条件不满足的情况下， follower 认为不应该听从 leader 的命令，返回 false ;
c、 此时如果超过半数的 follower 都成功写了 log ，那么 leader 开始_第二阶段_的提交：正式写入数据，然后同样广播给 follower ， follower 也根据自身情况选择写入或者不写入并返回结果给 leader ，最终所有节点的数据达成一致。
d、 这两阶段中如果任意一个都有超过半数的 follower 返回 false 或者根本没有返回，那么这个分布式事务是不成功的。此时虽然不会有回滚的过程，但是由于数据不会真正在多数节点上提交，所以会在之后的过程中被覆盖掉
Raft 协议保证_leader_的强领导地位 ,client _读写都_通过_leader__，有很高的一致性，但有些同学会问，那分布式的价值在什么地方呢?如何才能负载均衡呢?在实际中我们采用 Multi Raft 架构，结合应用，不同的应用选举不同的 leader 节点，在负载均衡。
5、跨机房部署
在分布式系统中，跨机房问题一直都是老大难问题。机房之间的网络延时较大，且不稳定。跨机房问题主要包含两个方面：数据同步以及服务切换。跨机房部署方案有三个：集群整体切换、单个集群跨机房、 Paxos 选主副本。下面分别介绍。
A 、集群整体切换
集群整体切换是最为常见的方案。如图所示，假设某系统部署在两个机房：机房 1 和机房 2 。两个机房保持独立，每个机房部署单独的总控节点，且每个总控节点各有一个备份节点。当总控节点出现故障时，能够自动将机房内的备份节点切换为总控节点继续提供服务。另外，两个机房部署了相同的副本数，例如数据分片 A 在机房 1 存储的副本为 A11 和 A12 ，在机房 2 存储的副本为 A21 和 A22 。在某个时刻，机房 1 为主机房，机房 2 为备机房。
机房之间的数据同步方式可能为强同步或者异步。如果采用异步模式，那么，备机房的数据总是落后于主机房。当主机房整体出现故障时，有两种选择：要么将服务切换到备机房，忍受数据丢失的风险;要么停止服务，直到主机房恢复为止。因此，如果数据同步为异步，那么，主备机房切换往往是手工的，允许用户根据业务的特点选择“丢失数据”或者“停止服务”。
如果采用强同步模式，那么，备机房的数据和主机房保持一致。当主机房出现故障时，除了手工切换，还可以采用自动切换的方式，即通过分布式锁服务检测主机房的服务，当主机房出现故障时，自动将备机房切换为主机房。
B 、单个集群跨机房
将单个集群部署到多个机房，允许不同数据分片的主副本位于不同的机房，如图 3-11 所示。每个数据分片在机房 1 和机房 2 ，总共包含 4 个副本，其中 A1 、 B1 、 C1 是主副本， A1 和 B1 在机房 1 ， C1 在机房 2 。整个集群只有一个总控节点，它需要同机房 1 和机房 2 的所有工作节点保持通信。当总控节点出现故障时，分布式锁服务将检测到，并将机房 2 的备份节点切换为总控节点。