5-8 大量服务器的故障排除 · 波仔的云计算课

📄 一句话概括

一台机器会坏，这件事没有解法——能做的是让坏的代价变小。双机主备是【坏一台就切换一次】，三机容错是【坏一台当作常态，继续跑】。而三机能自动决定的原因只有一个：3 台里有 2 台同意才算数（多数派）——所以坏的超过一半时，剩下的那台会主动停服，因为【停服】比【两个人都以为自己是主】安全得多。

📝 本节和前面几节的关系

上一节讲【怎么发现出事】，这一节讲出事之后系统怎么继续提供服务。

它的思路和存储技术① 面向数据中心完全一致：那一节讲的 RAID 是【把多块硬盘变成一个不会因为坏一块就停的磁盘】，这一节讲的是把多台服务器变成一个不会因为坏一台就停的服务。它也接着 2-10——那一节讲灾备的四个等级（RTO 从数小时到接近零），这一节讲的是其中【最高那两档】在服务器层面怎么实现。

一、三种做法：坏一台的代价不一样

方案	坏 1 台会怎样	一年中【有感的】中断
单台	整个服务停	87.6 小时
双机主备	切换，约 30 秒	约 43.8 分钟
三机容错	无感，另两台继续	0 分钟（坏 1 台时）

这张表要读出来的不是【三机最好】，而是【三种方案在防不同的东西】：

单台：什么也没防，机器一坏业务就停。它的【87.6 小时】是按单台可用性 99% 算出来的。
双机主备：防住了【机器坏】，但切换这件事本身会中断业务（本节按 30 秒算）。一年坏 87.6 次，加起来就是 43.8 分钟——比单台好得多，但仍然是【感觉得到】的。
三机容错：坏一台根本不需要切换，因为另外两台一直在正常工作。所以坏 1 台时，用户完全不知道。

换句话说：双机是【坏了再救】，三机是【一直有富余】。 这个差别在一年里就体现为那 43.8 分钟。

二、动手 Demo：多数派与代价

看到什么算成功：

==================================================================================================
【Demo 8】大量服务器的故障排除：三机容错
==================================================================================================
  一台机器会坏，这件事没有解法。能做的是【让坏的代价变小】。

  【一】三种做法的对比（单台可用性都按 99.0% 算）

  方案              坏 1 台会怎样                 一年中【有感的】中断
  ----------------------------------------------------------------------------------------
  单台              整个服务停                    87.6 小时
  双机主备          切换，约 30 秒                约 43.8 分钟
  三机容错          无感，另两台继续              0 分钟（坏 1 台时）

  双机那 43.8 分钟是怎么来的：一年主节点坏 87.6 次，
  87.6 x 30 秒 = 2628 秒 = 43.8 分钟。

  三机不是不会坏，而是把【坏 1 台】从【故障】降级成了【常态】。

  【二】三机为什么能自动决定：多数派
    3 台里，任何决定都要有 2 台同意才生效。
      · 坏 1 台：剩 2 台，还是多数 → 继续工作
      · 坏 2 台：剩 1 台，不是多数 → 这一台【主动停服】

  最后这条很反直觉：剩最后一台时它明明还活着，为什么要停？
  因为如果它继续服务，而另外两台也各自醒来继续服务，
  就会出现【两个都以为自己是主】——这叫脑裂，比停服危险得多。
  宁可不服务，也不能给出两个互相矛盾的答案。

  【三】代价

  资源项            单份            三副本          多花多少
  ------------------------------------------------------------------------------
  存储空间          1 份            3 份            3 倍
  服务器台数        1 台            3 台            3 倍
  许可与电费        1 份            3 份            3 倍

  所以容错级别是【按业务重要性买的】，不是越高越好。
  全公司都上三副本，等于为所有业务都付三份钱。

读结果：

第一张表的算法值得记一下：双机那 43.8 分钟不是算出来的故障时间，是算出来的【切换时间】——87.6 次 × 30 秒。这说明了一件事：双机主备的瓶颈不在机器可靠性，在【切换有多快】。 所以有人会把切换时间从 30 秒优化到 5 秒，那 43.8 分钟就变成 7.3 分钟——这是双机方案里最值得投入的优化点。
第二段是本节最需要理解的部分：剩最后一台时【主动停服】，看起来是把自己的能力浪费了。但这是有意的——因为分布式系统里最危险的状态不是【不工作】，而是【两个部分都以为自己是唯一的主】。它们会各自接受写入、各自给用户答案，事后无法合并。 所以【宁可停服】是这条设计原则的名字：用可用性换正确性。

三、为什么「多数派」这个数字是 2

三台里要有两台同意，这个【2】不是随便定的，它来自一个很实际的考虑：

台数	多数派需要几台	能容忍坏几台	还剩几台
2	2	0	坏一台就没了
3	2	1	2
4	3	1	3
5	3	2	3

看这张表会发现一个规律：偶数台没有意义。

2 台：多数派是 2，也就是说【两台都必须活着】——和单台一样，没有容错能力。
4 台：多数派是 3，还是只能容忍坏 1 台——和 3 台一样，但要多花一台的钱。

所以【容错集群的台数应该是奇数】：3 台容忍 1 台，5 台容忍 2 台。这不是数学上的玄学，是【多数派】这个规则直接推出来的结论。 现实里最常用的是 3 台——因为它是达到【容忍 1 台】的最小配置。

同样的道理也用在存储上：4-15 里讲 Ceph 的三副本——三份数据放在不同的故障域里，任何一份丢了都还在，而读写还能继续。这就是同一条原则在数据层面的应用。

30 秒实验

打开任意一家云服务商的【高可用】或【容灾】产品文档，做两件事：

找【可用区】这个词，看它建议把几个实例分布在几个可用区（多数会写【至少两个，建议三个】）。
看它的托管数据库产品（比如托管 MySQL）默认是几副本。

做完这个你会看到一件事：云服务商在这些产品上几乎不给【单副本】的选项，因为单副本的机器一坏，它就要对客户负责。这也解释了一个现象：托管的数据库比你自己在虚拟机上装一个贵的那些钱，有很大一部分就是买这个【默认多副本】——你不需要自己去设计三机容错，因为它默认就是这么部署的。

常见误区

错误：用了三机容错，系统就不会停了。——纠正：三机只解决【一台机器坏掉】，不解决别的。如果三台机器跑的是同一个有 bug 的版本，它们会一起出问题（因为故障原因对三台来说是共同的，不是独立的）；如果三台共用同一个电源、同一个交换机、同一个机房，那一次事故就能全灭。所以容错设计里有一条关键要求：副本要放在【不同的故障域】——不同的机架、不同的可用区。放在一起的三副本，等于一份。
错误：容错级别越高越好，全公司都上三副本。——纠正：容错的每一级都是用钱买的（本节 Demo 第三段：存储、台数、许可全部变三倍）。如果所有业务都上三副本，等于为所有业务都付三份钱——包括那些【停两小时也没关系】的内部系统。正确的做法是按业务重要性分级：核心交易系统上最高级别，内部报表系统能用双机就够了。这也是为什么 2-10 里就说过【不是越高越好，是算出来该多少】。
错误：剩下的那台明明是好的，停掉是浪费。——纠正：停服是它【主动的选择】，不是故障。如果它继续提供服务，就可能出现【这一台认为自己是主，另外两台苏醒后也各自认为自己是主】——三个节点各自接受写入，数据被分成三份且互相矛盾。这种情况（脑裂）比停机严重得多：停机只影响这段时间的可用性，脑裂会把数据搞坏，事后无法自动修复。所以分布式系统里有一条铁律：拿不准自己的状态时，选择停止服务。
错误：双机主备是最省钱的容错方案。——纠正：从资源角度确实最省，但要算上【切换带来的中断】和【复杂性】。双机方案里有一个很麻烦的问题：主备之间的心跳断了怎么办（网线松了、交换机抖动）——如果主节点还在正常工作只是联系不上备用节点，备用节点要不要接管？ 接管就可能脑裂，不接管就可能一直等着。所以双机方案通常还需要第三台来做仲裁——算上这一台，它就不比三机便宜了。 这就是为什么大多数现代高可用方案直接采用奇数台集群。

自测三问（点开对答案）

1. 为什么容错集群的台数要用奇数？ —— 因为**多数派的门槛决定了容错能力，而偶数台会浪费**。3 台需要 2 台同意，能容忍坏 1 台；4 台需要 3 台同意，**还是只能容忍坏 1 台**——多出的那一台完全没有增加容错能力，只是多花钱。5 台需要 3 台同意，能容忍 2 台。所以**从【达到某个容错目标】的角度看，最小的配置总是奇数**：要容忍 1 台就用 3 台，要容忍 2 台就用 5 台。**偶数台的存在意义只在于【同时要处理更多读写】，不在于容错。** 2. 为什么剩下最后一台时要【主动停服】？ —— 因为**它无法确认自己看到的状态是不是最新的**。极端情况下，另外两台可能并没有真正宕机——**只是网络断了，而它们仍然在正常工作、仍然在接受写入**。如果这时候最后一台也继续服务，**就会出现两个（或三个）互不知情的【主】，各自接受修改，产生两份互相矛盾的数据**。而【停服】是一个**可恢复的错误**：网络恢复之后大家重新选主就好。**数据矛盾则是不可恢复的**：谁也不知道哪一份是对的。**用可用性换正确性，是分布式系统的通用取舍。** 3. 为什么【副本要放在不同故障域】这件事这么关键？ —— 因为**容错的前提是【故障是独立的】**。三副本的理论依据是【三台机器同时坏的概率极小】——**但这个推算成立的前提是：它们的故障互不相关**。如果三台机器在同一个机架上，那么【机架断电】会让三台同时失效；如果三条线走同一根光缆，那么【施工挖断】会一次全断。**这时候三副本等于一份。** 所以容错设计里，**副本放置策略（放哪、隔多远）和副本数量同样重要**——这也是云上【可用区】这个概念存在的意义。