容错性

没有人应该在没有充分理由的情况下，将一个运行良好的简单系统转变为分布式系统。在最终决定采用分布式系统之前，必须进行深入的讨论和评估。

另一方面，正确构建分布式系统确实能带来一些在简单系统中无法实现的优势。

在本章中，我们将探讨构建分布式系统时需要牢记的核心目标。

让我们从容错性开始。

分布式系统中的容错性

任何可能出错的事情，最终都会出错。

爱德华·A·墨菲 Jr.（1918–1990）

在分布式系统的世界里，墨菲定律不仅仅是一句格言，更是一个现实。

各种各样的问题随时可能发生。

要构建一个健壮的系统，你的系统必须能够应对各种不利情况。而这样的健壮系统并非轻易就能获得——也绝非免费。它需要投入精力、付出努力并持续解决问题。作为开发者，你必须付出大量努力来实现容错性。

为了说明什么是容错性，我们来看一个场景。

这是一周一早，崭新的一周刚刚开始。你正在一家本地咖啡馆工作，喝着最爱的早晨饮品，精神饱满，充满动力，准备大展身手！

几个小时后，当你正准备收工时，屏幕突然变黑。笔记本电脑断电了！无论你怎么尝试，都无法开机！

原来，你的主板损坏了。你需要维修或更换新设备。不管怎样，你的重要工作都将被阻断一段时间。

你所经历的就是笔记本电脑的故障。在这种情况下，很可能是一种永久性的系统故障。

现在设想一下，同样的情况发生在“酷应用”（My Cool App）的后端。

如今，“酷应用”的后端由多个节点组成。数十台机器上运行着多个服务器程序。还有数据库副本，用于高效处理读请求。你也已配置了数据同步机制，确保所有数据库节点始终保持一致。

那么，如果系统中的某个节点出现问题怎么办？

注意：从分布式系统的角度来看，只要系统中任何部分出现问题，我们就称之为存在故障。

“酷应用”系统中可能出现的一些故障示例：

• 运行服务器程序的一个节点突然接收过多连接，导致内存耗尽，无法正常运行，最终崩溃。
• 两个数据库节点之间的网络通信中断，导致数据库节点间的数据同步停止。
• 系统中某个节点的硬件组件（如硬盘驱动器或主板芯片）发生损坏。
• 服务器节点无法应对流量的突然激增，导致系统崩溃。
• “酷应用”新增了一个功能，部署的代码中包含一个 NullPointerException 错误，导致运行在各节点上的服务器程序全部崩溃。

此外，还有许多其他可能性未在此列出。

在一个单节点系统中，如果某部分出现故障，整个后端瘫痪是合理的。但当你构建分布式系统时，人们期望系统能够在部分组件发生故障时依然保持运行。

这种能够容忍系统中不同部分出现故障的能力，被称为容错性。

为什么我们需要容错性

如果你有分布式系统的工作经验，就会发现，问题往往以最奇怪的方式发生。

硬件会失效，软件会有漏洞，网络会中断或崩溃。事情就是会出问题。

也许你的系统一切正常，但你很快会发现，某个依赖服务出了问题。比如外部API发生了变更，导致接口契约不再有效。

关键在于，你永远不能假设一切都会始终顺利。问题一定会发生。故障必然会出现。

这正是我们为何需要在分布式系统中具备容错能力的原因。否则，系统中任何一个微小环节的波动都可能导致整个系统崩溃——而这显然不是任何人希望看到的结果。如果允许这种情况发生，那建立分布式系统的初衷也就毫无意义了。

核心要点

• 如果系统中某个部分未能按预期运行，很可能存在故障。
• 分布式系统必须具备容错能力，以便在出现故障时仍能继续运行。
• 作为系统所有者，应始终预期故障的发生，并做好相应准备。在处理故障时，预防胜于治疗。
• 分布式系统本质上就必须具备容错能力。