2025年12月20日Evgeny · 技术总监
复制还是分片：数据库何时该扩展
你的初创公司起飞了。但快乐变成了恐慌：数据库正在“窒息”。CPU 满了，查询挂起 5 秒钟。仅仅“增加 RAM”已经没有帮助了。是时候选择架构药丸了：复制还是分片？
要点。 读瓶颈用复制，写或磁盘用分片。先做负载剖析和索引：「为了以后」就分片，几乎总比从库加缓存更贵。
架构师的困境
选择策略取决于你的“瓶颈”究竟在哪里：是在读取 (Read) 还是写入 (Write)。
图 1. 左：主从复制。右：水平分片。
1. 复制 (Replication)：扩展读取
本质： 你有一个“老板” (Master) 接受所有更改，还有许多“下属” (Slaves) 只提供数据。
- 何时使用： 80-90% 的负载是读取 (Read-heavy)。典型用于媒体、博客、电子商务目录。
- 优点： 易于配置 (PostgreSQL Streaming Replication, MySQL Binlog)。数据重复 (备份)。
- 缺点： 复制延迟 (Replication Lag)。你将数据写入 Master，但它在 100 毫秒后出现在 Slave 上。用户可能无法立即看到他们的评论。
2. 分片 (Sharding)：扩展写入
本质： Master 无法应付写入。我们将数据库切成块。用户 A-M 去服务器 1，N-Z 去服务器 2。
- 何时使用： 数据太大，一张磁盘装不下。或者当一个 Master 无法跟上写入速度 (Write-heavy)。
- 优点： 理论上无限扩展。
- 缺点： 这很痛苦。你失去了分片之间的 ACID 事务。你失去了 JOIN (如何连接来自服务器 1 和服务器 2 的表？)。备份成为噩梦。
NineLab 裁决
黄金法则： 将分片推迟到最后一刻。这是一个“核按钮”。
首先 —— 索引。然后 —— 缓存 (Redis)。然后 —— 复制。只有当你拥有 Telegram 或 Uber 级别的流量时 —— 分片。不要过早地使架构复杂化。
下一步
复制还是分片 — 常见问题
瓶颈在读（目录、媒体、橱窗）——先上从库。写入或单主磁盘装不下——再分片。CPU 已经打满时，「再加一点内存」两种都救不了。
80–90% 是 SELECT、主库写得动的时候。PostgreSQL 流复制或 MySQL binlog 就能扩读。代价是 replication lag：用户可能不能立刻在从库看到刚写入的数据。
跨分片没有 JOIN 和完整 ACID，备份和迁移变难。只有数据或写入真的塞不进单节点时才按键切开——不要第一天就「为了以后」分片。
先看读写比、慢查询、索引和缓存。常常从库加 Redis 就够。读从库用尽之后，才轮到分片。
