三节点集群为何挂一台能用、挂两台瘫痪？多数派协议详解

看到这个标题我猜你八成是做后端或者运维的朋友。当年我刚开始管三节点分布式集群的时候也问过一模一样的问题明明有三台机器挂一台读写一切正常挂两台就整个服务瘫痪这也太离谱了吧后来在故障演练里亲手把集群折腾挂掉我才彻底想明白——高可用从来不是靠堆机器数量而是靠一套叫“多数派”的规则。今天就用一篇实操向的博客把这个问题的原理、公式、故障现场和避坑经验一次讲透看完你不但能解释清楚“三台坏一台能用、坏两台瘫痪”还能顺手把这套逻辑用到集群选型、变更发布和故障恢复里。1. 先还原现场三节点集群到底在干什么1.1 “存三份”为什么不够从拷贝到共识普通人的直觉是三台机器各存一份数据坏掉一台还有两台可以顶上坏掉两台还剩一台数据明明还在为什么就不能用了这个直觉错在把“数据还在”等同于“服务可用”。分布式多副本集群要回答两个问题第一一次写入是否在足够多的节点上成功落盘第二所有节点看到的数据是否一致。如果系统只剩一个节点它对外说“数据没问题”但它根本不知道另外两个节点是死了、慢了、还是被网络切断了。它继续接受写入等另外两台重新连回来三台机器上的数据就对不上了。客户端在故障前读到的是值 A故障后读到的是值 B谁都说不清哪个才是对的。所以多副本集群不能靠“谁能响应就让谁服务”必须靠一套规则来消除这种不确定性这套规则就是共识。行业里最主流的做法用一句话就能说清——多数派任何一次写入必须让超过半数的节点确认成功才允许返回成功任何一次选主必须拿到超过半数的票才能当选。这里还有一个容易被忽略的关键点多数派里的“总节点数”是集群的初始规模而不是当前存活节点数。挂了两台以后剩下 1 台确实是“存活节点中的全部”但协议不这么算。协议关心的是“这个操作能不能被足够多的副本确认”而这个“足够多”永远是相对于集群设计时的总规模来说的。三节点集群的多数派永远是 2不会因为剩余节点少了就自动降级成 1。1.2 多数派写读一切高可用的地基把多数派规则套到三节点上标题里的现象就一目了然坏 1 台剩余 2 台2 ≥ 2多数派还在系统继续服务。坏 2 台剩余 1 台1 2多数派没了系统必须停摆。停摆不等于数据丢了而是“没有资格对外做出权威承诺”。这是很多人没转过弯来的地方。多副本系统宁可短暂不可用也不敢在多数派缺失时继续接受写入。用一句话概括可用性重要但一致性更重要当两者冲突时分布式系统默认选择安全。这也是为什么你在生产环境里看到的协调集群、注册中心、分布式锁服务几乎都采用了这套多数派模型。2. 多数派背后的数学账几台机器能扛几次故障2.1 一个公式最多容忍 N/2 台故障把多数派抽象成数学N 个节点的集群多数派数量 Q ⌊N/2⌋ 1也就是向下取整再加一。系统最多能容忍的故障数 F ⌊N/2⌋。只要故障数不超过 F剩余节点数就不少于多数派一旦故障数达到 F1剩余节点数低于多数派系统自动失效。代入几个常见值N3Q2F1坏 1 台没事坏 2 台瘫痪。N5Q3F2坏 2 台没事坏 3 台瘫痪。N7Q4F3坏 3 台没事坏 4 台瘫痪。规律很明显每增加两台机器多获得一次容错能力。三节点和四节点都是容一台故障五节点和六节点都是容两台故障。这也是行业集群节点数几乎都是奇数的根本原因偶数节点不会带来额外的容错只会白白增加成本。这里还要澄清一个容易混淆的点F 说的是“任意并发故障组合”。三节点坏两台瘫痪意思是任意两台同时故障都会瘫痪不管它们是进程崩溃、整机掉电还是被网络隔离。它和“一台故障恢复后再坏下一台”完全是两回事。滚动升级逐个重启不会触发瘫痪原因就在这里而升级脚本一时疏忽让两台同时处于不可用状态立刻就瘫痪。2.2 为什么奇数节点是行业默认偶数节点是坑常见困惑是我上 4 台是不是比 3 台更稳答案很扎心容错能力完全相同都只能坏 1 台。4 台坏 2 台剩下 2 台但多数派需要 3 台⌊4/2⌋132 3照样瘫痪。多出来的那一台并没有把容错上限从 1 变成 2它只是在没有故障时提供了更充裕的负载能力可不便宜。更麻烦的是偶数节点可能制造僵局4 台机器发生网络分区变成 2 对 2两个分区各自都拿不到多数派整个集群直接停摆。虽然这种分区没有引发脑裂但可用性比奇数节点更差。三节点分区最坏情况是 1 对 2其中一个分区刚好凑够多数派还能继续服务。奇数节点不是玄学是数学和可用性共同推出来的结论。用一个生活类比帮助理解一个 5 人表决的董事会要 3 票才能通过决议。如果 5 人分成 2 人一派和 3 人一派票多的那派说了算少数派闹也没用。但如果 4 个董事分成 2 对 2谁说了都不算公司只能僵着。多数派协议要的就是“任何时刻必须有一个派别能说了算”而不是“大家先各干各的以后再算账”。3. 共识算法工作过程选主与日志提交3.1 选主半数以上同意才算数多副本系统通常采用一主多从模型一个节点是主节点负责接收客户端读写其他节点是从节点负责同步数据并在主节点故障时参与选主。集群里所有节点会维护一个单调递增的任期号每次选主都会让任期号加一。当从节点长时间收不到主节点的心跳它就会进入候选状态给自己投一票同时向其他节点拉票。要成为新的主节点必须拿到超过半数的选票。三节点里如果两台同时宕机剩下的那个节点只能拿到自己的一票永远凑不够 2 票于是它会反复超时、反复发起选举一直停留在“无法确认谁是主”的状态。这个设计最关键的一点是旧主节点不会因为网络抖动自动退位。如果旧主节点还活着但它所在的分区凑不齐多数派它即使继续发心跳也无法完成任何新的数据提交。真正掌控系统的永远是“有资格凑齐多数派的那一组节点”而不是“上一轮当选的那个节点”。理解了这一点就理解了为什么挂两台后整个集群宁可不可用也不敢让剩下一台继续写。3.2 写入与读取多数派确认的完整链路一次正常写入的流程是这样的客户端把写请求发给主节点。主节点把数据作为一条日志记录并行发给所有从节点。从节点收到后落盘并向主节点回确认。主节点统计确认数量达到多数派三节点就是 2后把这条日志标记为已提交。主节点给客户端返回成功同时把提交结果广播给所有从节点。挂一台时主节点加上一个正常从节点能凑齐 2 个确认写入照常成功只是确认时间可能略微变长。挂两台时主节点即使在自己本地把日志写好了最多也只有自己这 1 个确认达不到 2于是只能拒绝写入。客户端看到的表现就是请求超时、写入失败。读取路径很多人会忽略。如果业务能接受“读到的数据可能不是最新”可以从任意副本读速度快但不够严谨。如果需要线性一致读也就是读到的数据一定是此前所有已确认写入的结果通常要走一次多数派确认或者强制从主节点读取。在 N3、W2、R2 的经典配置里写需要 2 个节点确认读也需要 2 个节点响应写集合和读集合必有交集所以能保证读到最新值。这就是读写多数派的精髓W R N。生产环境里很多注册中心、配置中心、分布式锁的底层都是这套逻辑。3.3 只剩一个节点时为什么不继续服务这是我被问得最多的问题剩下那台机器上明明有完整数据让它继续只读行不行哪怕拒绝写入、只提供读服务也比直接瘫痪强吧从工程上讲“只读降级”在某些系统里确实存在但需要非常慎重。剩下一台节点无法确定自己是多数派中的一员它提供的数据可能是过期的尤其是旧主节点宕机前刚刚写入、还没来得及复制到其他副本的日志。客户端如果在故障期间读到这种“从未被外部确认过”的数据外部一致性就被破坏了。更危险的是如果允许它在两节点故障时继续接受写入等另外两台恢复后冲突将不可收拾。你无法判断哪份数据才是正确的只能靠人工介入这比短暂不可用可怕得多。所以标准多副本系统的默认策略是无法满足多数派就停止对外提供服务。记住了这是一种保护不是故障。4. 实操记录亲手把三节点集群搞挂一次4.1 演练之前的准备理论说再多不如动手一次。我做故障演练时准备了三台虚拟机和一个小型三节点集群模拟配置中心或分布式锁的存储后端。业务侧有一个后台任务持续写入心跳数据同时用一个脚本定期观察集群状态。开始前先确认三台都健康并记下当前主节点是哪台。演练有两个关键动作模拟宕机用停止进程模拟网络分区用防火墙规则丢包。这两种故障形态在真实世界都很常见一定要分别演练。开始之前还要把日志采集和监控打开记录每个时间点集群状态的变化、请求成功率、客户端报错信息。没有监控的故障演练等于白练因为你根本说不清系统是什么时候开始恢复的。4.2 挂掉第一台毫秒级抖动我先把当前主节点直接停止。几秒钟后剩余两台机器因为收不到心跳开始进入选主流程。其中一台从节点给自己投票并请求另一台投票另一台同意后这台节点拿到 2 票当选为新主节点。整个过程在几秒内完成具体耗时由心跳超时和选举超时两个参数决定通常配置在几百毫秒到几秒之间。客户端这边的表现是监控曲线出现一次短暂抖动连接池里原来指向旧主节点的连接全部失效重试逻辑触发请求被转发到新主节点。因为心跳频率设置得比较快实际业务中断只有几秒钟业务侧配了重试机制的话用户几乎无感知。这验证了一个结论“挂一台还能用”并不是零中断而是自动完成选主切换。这里有个细节容易被忽略客户端连接的是旧主节点的地址它必须具备故障感知和自动重连的能力。我见过很多生产事故集群其实选主成功了但客户端没有及时重连一直向一台已退位的节点发请求导致业务侧误以为整个集群挂了。4.3 挂掉第二台服务真正瘫痪的瞬间接下来把另一台节点也停掉三台里只剩一台。我盯着监控剩下的那台尝试发起选举日志里出现选举超时然后再次选举循环往复。客户端请求开始大量超时写入和读取全部失败。整个集群对外表现为拒绝服务。瘫痪的根因非常清晰剩下 1 台机器无论怎么选最多只能拿到 1 票不满足 2 票的多数派条件无法产生合法主节点。没有主节点就没有人能把写请求落到多数派上。这不是某个程序的 bug是共识协议的预期行为。每次看到这里我都会提醒团队故障演练的目的不是“把系统搞挂看好戏”而是让每个参与的人亲眼看到多数派缺失时系统的真实反应这样才不会在半夜收到告警时手足无措。4.4 恢复过程与重启顺序恢复其实很简单把停掉的两台节点重新启动。它们启动后会先以从节点身份加入向存活节点同步日志。当集群里的活跃节点数重新达到 2 时多数派成立触发新一次选主第三台随后同步完成集群回到健康状态。恢复顺序值得多说一句尽量不要把最后一台健康节点也重启。如果三台一起挂恢复时要有顺序地一台一台启动给每台留出发现彼此的时间。同时要注意新加入的节点不能带着旧数据强行当主必须接受已有主节点的日志同步。很多人恢复时图省事直接对旧数据做手动覆盖结果把已提交的数据搞丢比原来的故障严重得多。5. 常见的翻车现场与排查速查表5.1 场景一滚动升级两台同时不可用最常见的事故不是硬件故障而是变更。给三节点集群做版本升级时如果自动化发布平台配置了并行重启或者人工操作手快一次重启了两台集群立刻失去多数派。我印象很深的一次事故是发布脚本在滚动重启到第二台时没有等待前一台完全恢复导致集群瞬间瘫痪页面和接口全部报错。解决办法是给变更流程加上明确的串行约束同一时间最多一台处于停止状态必须等一台恢复健康、确认它已经跟上日志再处理下一台。发布平台里的并行度参数一定要设成 1同时要加一个前置检查发起变更前集群内健康节点数必须大于多数派否则停止变更。5.2 场景二网络分区被误判为宕机停机会让多数派缺失网络分区也会。假设三台机器分布在两个机柜网络设备故障导致机柜间断连变成 21 两个分区。2 台的那个分区能满足多数派会继续选主并提供读写1 台的那个分区里如果恰好是旧主节点它会发现自己无法获得多数派确认于是停止接收写入变成不可用状态。这个现象经常被误判监控显示某台机器没有宕机但服务就是不可用其实是它所在的少数派分区被协议强制降级了。模拟网络分区可以用防火墙规则搞定# 在目标机器上执行模拟与对端节点断连 iptables -A INPUT -s 对端IP -j DROP iptables -A OUTPUT -d 对端IP -j DROP如果是跨机房部署节点分布更要算清楚。3 个节点分布在 3 个机房任何机房故障后还剩 2 台勉强满足多数派但如果是 2 个机房一个机房放 2 台、另一个放 1 台那只有 1 台的那个机房一旦故障集群直接失去多数派。所以部署前必须回答一个问题最多能容忍哪个机房整体挂掉5.3 场景三强制恢复的救急与代价极少数情况下比如多数派节点永久损坏业务又必须恢复一些系统提供了强制单节点模式或重置集群之类的逃生门。把存活节点强制设置为新集群的起点其他节点恢复后以它为基准继续同步。这个操作能救命但代价非常大所有未同步到该节点的已提交数据都会丢失。所以这个操作应该视为最后手段。触发前至少要做两件事先完整备份存活节点的数据目录再确认业务可以接受数据丢失。我见过有人把强制恢复当成常规恢复手段结果把故障后的脏数据当成了权威数据后面花了数倍时间做数据订正得不偿失。记住强制恢复是用来“止损”的不是用来“省事”的。5.4 写给小白的巡检清单检查项推荐做法说明节点总数奇数推荐 3 或 5偶数不增加容错变更并行度串行同一时间最多一台不可用滚动升级最大杀手健康节点数告警少于多数派必须 P0 告警多数派缺失就是不可用选主切换监控记录切换次数和耗时频繁切换说明网络不稳定数据备份定期备份演练恢复流程强制恢复时要靠它这条清单适用性很广不限于某一个具体组件。我每次给团队做培训都会发一遍大家反馈都是“早点看到能少踩一半的坑”。6. 节点数量怎么选3台、5台还是7台6.1 容错能力对照表节点数多数派最多容忍故障说明110单点无高可用220坏一台即不可用321最常见的最小集群431与 3 相同容错成本更高532生产环境推荐743更高可用成本与写放大明显读这张表会发现一个实用结论如果当前只有 3 台最需要做的是保证任何时刻最多只有一台不能服务如果业务非常重要直接上 5 台一次性把容错上限提到 2 台。5 台比 3 台只多了约 40% 的成本却把“任意两台同时故障导致瘫痪”的概率降低了一个数量级。有人会问两台节点能不能做高可用两台机器多数派需要 2 票坏一台就没人能凑齐确认所以双节点集群往往需要引入一个外部仲裁节点。仲裁节点不存业务数据只参与投票本质上你还是需要三个投票角色只是其中一个不存数据。这也是为什么很多数据库的“两节点加见证”方案选型和故障行为都要按三节点去理解。6.2 成本与性能的取舍增加节点不只是多买两台机器。每个写请求都要复制给多数派节点节点越多网络和磁盘的写放大越高在低速磁盘或跨机房链路上这个开销会被放大很多倍。我实践里见过不少集群读写性能瓶颈不是 CPU而是副本同步的磁盘 IOPS。所以节点数不是越多越好够用就行。如果容灾要求更高还可以考虑三机房五节点之类的布局把 5 个节点分布在 3 个机房任意一个机房整体故障剩下两个机房至少还有 3 台节点多数派依然成立。这种布局业务容错能力很强但跨机房延迟必须提前压测。很多团队不是被算法难倒而是被跨机房间的那几十毫秒延迟害得天天告警。选型和压测一定要结合起来只看理论容错数是不靠谱的。7. 结尾几条用教训换来的心得聊到最后我想把这几年的实际体会再浓缩一下。最重要的一条是永远别把“集群有 N 台机器”等同于“能坏 N-1 台”。多数派规则决定了它能承受的任意并发故障上限只有一半左右这是数学底线不是 bug。你可以在架构图上多画几个节点但故障发生时协议只认票数。第二变更操作比硬件故障更容易杀死集群。我踩过的坑里十次有八次是滚动升级、批量重启、运维脚本误操作搞出来的。给所有变更加上“同一时间最多一台不可用”的硬约束比任何高可用架构都实在。第三如果真的面临多数派缺失先冷静。不要急着重启所有节点更不要轻易使用强制恢复。按顺序拉起节点等待日志同步完成大多数情况下集群会自动恢复。数据丢失不可逆多备份、多演练关键时刻能救命。回到标题那个问题三台机器挂了一台还能用挂了两台就瘫痪本质是多数派协议在保护你的数据安全。理解了这一点你再去看分布式系统里的选主、同步、脑裂、节点数量选型就全都串起来了。希望能帮你少踩几个坑。