768台服务器协同如一，算力集群新突破

背景

在面向数百万用户、每秒执行数百万次查询的应用中，数千台服务器协同工作已是常态。然而，扩展基础架构中最棘手的组件几乎永远是数据库。单个数据库服务器无法支撑如此巨大的需求，因此必须通过数据库分片（Database Sharding）将查询和数据分散到多台服务器上。分片是扩展 Postgres 或 MySQL 数据库以应对数 TB 以上数据的最佳方式。本文讲述如何从一个小型单节点数据库，扩展到跨 4 个分片、数 TB 数据，再到最终跨 768 台服务器、存储 PB 级数据的全分片架构。

核心内容

从小规模到大规模：成长的烦恼

大多数应用初期都采用简单的架构：客户端软件通过互联网连接到应用服务器，应用服务器处理认证、页面加载和所有服务端逻辑，持久化数据（如用户账户、帖子、设置、消息）则存储在数据库服务器（通常是 Postgres 或 MySQL）中。

即使使用大型数据库服务器（数十 CPU 核心、数百 GB 内存），瓶颈也会很快显现。通常，瓶颈来自高查询量导致的 CPU 限制，或高读写量带来的 I/O 限制（IOPS）。这可以用通用可扩展性定律（Universal Scalability Law）来总结：资源争用导致扩展性随资源增加而呈次线性增长，到达某一点后，不一致性会导致性能下降——这对 Postgres 同样成立。

短期解法：只读副本

一种短期缓解方案是利用只读副本（Read Replicas）。配置中维护一个主库（Primary），并添加多个副本。主库持续向每个副本发送消息流，以确保它们与主库的数据更改保持同步。写入操作（INSERT、UPDATE、DELETE）只能发往主库，以避免数据冲突；应用服务器可以将读取查询（SELECT）发送到副本。由于大多数应用的读取比例远高于写入，这提供了更大的可扩展性。极端例子是 OpenAI 为单个主库使用了 50 个副本。

但垂直扩展（增加 CPU/内存）和添加副本只能解决部分问题，仍有多个瓶颈无法通过这种方式解决：

1. 写入限于单台服务器：高写入量下，再多的只读副本也无济于事。Postgres 在确认提交写入前，必须将更改记录到预写日志（WAL）并将日志刷入持久化存储。WAL 是主库上所有连接的共享资源，这本质上成为整个数据库的单一写入瓶颈。
2. 副本不增加数据容量：副本是主库数据的完整副本（包括所有索引）。添加副本提供了更多读取位置，但并未分散数据。
3. 备份问题：备份大型单体数据库到对象存储，可能因节点到存储的带宽限制而耗时数小时甚至数天，这对许多需要频繁且可验证备份的组织来说不可接受。

核心解法：分片（Sharding）

分片通过将数据和查询分散到多个独立的主库上，解决了上述三个瓶颈。单个节点只能存储有限数据且写入吞吐受限；网络互连和 CPU 也只能同时处理有限查询。分片在数据超过数 TB 后即可发挥作用。例如，对于 2 TB 数据，可以设置 4 个分片，每个存储 500 GB 并处理 1/4 的查询流量。当需要存储 PB 级数据（1,000,000 GB）时，就需要更多分片。文中案例使用 256 个分片，每个分片包含 1 个主库 + 2 个副本，每个分片负责存储约 4 TB。这需要 256 × 3 = 768 台服务器。

然而，没有良好的系统支持，分片会给应用后端带来巨大复杂性。系统需要解决：

• 决定哪些数据去往哪个服务器？
• 决定哪些查询去往哪个服务器？
• 处理需要同时与多个分片交互的查询？
• 对分散的数据库进行备份？
• 监控系统级健康状态？
• 响应故障服务器？

本文重点回答的是：如何让这 768 台服务器对应用而言看起来像一个统一的数据库？ 目标是让应用服务器从一个复杂的系统交互（如图中多个数据库节点）简化为通过单个连接字符串交互，仿佛只连接了一个大型可扩展数据库，而实际上利用了数十或数百个分片。Neki for Postgres 和 Vitess for MySQL 正是解决这一问题的工具。

代理层：路由与统一入口

代理层是其中最关键的部分。代理是位于两个服务之间的中间件服务器，这里位于应用服务器和数据库服务器之间。即使不进行分片，代理也常用于连接池和请求排队。对于常规（未分片）Postgres，PgBouncer 是一个流行的代理，它将数千个应用连接多路复用到更少的直接 Postgres 连接上，并在流量激增或数据库故障转移期间缓冲请求。

分片 Postgres 需要更复杂的代理。最大的区别在于：除了多路复用和缓冲，代理还必须理解数据在服务器间的分布情况，并将 SQL 查询路由到正确的分片。因此，这种代理被称为路由器（Router）。

当插入数据时，路由器必须知道数据如何分布，这称为分片策略（Sharding Strategy）。一种常见做法是基于 ID 列的哈希值对传入行进行分片。例如插入用户记录时，路由器根据 id 哈希决定数据进入哪个分片：

INSERT INTO users (id, username, email) VALUES
(1, 'ada', '[email protected]'),
(2, 'grace', '[email protected]'),
...

路由器自动将不同的行分发到对应的分片，应用端无需关心底层细节。

关键要点

• 分片的必要性：当数据库数据量超过数 TB 且写入吞吐成为瓶颈时，只读副本和垂直扩展无法解决写入单点瓶颈、数据容量限制和漫长备份等问题，分片是经过验证的有效方案。
• 分片的核心是路由器：代理层不仅负责连接复用，还必须理解数据分布（分片策略），并智能地将 SQL 查询路由到目标分片，使应用感知不到底层分片的存在。
• 数据分布策略：常见分片策略基于哈希（如对 ID 列取模），保证数据均匀分布；路由器负责在插入时决定数据归属，在查询时根据条件定位分片。
• 跨分片查询的复杂性：部分查询可能需要访问多个分片（如 JOIN 或聚合），路由器需具备合并结果的能力，但本文未深入展开，强调统一入口带来的简化。
• 768 台服务器的具体构成：文中案例采用 256 个分片，每个分片 1 主 2 副本，共 768 台服务器。通过 Neki（Postgres）或 Vitess（MySQL）这样的分片中间件，这些服务器对外表现为一个逻辑数据库。

意义与影响

分片技术是大型互联网应用走向极大规模数据存储的基石。它解决了关系型数据库在扩展性上的根本矛盾：既要保持 ACID 事务特性，又要突破单机物理限制。通过将数据分散到数百台服务器上，分片使得 PB 级数据量下的读写吞吐成为可能，同时通过多主库架构避免了单点写入瓶颈。Neki 和 Vitess 这类工具的出现，将分片带来的复杂性封装在代理层中，让应用开发者无需感知底层数百台服务器的存在，从而降低了大规模数据库运维的门槛。这深刻影响了现代云计算和数据密集型应用的设计模式——从“单体数据库”转向“逻辑统一、物理分散”的分片架构，为支撑千万级以上用户、毫秒级响应延迟的系统提供了可靠路径。