分片 vs. 分布式：弹性与高可用性背后的数学原理
Chris Smith July 14, 2025 原文
概率论（Probability theory）是数学中研究不确定性的分支。它帮助我们理解不同结果发生的可能性。在本文中，我们将考虑两种水平扩展数据库的替代架构方案，并运用概率论来评估每种架构对潜在故障的弹性（resilience）。
垂直 vs. 水平数据库架构选项
垂直扩展（Vertical scaling） 涉及增加单台服务器的资源以提升其处理能力。这意味着为现有服务器添加更多 CPU、内存或存储资源。这种扩展方式受到单台服务器物理限制的影响，并且在连接数、每秒事务数（transactions per second）和存储方面有着明确的上限。
水平扩展（Horizontal scalability） 涉及将工作负载分散到多台服务器上。这种方法允许向系统中添加额外的服务器，提供了一条超越单台服务器能力的可扩展路径。
水平数据库扩展架构选项
本文考虑的两种水平扩展架构是应用层分片（Application-Level Sharding）和分布式 SQL（Distributed SQL）。
应用层分片
应用层分片是一种水平扩展策略，它利用特定领域的知识将数据分区到运行在多台服务器上的多个数据库实例中。每个数据库实例都是隔离的，使工作负载能够被扩展。这种架构需要自定义逻辑来处理路由、重新平衡和跨分片操作。
分布式 SQL
分布式 SQL（Distributed SQL） 数据库，如 YugabyteDB，提供了一个单一的逻辑数据库，可跨多台服务器水平扩展，并具有内置的复制和基于法定人数（quorum-based）的逻辑来实现全局 ACID 事务。可以添加额外的服务器并集成到系统中，从而扩展工作负载。自动路由、重新平衡和跨分片操作的处理简化了开发并加快了上市时间。
但**高可用性（high availability）和弹性（resilience）**又如何呢？这两种水平可扩展架构的正常运行时间特性如何比较？
在本次比较中，我们假设两种架构都在 Google Cloud Platform 上运行，使用作为 Compute Engine Service 一部分托管的 VM（虚拟机）。Google Cloud Platform 为单个 VM/实例提供 99.9% 的月度正常运行时间服务级别目标（Service Level Objective, SLO）。我们将在系统可用性计算中使用此 SLO，详见：
架构 1 – 应用层分片
什么是应用层分片？
应用分片系统将数据分区到多台服务器上，这些服务器随后半独立地运行。
- 数据在服务器之间手动分区——例如，客户 A–F 在服务器 1 上，G–L 在服务器 2 上，等等。
- 每台服务器仅负责其数据切片。
- 应用程序必须将查询路由到正确的服务器。
- 如果一台服务器发生故障，其数据将变得不可用，即使其他服务器是健康的。
该架构由多台独立运行的数据库服务器并行组成。每台服务器保留与底层单体架构相同的计算资源需求配置。
6 节点应用层分片系统的可用性
假设我们有 6 个数据库节点，每个节点都在 GCP 中自己的虚拟机实例上运行。GCP 为每个 VM 提供 99.9% 的服务级别目标。
我们知道：
- 节点可用的概率，P(节点可用) = 0.999
- 节点彼此独立
- 系统需要所有 6 个节点都可用
在概率论中，独立事件是指其结果互不影响的事件。例如，当投掷四个骰子时，每个骰子上显示的数字与其他三个骰子无关。
类似地，在 4 节点应用分片集群中，每台服务器的可用性独立于其他服务器。这意味着每台服务器都有各自可用或不可用的概率，一台服务器的故障不受集群中其他服务器故障与否的影响。
实际上，可能存在共享资源或共享基础设施将一台服务器的可用性与另一台服务器联系起来。用数学术语来说，这意味着事件是相关的。然而，我们认为这类故障的概率较低，因此在本分析中不予考虑。
从数学上讲，如果两个事件 A 和 B 是独立的，那么 A 和 B 同时发生的概率是它们各自概率的乘积：
P(A 和 B) = P(A)*P(B)
以骰子为例：
投掷一个骰子得到 6 的概率是：1/6 = 0.16667。
同时投掷出六个 6 的概率是：(1/6)^6 = 0.00002
回到我们的 6 节点数据库集群：
P(所有 6 个节点可用) = P(1 个节点可用)^6 = 0.999^6 = 0.99401
因此，6 节点分片架构支持 99.4% 的服务级别目标，这明显低于底层 VM 的 SLO。
架构 2 – 分布式 SQL
什么是分布式 SQL 集群？
分布式 SQL 数据库自动将单个逻辑数据库的数据分片到多台服务器上。此外，为了弹性，它为每个分片维护副本，并通常使用基于法定人数的算法来协调更新，确保读写操作的强一致性。
- 每个数据分片在多个节点上复制，其中一个副本被指定为 leader（领导者）。
- 写入数据需要法定人数**（多数）**（例如，如果复制因子（replication factor, RF）为 3，则需要 3 个中的 2 个）。
- 读取也需要法定人数，这通过将请求路由到 leader 来优雅地实现，避免了向所有 3 个副本发出读取并等待多数响应的需要。
- 数据不绑定到单个节点。
- 系统可以容忍节点故障并仍然提供服务请求。
6 节点 RF3 分布式 SQL 集群的可用性
假设我们有 6 个节点，每个节点都在 GCP 中自己的虚拟机实例上运行。GCP 为每个 VM 提供 99.9% 的服务级别目标。
每个节点管理一个或多个数据分片。每个分片都处于一个法定人数组中，其数据复制到其他两个节点上（假设复制因子（RF）为 3）。为了防止可用区（Availability Zone, AZ）中断和单个节点故障，集群通常分布在三个可用区中，数据分布算法确保分片的副本始终放置在不同的可用区中。
在概率论中，二项分布（binomial distribution）对一系列试验或测试期间的预期结果数量进行建模。例如，在投掷骰子时，二项分布可用于计算投掷三个骰子时得到两个 6 的概率。
我们知道掷出 6 的概率是：1/6 = 0.16667。
我们知道掷不出 6 的概率是：5/6 = 0.83333。
因此，掷出两个 6 后跟一个"非 6"的概率是：
0.16667 * 0.16667 * 0.83333 = 0.02315 = 2.315%
玩家可能以以下任意组合掷出一对 6：
- 掷出两个 6，然后是一个非 6
- 掷出一个 6，一个非 6，然后再一个 6
- 掷出一个非 6，然后是两个 6。
3 种掷骰组合会产生一对 6。因此，掷出一对 6 的概率是：
3 * 2.315% = 6.944%
计算二项分布的公式如下，假设 p 是 1 次试验中成功的概率：
P(n 次试验中 k 次成功) = n/k · p^k * (1-p)^(n-k)
其中 n/k = n 中选 k 的组合数 = n!/(k!·(n-k)!)
注意："n 中选 k 的组合"是英国术语；美国"数学"学生将其理解为"n choose k"。
因此，计算投掷 3 个骰子时得到两个 6 的概率：
P(3 个骰子中两个 6) = 3/2 · p^2 · (1-p) = 3 · p · (1 – p) = 3 * 0.16667^2 * 0.83333 = 0.06944
回到我们的 6 节点数据库集群，我们可以使用二项分布来计算 n 个节点的集群中 k 个服务器可用的概率。计算如下：
P(n 个服务器中 k 个可用) = n/k · p^k * (1-p)^(n-k) 其中 n/k = n!/(k!·(n-k)!)
我们知道：
- P(节点可用) = 0.999
- 节点彼此独立
- 节点均匀分布在 3 个可用区中
- 有许多法定人数组分布在服务器上
- Raft 组的组织方式确保副本始终位于不同的可用区中
- 如果丢失 1 个节点，只有 1 份数据副本受到影响，因此集群保持可用
- 如果丢失 2 个节点，只要它们在同一 AZ 中，只有 1 份数据副本受到影响，因此集群保持可用。
- 如果丢失 3 个或更多节点，2 份或更多数据副本受到影响，集群将变得不可用。
换句话说，6 节点系统在以下情况下可用：
- 所有 6 个节点都在线
- 恰好 5 个节点在线
- 恰好 4 个节点在线，但两个下线的节点在同一 AZ 中。
P(法定人数) = P(6 个在线) + P(5 个在线) + P(4 个在线且 2 个下线在同一 AZ 中)
在 6 节点集群中选择 4 个节点的组合，加上 2 个不可用节点必须来自单个可用区的附加约束，被称为"约束组合集（Constrained Combinatorial Sets）"。这是指从更大的组中选择项目，但具有某些限制可能组合的规则或限制。
这些约束可以基于元素之间的关系、资源限制或其他因素，从而减少有效组合的数量。在我们的案例中，我们只能从 1 个可用区中选择元素。
通过在 6 节点集群中选择 4 个节点的具体案例，我们有：
(6 选 4) = 6!/4!(6-4)! = 6!/(4!·2!) = 720/(24·2) = 15
计算 6 节点集群中 4 个节点的组合，加上另外 2 个节点必须来自单个可用区的附加约束，在数学上较为复杂，但直观地说，另外 2 个节点在 AZ1、AZ2 或 AZ3 中，因此有 3 种组合。所以我们有：
(6 约束选 4) = 3
我们将使用以下符号来描述约束组合集，约束条件为未选择的项目来自 1 个 AZ：
(n 约束选 k) 表示 在 RF3 配置中从 n 个中选择 k 个，其中 (n – k) 个来自 1 个 AZ，在 RF5 配置中来自 1 或 2 个 AZ。
回到计算：
P(6 个在线) = (6 约束选 6) · p^6 = 0.999^6 = 0.9940149800
P(5 个在线) = (6 约束选 5) · p^5 · (1-p) = 6 · p^5 · (1 – p) = 0.0059700599
P(4 个在线) = (6 约束选 4) · p^4 · (1-p)^2 = 3 · p^4 · (1-p)^2 = 0.0000029880
P(法定人数) = 0.9940149800 + 0.0059700599 + 0.0000029880 = 0.9999880279
因此，6 节点 RF3 基于法定人数的架构支持 99.998% 的服务级别目标，这明显高于底层 VM 的 SLO。
10 节点 RF5 分布式 SQL 集群的可用性
假设我们有 10 个节点，每个节点都在 GCP 中自己的虚拟机实例上运行。GCP 为每个 VM 提供 99.9% 的服务级别目标。
每个节点管理一个或多个数据分片。每个分片都处于一个法定人数组中，其数据复制到其他四个节点上（假设复制因子（RF）为 5）。
为了防止可用区中断和单个节点故障，集群通常分布在五个可用区中。数据分布算法确保分片的副本始终放置在不同的可用区中。
我们知道：
- P(节点可用) = 0.999
- 节点彼此独立
- 节点均匀分布在 5 个可用区中
- 有许多法定人数组分布在服务器上
- Raft 组的组织方式确保副本始终位于不同的可用区中
- 如果丢失 1 个节点，只有 1 份数据副本受到影响，因此集群保持可用
- 如果丢失 2 个节点，只有 2 份数据副本受到影响，因此集群保持可用
- 如果丢失 3 个节点，只要它们在 2 个或更少的 AZ 中，只有 2 份数据副本受到影响，因此集群保持可用。
- 如果丢失 4 个节点，只要它们在 2 个或更少的 AZ 中，只有 2 份数据副本受到影响，因此集群保持可用。
- 如果丢失 5 个或更多节点，3 份或更多数据副本受到影响，集群将变得不可用。
P(法定人数) = P(10 个在线) + P(9 个在线) + P(8 个在线) + P(7 个在线) + P(6 个在线)
以下所有组合都是约束组合集，约束条件为未选择的项目来自两个或更少的可用区。
P(10 个在线) = (10 约束选 10) · p^10 · (1-p)^0 = 1 · p^10 · (1-p)^0 = 0.9900448802 P(9 个在线) = (10 约束选 9) · p^9 · (1-p)^1 = 10 · p^9 · (1-p)^1 = 0.0099103592 P(8 个在线) = (10 约束选 8) · p^8 · (1-p)^2 = 45 · p^8 · (1-p)^2 = 0.0000446413 P(7 个在线) = (10 约束选 7) · p^7 · (1-p)^3 = 40 · p^7 · (1-p)^3 = 0.0000000397 P(6 个在线) = (10 约束选 6) · p^6 · (1-p)^4 = 10 · p^6 · (1-p)^4 = 0.0000000000
P(法定人数) = 0.9999999204
因此，10 节点 RF5 基于法定人数的架构支持 99.999992% 的服务级别目标，这显著高于 RF3 集群的 SLO。
总结
架构对可用性的影响
传统架构受到单节点故障风险的限制。应用层分片加剧了这个问题，因为如果一个节点宕机，其分片以及整个系统将变得不可用。
相比之下，具有基于法定人数共识的分布式数据库（如 YugabyteDB）提供了容错能力和可扩展性，从而实现更高的弹性和改进的可用性。
直接比较
| 架构 | 服务级别目标 |
|---|---|
| 单节点 | 99.9%（三个 9） |
| 6 节点应用层分片 | 99.4%（两个 9） |
| 6 节点 RF3 分布式 SQL 集群 | 99.998%（四个 9） |
| 10 节点 RF5 分布式 SQL 集群 | 99.999992%（七个 9） |
宕机的业务影响
数学概率可能是一个难以把握的概念。例如，如果天气预报模型预测周三有 50% 的降雨概率，这并不意味着半天都会下雨。然而，如果预报说周四有 75% 的降雨概率，该模型预测周三干燥的可能性是周四的两倍。我们计算如下：
P(周三干燥) = 1 – P(周三降雨) = 1 – 0.5 = 0.5
P(周四干燥) = 1 – P(周四降雨) = 1 – 0.75 = 0.25
周三与周四相比干燥的可能性 = P(周三干燥) / P(周四干燥) = 0.5 / 0.25 = 2
上面的汇总表显示，与 10 节点 RF5 分布式 SQL 集群相比，使用 6 节点应用层分片架构时故障的可能性要大得多。具体而言：
6 节点应用分片与 10 节点 RF5 相比的故障可能性 =
(P(6 节点应用分片不可用)) / (P(10 节点 RF 不可用)) = (100 – 99.4) / (100 – 99.999992) = 75000
弹性重要吗？
提供高吞吐量、实时交易服务的企业——如支付处理商和反洗钱（anti-money laundering, AML）平台——对其基础设施的弹性有着至关重要的依赖。
每一分钟的宕机都是收入的损失。它会侵蚀信任并可能导致客户流失。例如，一个每秒处理 10,000 笔交易、每笔 50 美元、收取 2% 费用的平台，仅费用方面每分钟就会损失 600,000 美元的收入。
Comply Advantage 的 CTP Mark Watson 表示，该平台实时监控交易以检测欺诈和 AML 违规行为，"一次 outage（中断）可能会让非法活动逃过检测，为我们的客户带来监管风险，可能产生数十万美元的连带责任。我们在严格的合同正常运行时间保证下运营，因为一次中断可能触发罚款和立即的高层升级。"
所以是的，弹性很重要。这就是为什么运营弹性已经超越了在故障场景期间激活的有据可查的流程和 runbook（运行手册），现在通过分布式 SQL 等弹性自愈架构来解决。
这就是 DORA（《数字运营弹性法案》，Digital Operational Resilience Act）的目的，该法案旨在通过确保企业能够承受、应对和从所有类型的技术中断和威胁中恢复，来加强欧盟金融部门的数字弹性。
结论
传统架构，特别是使用单节点或应用层分片的架构，容易发生故障且可用性有限。相比之下，具有基于法定人数复制的分布式 SQL 数据库（如 YugabyteDB）提供了显著更高的可用性、容错能力和弹性。
这种差异不仅是技术性的，更是业务关键性的：宕机可能导致巨大的收入损失、声誉损害和监管风险。随着运营需求和监管期望的增加，采用弹性自愈架构对于任何依赖高吞吐量、实时服务的企业来说都变得至关重要。
阅读我们的新白皮书"Architecting Apps for Ultra-Resilience with YugabyteDB"，了解更多关于超高弹性（ultra-resilience）的信息，为什么它对现代应用程序至关重要，以及 YugabyteDB 如何帮助您实现它。
