分布式系统里最尴尬的场景，是5个人同时举手说"我来当老大"。Raft算法用一行随机数解决了这个问题——150到300毫秒之间随便挑一个数，先响铃的人赢。这个设计看起来太随意了，但数学上它能让选举成功率飙到99%以上。
本文用原文的推导逻辑，算清楚这个"抽签"为什么不会反复撞车。
死锁是怎么发生的：心跳消失后的集体 panic
Raft集群的正常状态很简单：Leader定时发心跳，Follower安静接收。一旦Leader宕机，心跳停止，所有Follower都在等同一个信号——选举超时。
问题是它们等的时长原本是一样的。
假设5台服务器都设置150毫秒超时，网络延迟让它们的检测时间有微小差异，但差异太小。150毫秒一到，5台同时变成Candidate，各自投自己一票。总票数5张，每人1票，没人过半。选举失败，全员退回Follower，重新等待超时。
如果重试时还是固定150毫秒，它们会再次同时触发，再次平票，无限循环。这就是活锁（livelock）：系统没崩溃，但永远选不出Leader。
工程师的第一反应可能是"加个随机退避"，比如失败后随机等50-100毫秒再试。但Raft的作者发现，根本没必要等失败——第一次超时本身就应该是随机的。
关键洞察：时间差比绝对时间更重要
随机化的目标不是"让某人先超时"，而是"让第一个和第二个超时的人拉开足够大的差距"。
假设Server A抽中173毫秒，Server B抽中214毫秒，网络往返延迟2毫秒。A在173毫秒时发起投票请求，B在174毫秒收到——此时B自己的计时器还要40毫秒才响。B看到A的请求，直接投票给A，自己不会进入Candidate状态。
40毫秒的缓冲，让A在B"觉醒"之前就锁定了多数票。
这里的核心变量是：最小值与次小值的差距（gap）。如果gap > 网络延迟，选举干净结束；如果gap < 网络延迟，多个Candidate同时活跃，可能分裂投票。
原文给了一个具体场景：5台服务器，超时窗口150毫秒（150-300ms均匀分布），网络延迟5毫秒。问：最小值和次小值差距超过5毫秒的概率是多少？
概率计算：为什么150毫秒的窗口够宽
5个独立均匀分布在[0, 150]的随机变量，排序后得到X₁ ≤ X₂ ≤ X₃ ≤ X₄ ≤ X₅。我们需要P(X₂ - X₁ > d)，其中d=5ms。
均匀分布的顺序统计量有标准解法。5个点的分布相当于把区间分成6段，每段长度服从联合Dirichlet分布。最小间隙的分布可以用组合方法推导。
原文给出的结果是：对于5台服务器、150毫秒窗口、5毫秒延迟阈值，干净选举的概率约为99.2%。这意味着100次选举中，只有不到1次会因为时间差太小而陷入分裂投票。
如果窗口缩到50毫秒，同样条件下干净选举概率暴跌。如果服务器数量增加到10台，概率也会下降，但150毫秒的窗口仍然够用——因为分子（窗口宽度）和分母（服务器数量）的关系是对数级的。
150-300ms这个具体数字不是拍脑袋。太短则网络抖动容易覆盖时间差，太长则故障恢复太慢。150毫秒的宽度，是在"快速恢复"和"高成功率"之间的经验平衡点。
工程细节：随机源和网络不对称
实际实现中还有两个坑。第一，随机数质量。如果所有服务器用同一个种子，或者系统时钟高度同步，"随机"就失效了。生产环境通常用硬件熵源或独立种子。
第二，网络不是对称的。A到B的延迟可能不等于B到A的延迟，甚至差距很大。Raft的投票请求是单向广播，Candidate不需要等待所有响应才继续，这降低了不对称性的影响——只要大部分节点及时收到，选举就能推进。
原文提到一个反直觉的点：随机化不仅解决了分裂投票，还隐含地解决了"脑裂"风险。如果网络分区导致两个子集各自选举，只有获得多数派的那边能继续服务；随机化让这种冲突更快决出胜负，而不是两边僵持。
150-300ms的窗口在万兆网络、同机房部署的场景下显得保守。但Raft的设计目标是通用性——它要能在跨机房、云环境、甚至部分节点高负载的情况下工作。保守的窗口是对现实世界的容错。
最后留一个问题：如果你的集群有100个节点，网络延迟波动到50毫秒，这个150毫秒的窗口还够用吗？还是需要动态调整？
热门跟贴