扩展模式
让系统增长的架构形状——垂直、水平、分片、分区——及各自适用时。
为什么
扩展非一事——垂直（更大盒）、水平（更多盒）、分片（按键拆）、读副本（读写拆）各解不同瓶颈且各不同成本。选错模式浪费钱且常不修瓶颈（如写吞吐受限时加读副本）。知模式及权衡让你选最便宜且真解极限的，并排序使不在耗尽水平（最便宜）前分片（最贵）。
何时使用
当组件触极限。半天选+实现。每 10 倍增长重访。
如何做
1. 识别瓶颈：CPU、内存、连接、DB 写、DB 读、存储？ 2. 模式配瓶颈： - CPU/内存受限、无状态 → 水平（加实例） - CPU/内存受限、有状态 → 垂直（更大实例）后分片 - DB 读受限 → 读副本 - DB 写受限 → 按键分片，或移到写优化存储 - 存储受限 → 按时间分区（冷存）或按租户分片 3. 先用最便宜且修瓶颈的模式 4. 前后测；瓶颈没动说明选错 5. 规划下个极限——此修后 10 倍时什么破？
示例
瓶颈：DB 写吞吐 8k 写/秒（此实例 Postgres 极限） 按成本序选项： 1. 垂直：r5.2xlarge → r5.4xlarge → ~12k 写/秒，+$400/月 ← 最便宜 2. 连接池（pgbouncer）：释放写槽 → ~10k，+$20/月 3. 按 user_id 分片：2 片 → ~16k 写/秒，+$500/月 + 迁移 4. 写移 Cassandra：~50k 写/秒，+$2k/月 + 重写 选：pgbouncer（2）+ 垂直（1）→ 15k 写/秒，+$420/月。 分片推迟到需 30k 写/秒（给 2 年）。
常见问题
- ⚠在耗尽垂直+水平前分片——分片是最贵扩展（跨片查询、再均衡）且常过早。
最佳实践
- ✓扩展前后必测瓶颈——"加了实例感觉快了"不是验证。
- ✓选均匀分布写且聚相关数据的分片键——坏分片键造热片和跨片 join。