文章对比了应用层分片和分布式SQL两种数据库架构的可靠性。通过概率计算，表明分布式SQL架构的可靠性远高于应用层分片，尤其是在高吞吐量、实时交易服务中，弹性至关重要，停机损失巨大。
译自：Sharded vs. Distributed: The Math Behind Resilience and High Availability
作者：Chris Smith
概率是数学的一个分支，它处理不确定性。它帮助我们理解不同结果发生的可能性。下面，我们考虑了两种用于水平扩展数据库的替代架构选项，并运用概率论来表明，一种架构的可靠性比另一种高出 60,000 倍。
水平数据库扩展架构选项
应用层分片
应用层分片使用特定领域的知识将数据分区到多个在多个服务器上运行的数据库实例中。每个数据库实例都是隔离的，从而可以扩展工作负载。这种架构需要自定义逻辑来处理路由、重新平衡和跨分片操作。
分布式 SQL
分布式 SQL提供了一个单一的逻辑数据库，该数据库可以在多个服务器上进行水平扩展，并具有内置的复制和基于仲裁的逻辑来实现全局 ACID 事务。可以添加其他服务器并将其集成到系统中，从而可以扩展工作负载。自动路由、重新平衡和跨分片操作的处理简化了开发并加快了上市时间。
为了进行此比较，我们假设两种架构都在 Google Cloud Platform 上运行，并使用作为 Compute Engine 服务一部分托管的 VM。 Google Cloud Platform 为单个 VM/实例提供每月 99.9% 的正常运行时间服务级别目标。我们在系统可用性计算中使用此 SLO。
架构 1 — 应用层分片
应用分片系统将数据分区到多个服务器上，这些服务器然后半独立地运行。
- 数据在服务器上手动分区 — 例如，服务器 1 上的客户 A–F，服务器 2 上的 G–L 等。
- 每台服务器仅负责其数据切片。
- 应用程序必须将查询路由到正确的服务器。
- 如果服务器发生故障，即使其他服务器运行状况良好，其数据也会变得不可用。
6 节点应用层分片系统的可用性
我们知道：
- 节点可用的概率，P(节点可用) = 0.999。
- 节点彼此独立。
- 系统需要所有六个节点都可用。
在概率论中，独立事件是指其结果互不影响的事件。例如，当掷四个骰子时，每个骰子上显示的点数与其他三个骰子无关。
类似地，六节点应用分片集群中每台服务器的可用性彼此独立。这意味着每台服务器都有单独的可用或不可用概率，并且一台服务器的故障不受集群中其他服务器的故障或运行状况的影响。
实际上，可能存在共享资源或共享基础设施，将一台服务器的可用性与其他服务器的可用性联系起来。用数学术语来说，这意味着事件是相关的。但是，我们认为这些类型故障的概率很低，因此，我们在此分析中不考虑这些故障。
从数学上讲，如果两个事件 A 和 B 是独立的，那么 A 和 B 同时发生的概率是它们各自概率的乘积：
对于一个六节点数据库集群，这意味着：
因此，六节点分片架构支持 99.4% 的 SLO，这明显低于底层 VM 的 SLO。
架构 2 — 分布式 SQL
分布式 SQL 数据库自动将单个逻辑数据库的数据分片到多个服务器上。此外，为了提高弹性，它为每个分片维护副本，并且通常使用基于仲裁的算法来协调更新，从而确保读取和写入的强一致性。
- 每个数据分片都复制到多个节点上，其中一个副本被指定为 leader。
- 写入数据需要仲裁（多数）（例如，如果复制因子为 3，则为 3 个中的 2 个）。
- 读取也需要仲裁，这可以通过将请求路由到 leader 来优雅地实现，从而避免了向所有三个副本发出读取请求并等待多数响应的需要。
- 数据不与单个节点绑定。
- 系统可以容忍节点故障并且仍然可以提供请求。
复制因子为 3 的六节点分布式 SQL 集群的可用性
每个节点管理一个或多个数据分片。每个分片都在一个仲裁组中，其数据复制到其他两个节点上。为了防止可用性区域 (AZ) 中断以及单个节点故障，集群通常分布在三个可用性区域中，并且数据分配算法确保分片的副本始终放置在不同的可用性区域中。
在概率论中，二项式分布对一系列试验或测试期间的预期结果数量进行建模。
我们可以使用二项式分布来计算 n 个服务器的集群中 k 个服务器可用的概率：
我们知道：
-
P(节点可用) = 0.999。
-
节点彼此独立。
-
节点均匀地分布在三个可用性区域中。
-
许多仲裁组分布在服务器上。
-
Raft 组的组织方式是副本始终位于单独的可用性区域中。
-
如果一个节点丢失，只会影响数据的一个副本，因此集群仍然可用。
-
如果丢失两个节点，只要它们位于同一 AZ 中，只会影响数据的一个副本，因此集群仍然可用。这进一步提高了可用性，但为简单起见，我们没有包括这些计算。
-
如果丢失三个或更多节点，则会影响数据的两个或更多副本，并且集群将不可用。
因此，六节点系统在以下情况下可用：
- 所有六个节点都已启动。
- 恰好五个节点已启动。
这意味着：
六节点复制因子 (RF) 三仲裁架构支持 99.998% 的 SLO，明显高于底层 VM 的 SLO。
复制因子为 5 的 10 节点分布式 SQL 集群的可用性
为了进一步提高弹性并防止两次同时发生的故障，可以将分布式 SQL 配置为以复制因子 RF 为 5 运行。使用此架构，每个节点管理一个或多个数据分片。
每个分片都在一个仲裁组中，其数据复制到其他四个节点上。为了防止可用性区域 (AZ) 中断以及单个节点故障，集群通常分布在五个可用性区域中，并且数据分配算法确保分片的副本始终放置在不同的可用性区域中。
我们知道：
- P(节点可用) = 0.999。
- 节点彼此独立。
- 节点均匀地分布在五个可用性区域中。
- 许多仲裁组分布在服务器上。
- Raft 组的组织方式是副本始终位于单独的可用性区域中。
- 如果一个节点丢失，只会影响数据的一个副本，因此集群仍然可用。
- 如果丢失两个节点，只会影响数据的两个副本，因此集群仍然可用。
- 如果丢失三个或四个节点，只要它们位于两个或更少的 AZ 中，只会影响数据的两个副本，因此集群仍然可用。这进一步提高了可用性，但为简单起见，我们没有包括这些计算。
- 如果丢失五个或更多节点，则会影响数据的三个或更多副本，并且集群将不可用。
10 节点 RF5 仲裁架构支持 99.99999% 的服务级别目标，这明显高于 RF3 集群的 SLO。
架构对可用性的影响
传统架构受到单节点故障风险的限制。应用层分片加剧了这个问题，因为如果任何节点发生故障，其分片以及整个系统都将变得不可用。
相比之下，具有基于仲裁的共识的分布式数据库（如 YugabyteDB）提供容错和可扩展性，从而实现更高的弹性和更高的可用性。
| 架构 | 服务级别目标 | |
|---|---|---|
| 单节点 | 99.9% | （三个 9） |
| 6 节点应用层分片 | 99.4% | （两个 9） |
| 6 节点 RF3 分布式 SQL 集群 | 99.99% | （四个 9） |
| 10 节点 RF5 分布式 SQL 集群 | 99.99999% | （七个 9） |
上面的汇总表显示，使用六节点应用层分片架构发生故障的可能性远大于 10 节点 RF 5 分布式 SQL 集群。具体来说：
六节点应用分片与 10 节点 RF5 相比的故障可能性 =
弹性重要吗？
提供高吞吐量、实时事务服务的企业，例如支付处理商和反洗钱解决方案，严重依赖其基础设施的弹性。
每停机一分钟都是收入损失。它会削弱信任并可能导致客户流失。一个以每秒 10,000 笔交易、每笔 50 美元、收取 2% 费用的平台，每分钟仅费用就会损失 600,000 美元的收入。
弹性至关重要。在故障情况下激活的文档完善的流程和运行手册是不够的。关键服务的运营弹性需要弹性、自我修复的架构，例如分布式 SQL。
结论
传统架构，特别是那些使用单节点或应用层分片的架构，容易发生故障并且提供的可用性有限。具有基于仲裁的复制的分布式 SQL 数据库提供明显更高的可用性、容错能力和弹性。
这种差异不仅是技术上的，而且对业务至关重要。停机可能导致大量收入损失、声誉损害和监管风险。随着运营需求和监管期望的增加，对于任何依赖高吞吐量、实时服务的企业来说，采用弹性、自我修复的架构至关重要。
