1.1 临界线从哪儿来
1.1 集中式数据库什么时候就撑不住了
同意做分布式之前，先要知道单机到底败在哪。本节把"集中式数据库到底哪些指标先到顶"这件事拆开：存储装不下、单个请求排队、一次断电全站停摆，三个临界点分别来自硬件容量、串行执行模型、单点依赖。理解了这三根柱子，你就知道后面所有"分布式换来什么"都不是凭空掉下来的。
学习目标
阅读完本节，你应当能够：
- 说出集中式数据库最先到顶的三个方向，并给每个方向配一个触发场景。
- 解释"扩容"为何能解存储却解不了单请求队列。
- 区分物理极限与逻辑极限，说明哪些问题靠换机器、哪些问题必须靠改架构。
一、一台数据库的体面生活
先把感受校准一下。你租一台 16 核 128G 内存的机器，装个 MySQL，批量导三亿行订单，配好索引，日常读写都在几十毫秒以内。这个阶段很美好，因为数据库的每一次操作本质都在"同一台机器里打转"——内存里找数据、磁盘上读回、锁表后改，这些动作之间只隔着纳秒级的总线延迟。这不是巧合，而是设计前提：传统数据库的整套工艺，从锁、到日志、到崩溃恢复，都默认"就一台机器，大家抢同一份内存和磁盘"。
问题出在量上。你会发现乐观的窗口期在三种压力下一项项被刺穿。
二、第一根柱子：磁盘装不下
这是最直白的一条线。硬盘就这么大，能删的日志删了、能归档的归档了，但当业务数据本身就过了一个数量级，你再怎么优化都没有用——物理容量到了头。这里要特别提醒一句，很多人以为"换成更大的盘就行"，这是误区。当你需要买的机器已经贵到"一台都快顶样机房一半了"，或者单盘容量跟不上写入速率时，买大机器就不是解法，而是慢性自杀，因为单机性能和容量存在平台上限，不是你想多就能多。
三、第二根柱子：单个请求排长队
存储还能靠买盘续一命，请求并发却不是加钱就能解。数据库在单机上的执行模型，本质是"多个请求抢同一组锁、同一段内存页、同一块磁盘带宽"。你可以在物理上把 CPU 从 16 核加到 64 核，可一旦某个热点行大家都在改，锁冲突会把你加核的收益全部吃回去。更隐蔽的是跨请求的相互拖累：一个慢查询把缓冲区占满，接下来所有快查询都被挤在后面排队。这个阶段的典型指标是"QPS 到了一个平台后，加核几乎无效"，因为你加的不是并行能力，而是把更多线程塞进同一条竞争链路。
四、第三根柱子：一次断电全站停摆
最狠的一条线来自"单点"。一台机器的可用性，无论单机内部做得多好，故障概率终究是单节点求和：掉电、磁盘坏道、操作系统崩溃、机房断网，任何一件落到这台机器上，整个系统就一起闭眼。做可用性的人喜欢算这个数：单台机器一年故障时间假设能到大学几百分钟，换算成年可用性也就是个三点九几个九，而金融、社交、购物对核心库的要求是四个九、五个九。这个差距靠把单台机器造得再稳定都补不平，因为它是个乘法逻辑——你需要的是冗余，是"这台倒了那台顶上"。而冗余恰恰是单机架构给不了的东西。
演进的时间线，其实暗示了答案
五、物理极限与逻辑极限
把三根柱子再分一下类。磁盘装不下，是物理极限——可以通过监控指标提前预测，因为容量曲线是连续可数的；请求排队，往深了挖是逻辑/架构极限——它不来自某个具体硬件坏掉，而来自"多请求共享单机资源"这个执行模型本身，你加机器解决不了，因为模型没变；断电全停，是可用性极限——来自单点依赖，属于数学上无法回避的结构问题。
明白这层区别很重要：物理极限能用"换更大单机"延缓，逻辑极限和可用性极限则必须靠"换执行模型"来根治。而这个新执行模型，就是让很多台机器各自用一亩三分地、再通过网络协作的分布式数据库。
为了把三种极限看得更清楚，我给你一张对比表：
| 临界类型 | 触发场景 | 能不能靠加大单机解决 | 根治方向 |
|---|---|---|---|
| 物理容量极限 | 存量数据超过单盘上限 | 短期能，成本高 | 数据分布到多机 |
| 逻辑并发极限 | 热点行锁竞争、慢查询拖垮快查询 | 几乎无效 | 并行与分片执行 |
| 可用性极限 | 断电、宕机、机房故障 | 无效 | 冗余副本与故障转移 |
六、一个把三根柱子压垮的真实例子
2010 年代一家大型内容平台的评论模块就是标准案例。它一开始用单机 MySQL 存评论，七八个九的量级还能跑。当用户量和互动量翻了两番之后，先是磁盘持续告警（容量柱），接着峰值时评论区变成"正在加载"长达十几秒（性能柱），随后一次机房断电，整个平台的评论与举报功能一起失效（可用性柱）。运营复盘时发现，任何单机都救不回这个业务——它需要的不是一个更大的盒子，而是把评论数据拆到多台机器、每台机器各有副本、坏一台换一台还能继续服务的整套机制。这个案例里，三根柱子其实是同一个决策的三种压力模型。
七、一张可复用的自查清单
知道自己到了没到临界线，靠的是在崩溃之前看懂几个数字，而不是等报警吵醒你。你可以给单机库配这么一张三级自查卡：
- 容量级：数据文件大小 ÷ 磁盘容量走势。连续两周逼近 85%，就该把"数据分布到多机"提上日程，而不是继续祈祷双十一别爆。
- 并发级：热点行的行锁等待均值，以及 P99 查询延迟。如果 P99 在峰值时是 P50 的三倍以上，且加核后几乎不动，你多半撞上了锁竞争这条逻辑极限。
- 可用性级：过去一年发生过几次非计划中断、单台机器承担的核心读写比例是不是 100%。只要核心读写还完全挂在一台机器上，你的可用性上限就被这台机器钉死了。
把这张卡往运维群里一贴，你会立刻发现：前三项里至少有一项已经红了很久，只是之前没人把它翻译成"该上分布式了"。它不能替你写架构，但能把"何时动手"这个最容易被拖着的问题，变成一个可量化的时间点。
本节要点回顾
- 三根柱子：容量装不下、单请求排队、一次停摆全站死，分别对应物理/逻辑/可用性三类极限。
- 扩容≠根治：加核加盘能拖住物理极限，却治不了锁竞争与单点依赖。
- 模型比硬件重要：单机执行模型默认"共享同一资源"，分布式换的就是这个模型。
- 可用性是乘法逻辑：要四个九，必须靠冗余副本，而不是把单台造得更可靠。
承认单机有极限之后，下一个问题很自然：拆开数据，我到底能换来什么，又要付什么代价？下一节 1.2，我们把这笔账摊开算。