万字长文解析raft算法原理

Tags

Top Highlights

• 一味地增加节点不加以约束，最终只会导致集群内部的网络请求行为反过来成为系统瓶颈点.

• 分区容错性强调的是，在网络环境不可靠的背景下，整个系统仍然是正常运作的，不至于出现系统崩溃或者秩序混乱的局面.

• （1）倘若集群中某个 follower 出现宕机, master 同步数据时会因为未集齐所有 follower 的响应, 而无法给客户端 ack，这样一个节点的问题就会被放大到导致整个系统不可用； （2）倘若某个 follower 的网络环境或者本机环境出现问题，它给出同步数据响应的时间出乎意料的长，那么整个系统的响应效率都会被其拖垮，这就是所谓的木桶效应.

• 因此，分布式一致性共识算法，实际上是在基于各种精妙的算法机制，能够在尽可能少地牺牲 C 的基础之上，将 A 提升到尽可能高的水平.

• 每个任期内至多只允许有一个 leader.

• 同理，倘若集群 6 个节点，则多数派需要集齐 4 个及 4 个以上节点，因此同样至多允许 2 个节点开小差. 综上，这是奉行多数派原则的集群通常将节点个数设置为奇数的原因之一.

• 由全员响应进化为多数派共识，这将把一种底线思维下的随机性问题进化为一个数学期望问题.

• leader拥有更广阔的视野，需要总览全局，领导一些日常事务的推进； follower 职责相对简单但同样重要，因为这是一个基于多数派原则运作的民众团体，所有角色只要拧成一股绳，聚成了多数派，就能代表整个系统进行决断，甚至包括推翻 leader.

• 倘若 follower 率先收到了来自客户端的写请求，也需要转发给 leader 进行处理.

• 因此到此为止，raft 只能保证到数据的最终一致性，而无法满足即时一致性. 在工程落地中，也针对读操作的即时一致性提出了改进方案，具体可见本文 4.2 小节；

• 读请求也需要从状态机中获取数据进行响应.

• 这样就能解决写请求乱序的问题，从而达成数据的最终一致性.

• 倘若追求立即一致性，则会要求 leader 先应用到状态机，才能给予客户端 ack.

• 回头思考，可以发现正是这种两阶段提交的方式，实现了与多数派原则的串联打通. 因为有第一阶段的 proposal，leader 获得了群访 follower 收集民意的机会，一旦多数派达成共识，可以立即提交请求，并响应客户端，这样请求的耗时只取决于多数派中的短板，而不取决于全员的短板，大大提高了可用性.

• leader 是写请求的入口，如果出了问题，会导致整个集群不可写.

• 倘若 follower 超过一定时长没收到 leader 心跳时，会将状态切换为 candidate ，在当前任期的基础上加 1 作为竞选任期，发起竞选尝试补位.

• II 竞选期间，收到了任期大于等于自身竞选任期的 leader 传来的请求.

• 领导者是写请求的统一入口，在接收到来自客户端的写请求时，会开启“两阶段提交”的流程：

• 通过接收 leader 心跳的方式，获取到携带的 commitIndex 信息，及时完成已被多数派认可的预写日志的提交，以推进其写入状态机的进度. 这一项相当于做到了数据的备份，也被读请求最终一致性提供了保证;

• 倘若 follower 接收到了写请求，则会告知客户端 leader 的所在位置（节点 id），让客户端重新将写请求发送给 leader 处理；