引言

PlanetScale 既快速又可靠。我们使用无共享架构（Shared nothing architecture），能够利用本地存储代替网络附加存储，这使得我们的速度在云环境中表现最佳。而我们的容错能力则构建在易于理解但需要极为精细的原则、流程和架构之上。

我们已经多次讨论过我们的速度优势。今天，让我们来谈谈为什么我们的系统能够如此可靠。

设计原则

这些原则其实并不新颖或激进，甚至可能显得是显而易见的。然而，它们却是我们容错设计的基础。我们添加的每项功能以及进行的每次优化，均遵循或源自以下原则。

隔离

  • 系统由尽可能物理和逻辑上独立的部件构成。
  • 一个部件的故障不会传播到独立的其他部件。
  • 关键路径中的部件依赖关系尽可能少。

冗余

  • 每个部件都有多个副本，如果其中一个故障，其副本可以继续处理任务。
  • 每个部件的副本之间相互隔离。

静态稳定性

  • 当某个部件出现故障时，继续根据最后一个已知的良好状态运行。
  • 过度配置资源，以便故障部件的工作能够被副本吸收处理。

系统架构

我们的架构完全基于上述原则设计。

控制平面

  • 提供数据库管理功能，例如数据库创建、账单管理等。
  • 由多个冗余、跨多个云可用区分布的组件组成。
  • 重要性低于数据平面，因此可以有更多依赖。
  • 示例：使用 PlanetScale 数据库来存储客户与数据库元数据。

数据平面

  • 存储数据库数据和服务客户应用查询。
  • 由查询路由层和数据库集群组成。
  • 每个部分在区域和可用区内均冗余且隔离。
  • 最关键的层，依赖关系比控制平面更少。
  • 不依赖控制平面运行。

数据库集群

  • 由一个主实例和至少两个副本组成。
  • 每个实例包括 VM 和驻留在数据平面中的存储。
  • 实例均匀分布在三个可用区。
  • 在故障发生时，主库自动故障转移到健康副本。
  • 客户可以选择运行只读区域副本。
  • 企业客户还可以选择将只读区域提升为主库。
  • 极端关键，依赖关系极少。

运行流程

在上述架构中，我们应用了一些流程来强化系统的整体容错能力。

持续故障转移

  • 支持非常成熟的故障转移能力，可以将故障的主数据库快速迁移到健康副本。
  • 每周针对每个客户数据库执行故障转移测试，以验证系统变更的影响。
  • 在发生硬件故障或网络故障时（在云环境中是相对普通的情况），我们会自动执行故障转移来应对。
  • 故障转移期间，查询缓冲可以最大化减少干扰。

同步复制

  • 使用 MySQL 半同步复制和 Postgres 同步提交技术。
  • 提交在主库发送回客户端确认之前，需至少在一个副本中稳定存储。
  • 使我们可以将这些副本视为潜在主库，并在需要时立即进行故障转移。

渐进交付

  • 数据平面变更逐步应用到不同层级的环境。
  • 数据库集群配置和二进制变更可以通过特性标志（Feature Flags）逐步应用到每个数据库。
  • 发布渠道允许我们先对开发分支应用变更，等待一周或更长时间后再应用到生产分支。
  • 降低我们的错误对客户造成的影响。

故障场景的容忍能力

通过上述设计原则、架构和流程，我们能够应对各种故障场景。

非查询路径的故障

  • 因为我们的查询路径依赖关系非常少，因此查询路径以外的故障不会影响客户的应用查询。
  • 示例：假设某云服务提供商的 Docker 仓库服务发生故障，可能会影响我们创建新的数据库实例的能力，但不会影响现有实例处理查询或存储数据的能力。
  • 同样，即使控制平面完全故障，客户仅无法更改数据库集群设置，但不会影响其查询服务。

云服务提供商故障

  • 我们运行于 AWS 和 GCP，这些服务提供商可能以不同形式发生故障。
  1. 实例故障：
    • 主库实例发生故障时，我们会立即故障转移到副本。
    • 如果块存储的实例 VM 故障，会将弹性卷从故障 VM 分离并重新挂载到新的健康 VM。
    • 如果 Metal 数据库实例 VM 故障，会启动替换实例并销毁故障实例。
    • 存储故障时，块存储和 Metal 集群会以类似方式启动替换数据库实例。
  2. 可用区故障：
    • 类似于实例故障，若主库实例所在的可用区发生故障，我们会立即故障转移到健康区的副本。
  3. 区域故障：
    • 若整个区域宕机，运行于该区域的数据库集群会下线，但其他区域运行的数据库集群仍能继续运行。
    • 企业客户可以将故障转移到其他只读区域副本。

PlanetScale 自身故障

  • Vitess 或 PlanetScale Kubernetes operator 的 bug 极少影响超过 1~2 名客户，原因是我们广泛采用特性标志逐步应用修改。
  • 基础设施变更（例如 Kubernetes 升级）导致的故障可能影响更大，但因为我们严格测试且逐步发布，几乎不会发生大规模影响。

结论

基于严格原则、稳健架构和成熟流程，我们能够处理多种故障场景，同时最大化减少对客户的影响。PlanetScale 的容错能力不仅建立在先进技术上，还体现了我们对托管服务稳定性和可靠性的坚定承诺。


极端容错设计原则插图

关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台

除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接

本文链接：https://choupangxia.com/2025/09/14/the-principles-of-extreme-fault-tolerance/