大家好，我是Tony Bai。
在上一讲中，我们系统性地学习了 Raft 这个为“可理解性”而生的共识算法。我们将其分解为领导者选举、日志复制和安全性三大模块，并理解了它们各自的运作原理。
理论是灯塔，指引方向；而代码是航船，载我们抵达彼岸。检验我们是否真正理解 Raft 的唯一标准，就是亲手将论文中的伪代码和状态机图，转化为真实可运行的逻辑。
今天，我们将扮演一次系统工程师的角色，用我们最熟悉的 Go 语言，从零开始，一步步地构建出一个迷你版的 Raft 核心。
明确边界：我们的迷你 Raft 能做什么，不能做什么？
在开始之前，我们必须清晰地定义本次实现的边界。我们的目标是构建一个用于教学和理解的 Raft 核心共识模块，而非一个生产级的、功能完备的系统。
本次实现将覆盖：
领导者选举：节点可以在 Leader 宕机后，通过投票选举出新的 Leader。
日志复制：Leader 可以将客户端的指令作为日志条目，复制到多数派的 Follower 节点上。
核心安全性：包含选举限制等核心安全规则，保证在非拜占庭环境下不会选出错误的 Leader。
内存存储：所有状态（当前任期、日志等）都将存储在内存中，以便于观察和调试。
为了聚焦核心逻辑，我们将简化或忽略以下内容：
持久化：我们不会将任期和日志写入磁盘。这意味着节点重启后会丢失所有状态。
客户端交互：我们不会实现真正的客户端 RPC 接口，而是通过一个简单的方法来模拟 Leader 接收指令。
状态机应用：我们只负责就日志达成共识，但不会去实现将日志应用到状态机（如 K-V 存储）的逻辑。
集群成员变更：我们的集群节点是固定的，不支持动态增删节点。
日志压缩/快照：我们不会实现日志压缩。
网络层：我们将用 Go channel 来模拟 RPC 网络通信，忽略所有真实的网络问题（如延迟、丢包、重连）。
