【架构师面试-分布式-2】-解决共识问题方案-Raft 算法

1 什么是Raft算法

Raft算法是一种非常易于理解的分布式共识算法。Raft算法可以保障分布式系统数据的一致性，解决分 布式容错系统的共识问题。在容错性与性能表现方面等同于老牌的复杂的Paxos共识算法。

Raft 算法：是一个最终一致性的算法，不是强一致性算法。

2 角色、任期及角色转变

主节点有写入数据的权限。对系统的所有更改，都需要经过Leader节点。从节点没有权限，从节点只有读取权限！

在 Raft 中，节点有三种角色：

Leader【主】：唯一负责处理客户端写请求的节点；也可以处理客户端读请求；同时负责日志复制工作

Candidate【候选人】：Leader 选举的候选人，其可能会成为 Leader

Follower【从】：可以处理客户端读请求；负责同步来自于 Leader 的日志；当接收到其它Cadidate 的投票请求后可以进行投票；当发现 Leader 挂了，其会转变为 Candidate 发起Leader选举

Term：【任期/年号】什么是Term呢？

3 leader选举流程

（1） 成为候选人

（2） follower投票

（3） Candidate 等待响应

（4） Candidate 获取半数以上投票【活动节点】成为主节点，可以防止脑裂的

4 Raft算法下集群脑裂情况【普遍】

Raft算法自己就解决了网络分区的问题，基于领导选举及日志复制的机制来解决的！

什么是脑裂

在一个高可用系统中，当联系着的节点断开联系时，本来为一个整体的系统，分裂成两个独立节点，两个节点开始争抢共享资源造成系统混乱、数据损坏的现象，称为“脑裂”。网络分区会导致脑裂发生。

Raft 集群存在脑裂问题。在多机房部署中，由于网络连接问题，很容易形成多个分区。而多分区的形成，很容易产生脑裂，从而导致数据不一致。

Raft如何应对脑裂

1. 只有主节点可以写入数据

2. 写入数据的条件是，半数以上节点确认，提交数据

3. 日志复制机制

5 保证数据最终的一致性

（1） 情况1：请求到达前Leader挂了

（2） 情况2：未开始同步数据前Leader挂了

（3） 情况3：同步完部分后Leader挂了

（4） 情况4：apply通知发出后Leader挂了

领导人完全原则（Leader Completeness Property)：如果一个日志条目在一个给定任期内被提交，那么这个条目一定会出现在所有任期号更大的领导人中。保证了领导人一定拥有所有已经被提交的日志条目。