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 级别的流量时 —— 分片。不要过早地使架构复杂化。
主题常见问题
流量形态与数据往往与生产不一致。需要场景、与线上一致的指标，以及可回滚的逐步加压。
常见瓶颈在数据库与执行计划、连接池、同步外部调用与队列——可作为快速排查清单。
不一定：失效、冷启动与热点键可能适得其反。缓存要按读模型与 SLO 设计。
垂直扩展与查询优化触顶，且数据增长在分片键上可预期时。