分片 vs. 分布式弹性与高可用性背后的数学原理Chris SmithJuly 14, 2025原文链接概率论Probability theory是数学中研究不确定性的分支。它帮助我们理解不同结果发生的可能性。在本文中我们将考虑两种水平扩展数据库的替代架构方案并运用概率论来评估每种架构对潜在故障的弹性resilience。垂直 vs. 水平数据库架构选项垂直扩展Vertical scaling涉及增加单台服务器的资源以提升其处理能力。这意味着为现有服务器添加更多 CPU、内存或存储资源。这种扩展方式受到单台服务器物理限制的影响并且在连接数、每秒事务数transactions per second和存储方面有着明确的上限。水平扩展Horizontal scalability涉及将工作负载分散到多台服务器上。这种方法允许向系统中添加额外的服务器提供了一条超越单台服务器能力的可扩展路径。水平数据库扩展架构选项本文考虑的两种水平扩展架构是应用层分片Application-Level Sharding和分布式 SQLDistributed SQL。应用层分片应用层分片是一种水平扩展策略它利用特定领域的知识将数据分区到运行在多台服务器上的多个数据库实例中。每个数据库实例都是隔离的使工作负载能够被扩展。这种架构需要自定义逻辑来处理路由、重新平衡和跨分片操作。分布式 SQL分布式 SQLDistributed 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详见https://cloud.google.com/compute/sla?hlen架构 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.9940149800P(5 个在线) (6 约束选 5) · p^5 · (1-p) 6 · p^5 · (1 – p) 0.0059700599P(4 个在线) (6 约束选 4) · p^4 · (1-p)^2 3 · p^4 · (1-p)^2 0.0000029880P(法定人数) 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.9900448802P(9 个在线) (10 约束选 9) · p^9 · (1-p)^1 10 · p^9 · (1-p)^1 0.0099103592P(8 个在线) (10 约束选 8) · p^8 · (1-p)^2 45 · p^8 · (1-p)^2 0.0000446413P(7 个在线) (10 约束选 7) · p^7 · (1-p)^3 40 · p^7 · (1-p)^3 0.0000000397P(6 个在线) (10 约束选 6) · p^6 · (1-p)^4 10 · p^6 · (1-p)^4 0.0000000000P(法定人数) 0.9999999204因此10 节点 RF5 基于法定人数的架构支持 99.999992% 的服务级别目标这显著高于 RF3 集群的 SLO。总结架构对可用性的影响传统架构受到单节点故障风险的限制。应用层分片加剧了这个问题因为如果一个节点宕机其分片以及整个系统将变得不可用。相比之下具有基于法定人数共识的分布式数据库如 YugabyteDB提供了容错能力和可扩展性从而实现更高的弹性和改进的可用性。直接比较架构服务级别目标单节点99.9%三个 96 节点应用层分片99.4%两个 96 节点 RF3 分布式 SQL 集群99.998%四个 910 节点 RF5 分布式 SQL 集群99.999992%七个 9宕机的业务影响数学概率可能是一个难以把握的概念。例如如果天气预报模型预测周三有 50% 的降雨概率这并不意味着半天都会下雨。然而如果预报说周四有 75% 的降雨概率该模型预测周三干燥的可能性是周四的两倍。我们计算如下P(周三干燥) 1 – P(周三降雨) 1 – 0.5 0.5P(周四干燥) 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 如何帮助您实现它。