“这是我自学算力大集群相关知识的第4篇笔记。在这一篇中，我们将深入容错机制，并对Raft算法的一些基本概念与框架进行了解。”
摘要
在上一篇中我们了解到复制机制，其通过主节点与副节点之间的状态复制来完成系统冗余，保障系统在线。但单一实体决定谁是主节点的问题在于，其本身存在单点故障的风险。这引发了对于构建自动故障转移系统的进一步思考。
首先，我们构建的首要目标是：能够在面对不稳定网络、可能出现故障的网络以及可能发生分区的网络时（即原先分布式网络从一个整体被分割成多个暂时不能互联的子网络时），系统依然能够正确运行。
*这里我们先对容错机制的基本思路与框架进行了解，之后再涉及Raft算法的相关内容。
- 投票机制
基于上一篇中介绍的复制机制，通过对其进行改造，并通过Raft算法实现上述目标——即采用“多数”投票机制（这里的“多数”是指该分布式网络中所有服务器的大多数，而非仅仅是活跃服务器）。建立“多数”投票的第一步是在一个分布式系统方案中采用奇数个服务器，而非偶数个服务器。当发生网络故障致使原本网络出现分区或主节点（领导者节点）发生故障/任期结束时，即会开始通过投票的方式选出新的领导者节点接管当前系统响应客户端请求。在投票的过程中需要遵循两个基本原则：
1.最多只有一个分区能够拥有多数票；
2.在第二轮投票的结果中必须有一个上一轮参与共识的节点。
这种机制，可以保证在2N+1台服务器的情况下能容忍N台服务器的故障。
此外，对于所有副本服务器，不仅需将相同的客户端操作应用于其初始状态，而且这些操作必须以相同的顺序执行对应请求。可以使用日志来达到这一目。
日志的一个作用是在跟随者节点（即副本节点）上，作为跟随者暂时存放尚未确定是否已提交的操作的地方，这些操作虽已到达但尚未被确认为已提交。
领导者一侧需要在其日志中记录操作，因为它可能需要将这些操作重新传输给跟随者，如跟随者暂时离线的情况。
设想一种场景，如果一个服务器在崩溃后重启并希望重新加入集群，那么日志就是服务器在重启后所依赖的数据源。每个使用Raft算法的服务器都需要将其日志写入磁盘，这样即使服务器崩溃并重新启动后，日志依然存在。便可从日志的开头重新执行这些操作，以此来重建崩溃时的系统状态。服务器崩溃并重后后，在读取其日志的那一刻，它不被允许对日志进行任何操作，因为它尚不清楚系统在其日志中的提交进度到了哪一步，因此，领导者节点将确定出所有副本中大多数达成共识的最新点。
- 关于Raft算法
Raft 是一种分布式一致性算法，用于确保多个服务器节点在处理数据时能达成一致。它的核心目标是解决分布式系统中最关键的“谁说了算”和“数据如何同步”问题。
算法的原理可以简单理解为：
1. Leader 选举
所有节点初始为 Follower（跟随者），通过投票选出唯一的 Leader（领导者）。如果 Leader 失效，会重新选举。
类比：班长竞选，得票过半者当选。
2. 日志复制
Leader 接收客户端请求后，将操作记录为日志条目，并复制到其他节点（Follower）。只有大多数节点确认后，操作才生效。
类比：班长把作业要求传给全班，超过一半同学完成才算通过。
3. 心跳与容错
Leader 定期发送心跳维持地位；若 Follower 收不到心跳，则触发选举。节点故障时，系统自动恢复。
Raft算法的关键特性在于：
1.强一致性：所有节点数据最终一致，适合金融、数据库等场景；
2.高可用性：允许部分节点故障，仍能继续服务；
3.易于理解：比 Paxos 更直观，适合工程实现。
其与我们之前介绍的MapReduce 的区别如下
Raft：解决分布式系统的数据一致性问题（如数据库同步）。
MapReduce：解决大规模数据计算问题（如日志分析）。
总结：Raft 是分布式系统的“交通规则”，确保数据在混乱的网络中也能有序流动。
关于Raft算法更深入的内容我们将在下期继续。
以上内容来自对 MIT 《分布式系统 6.824》的学习笔记，在此特别声明。