Raft 是一种共识算法，旨在使分布式系统中的多个节点能够就状态机的更新达成一致。它由 Diego Ongaro 和 John Ousterhout 在 2013 年提出，目标是提供一个比 Paxos 更容易理解和实现的替代方案。
Raft 算法的主要组成部分
节点角色：
- 领导者（Leader）：负责处理所有客户端请求，并将更改日志复制到其他节点。只有领导者可以向集群提交日志。
- 跟随者（Follower）：被动地响应来自领导者或候选者的请求，不主动发送请求。
- 候选者（Candidate）：当跟随者无法联系到领导者时，会变为候选者并开始进行选举，以成为新的领导者。
日志条目：
- 每个状态变更都以日志条目的形式存储在各个节点中。这些条目包含命令及其对应的索引。
选举过程：
- 节点会定期重置其“心跳”计时器。如果某个跟随者在一定时间内未接收到来自领导者的心跳信号，则会转变为候选者并发起选举。
- 候选者会向其他节点请求投票，如果获得大多数节点的投票，它将成为新的领导者。
日志复制：
- 领导者接受来自客户端的写入请求，将这些请求作为新的日志条目添加到自己的日志中，然后异步地将这些条目复制到跟随者。
- 一旦大多数节点都成功写入该条目，领导者会向客户端确认操作成功。
安全性和一致性：
- Raft 确保一旦某个日志条目被提交并且已经被应用到状态机中，那么这个条目不会丢失，也不会出现不同值的情况。
- Raft 强制遵循一些规则，如每个新的领导者必须包含已提交的所有日志项，这样即便旧数据依然可以保证安全性和一致性。
工作流程
初始化阶段： 当集群启动时，每个节点开始作为一个跟随者。
心跳机制： 领导者定期发送心跳消息给所有跟随者，以维持其身份。
处理客户端请求： 客户端发出写入请求，领导首先将该请求转换为一个日志项，然后将其记录下来，并传播给所有跟随节点。
日志提交与状态更新： 当超过半数的跟随者确认收到并存储了该日志项后，领导才会向客户端返回结果，并通知所有节点应用此项更新至他们各自的状态机。
优势与缺点
优势
- 简单易懂，比 Paxos 更容易实现。
- 提供强一致性保证，确保系统的一致性与可靠性。
缺点
- 性能上可能因网络延迟而受到影响，特别是在较大的集群中，需要更多通信来维持一致性。
应用场景
Raft 广泛用于需要高可用性和数据一致性的分布式系统，例如数据库、文件存储系统、区块链技术等。许多现代开源项目，如 etcd、Consul 和 RethinkDB，都使用 Raft 来管理分布式共识。
内容由零声教学AI助手提供，问题来源于学员提问
