Raft共识算法中current term为何必须单调递增？

为什么current term必须单调？ #

current term是Raft的核心逻辑时钟，它的单调递增是整个共识机制正常运转的基础，核心原因有三点：

• 标记全局时间顺序：term相当于集群的统一时间戳，所有节点的term只能递增不能回退。这样任意节点都能通过term判断状态的新旧，避免旧状态干扰新状态。比如节点宕机重启后，必须用磁盘上持久化的term（不能随意重置），否则会误以为自己回到了过去的任期，打乱当前集群的正常节奏。
• 确保单任期单leader：Raft的规则是每个任期最多只能选出一个leader。单调递增的term能让节点在选举时，只认可term更高的请求。如果某个节点的term突然变小，它可能会在旧任期发起选举，甚至说服其他节点回到旧任期，直接破坏leader的唯一性。
• 维护日志一致性：Raft的日志复制和term深度绑定，新term的日志必然产生在旧term日志之后。term单调递增能保证日志的顺序性，从根源上避免旧日志覆盖新日志的情况。

违反单调规则会引发什么问题？ #

如果current term不单调（比如节点重启后term被重置、出现term回退），会直接击穿Raft的共识逻辑，引发一系列严重问题：

• 脑裂与多leader并存：旧term的节点会判定当前集群没有合法leader，发起旧任期的选举。如果部分节点误接受了这个请求，就会在旧任期选出新leader，和当前运行的新termleader同时存在。两个leader都会处理客户端请求，导致数据分叉，最终集群状态彻底不一致。
• 日志覆盖与数据丢失：假设节点A的term从5回退到3，它会认为自己的日志是最新的（基于term3）。当和term5的leader通信时，它会拒绝leader的日志同步请求，甚至把自己的旧日志推给leader，导致leader的新日志被覆盖，造成不可逆的数据丢失或不一致。
• 集群共识瘫痪：节点之间term不一致会导致所有RPC请求（选举、日志复制、心跳）无法正常交互。新term节点会拒绝旧term节点的请求，旧term节点也无法理解新term节点的指令，整个集群彻底无法达成共识，失去服务能力。

内容的提问来源于stack exchange，提问作者Mark