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