让 768 台服务器看起来像 1

让 768 台服务器看起来像 1 Ben Dicken [@BenjDicken] | 2026 年 7 月 15 日 这是 768 台服务器。对某些人来说，这看起来像是很多台计算机。对于那些管理拥有数百万客户的应用程序基础设施的人来说，每秒执行数百万次查询是很正常的。这种规模的产品通常需要数千台服务器协同工作。最难扩展的基础设施组件几乎总是数据库。单个数据库服务器无法满足这样的需求，因此我们必须通过数据库分片将查询和数据分散到许多服务器上。数据库分片是扩展 Postgres 或 MySQL 数据库以处理超过几 TB 数据的最佳方法。让我们看看如何从小型单节点数据库发展到分布在四个分片上的几 TB 数据库，一直到分布在 768 个服务器上并存储 1 PB 数据的数据库。成长的烦恼 要理解为什么分片是扩展关系数据库的必要组成部分，我们必须了解可扩展性较差的方法的瓶颈。首先考虑一个简单的应用程序架构。您使用过的大多数应用程序都以这种方式运行，或者至少在其存在之初是这样的。在客户端设备上运行的软件通过互联网连接到应用程序服务器。该应用程序服务器位于数据中心，负责处理身份验证、页面加载以及应用程序行为的所有服务器端逻辑。所有持久数据（例如用户帐户、帖子、设置和消息）都存储在数据库服务器中并从中检索（其中“数据库服务器”通常是 Postgres 或 MySQL，尽管本文的重点是 Postgres）。即使使用大型数据库服务器（数十个 CPU 核心、数百个 GB 的 RAM），瓶颈也会很快出现。通常，它要么是由于高查询量而导致的 CPU 限制，要么是由于大量读取和写入而导致的 I/O 限制 (IOPS)。通用可扩展性定律很好地总结了这一点：简而言之，USL 指出，资源争用会导致可扩展性随着资源的增加而呈次线性增长，并且在某个点上，不连贯性会导致性能下降。对于 Postgres 来说也是如此，就像任何试图在更大的服务器上跨多个线程或进程进行横向扩展的软件系统一样。至少在短期内解决此问题的一种方法是利用只读副本。在此配置中，您将原始服务器维护为主服务器并添加其他副本，如上所示。主节点向每个副本发送连续的消息流，以确保它们及时了解主节点上的数据更改。写入（INSERT、UPDATE、DELETE）只能写入主数据库。如果允许对任何服务器进行写入，我们最终可能会出现数据冲突。解决这个问题需要复杂而缓慢的共识算法，这是可能的，但在大多数情况下对于最佳性能来说并不理想。但是，应用程序服务器可以向副本发送读取 (SELECT) 查询。由于大多数应用程序的读取百分比远高于写入百分比，因此这提供了更多的可扩展性。 （副本对于高可用性和数据持久性也是必要的，即使查询流量不需要它们）。数据库可以通过添加副本来扩展以处理更多流量。一个极端的例子是 OpenAI 在单个主节点上使用 50 个副本。事实证明，垂直扩展服务器（增加 CPU / RAM）和添加副本只能让您到目前为止。有几个瓶颈无法通过这种方式解决： 1) 写入仅限于一台服务器 如果写入量足够大，再多的只读副本也无法缓解问题。在 Postgres 确认已提交的写入之前，它必须在其预写日志 (WAL) 中记录更改并将该日志刷新到持久存储。 WAL 是主节点上所有连接之间的共享资源。这本质上是整个数据库的单一写入瓶颈，即使您有数十个副本。 2) 副本不会增加数据容量 副本是主数据的完整副本，包括所有索引。添加副本为我们提供了更多运行读取的位置，但它不会分发数据。 3) 备份 备份是数据持久性和RPO/RTO保证的重要组成部分。由于节点到存储通信的带宽限制，将大型整体数据库备份到对象存储可能需要数小时甚至数天的时间。对于许多依赖频繁且经过验证的备份的组织来说，这个时间长得令人无法接受。处理这个问题最有效的方法是分片。分片（带有“d”） 分片通过将数据和查询分布在许多不同的主节点上来解决这三个瓶颈。对于数据来说，它很有用，因为单个节点只能存储这么多数据，并且写入吞吐量有限。对于查询来说，这非常有用，因为网络互连和 CPU 一次只能处理这么多查询。分片对于超过几 TB 数据的所有规模都很有用。例如，具有 2 TB 的 d