第1章 从集中式到分布式
第1章 从集中式到分布式
本章跟着一条线走：一台数据库一开始好好的，随着数据变多、请求变多、要保证不关机，它一步步被"拆开"，直到拆成分散在多个节点、却仍像一台整机的形态。理解这条线从哪儿开始崩，是后面所有章节的地基。
本章路线图
一条主线
想象你运营一个电商后台，最开始一台 MySQL 就管得过来：订单、用户、库存都挤在一张盘上，一个事务保住 ACID，查询秒回。可业务冲量后，三件事先后冒出来——磁盘装不下（存储上限）、单请求排队（吞吐瓶颈）、一次双十一大促死机导致全站瘫掉（可用性阈值）。这一章的主线，就是看这三根柱子怎么一根根被推倒，而"拆库"是被推倒后的必然选择。我们把这三根柱子分别记作：容量柱、性能柱、可用性柱。
沿途站点
- 1.1 临界线从哪儿来：区分"单机还能忍"和"单机已经没救"的分界，讲清楚三根柱子为什么撑不住。主线推进到：承认集中式有物理与逻辑的极限。
- 1.2 分布式换来什么与付出什么：拆完后得到可扩展、高可用、数据本地性，但也要为此付出网络、一致性与运维三笔账。主线推进到：算一笔"拆的收益减去拆的代价"。
- 1.3 按什么给分布式数据库分家：用数据模型、一致性、扩展方式三个维度给五花八门的系统分类，并给出"什么时候值得跨过那条线"的判断法。主线推进到：认出了你要选的方向。
拐点与结论
本章最重要的认知转折是：分布式不是"把单机搬到局域网里"，而是"接受单机做不到、从而主动设计网络的参与"。单机时代网络是透明的、是可以假装不存在的；一旦拆开，网络故障就变成了常态而不是异常。这个拐点决定了后面每一章都在与"网络不可靠、并发天然存在、故障必然发生"这三个前提共处。
读完你应该
- 说出集中式数据库被质疑的三根柱子，并各给一个触发它的业务场景。
- 解释为什么"扩容解了容量问题"不等于"解决了全部问题"，还会引发新问题。
- 权衡可扩展、高可用、数据本地性的收益，与网络、一致性、运维的成本。
- 用数据模型、一致性取向、扩展粒度三个维度给 TiDB、MongoDB、HBase 分类。
- 判断一个系统是否真的需要跨过分布式那条线，而不被"分布式=先进"带偏。
尽早建立：拆库前先做一次盈亏测算
真正动手拆库前，先对着三幅场景做一次"盈亏测算"。沿用 1.1 的三根柱子逐个看：容量超限时，你的第一反应是加盘还是分片？性能卡住时，是加索引并发读还是直接加机器横向摊？可用性若允许几分钟宕机，那单机配一个从库也许就够了，根本不必走向彻底分布式。这三问的关键不是"分布式好不好"，而是"我这笔业务值不值得付出那三笔账"。等走完第 6 章再回头看，会觉得这页估算很糙——但它能挡住"为了先进而先进"的冲动，也替后面每章的方案选择提前定了取舍基调。习惯性拿这张卡片去套任何新技术，是你从"会读教程"走向"能选型"的第一大步。
一个最朴素的三栏得失表
怕你只记住红口白牙的说法，我把它压成一张三栏得失表，方案评审时直接照着过一遍就知道该不该拆：
| 这根柱 | 换来的 | 要付的 | 是否结构性 |
|---|---|---|---|
| 容量柱 | 水平扩容到够 | 分片、迁移、目录 | 可优化为主 |
| 性能柱 | 并发被多台摊平 | 跨节点网络往返 | 结构性不可避免 |
| 可用性柱 | 多副本随时顶替 | 一致性要做妥协 | 结构性不可避免 |
看见没有，三根柱子各付各的账：后两样的"付出"是结构性不可避免的，躲不掉只能设计规避；唯独容量那根还能靠分片策略与迁移工具优化。评审时别只盯收益，把它们按"可优化/不可避免"分完类，取舍基调就清楚了。
下一章的接力
分布式拆开了数据，就立刻撞上一个躲不开的问题：一致性拿什么来保证？第 2 章用 CAP 定理和一致性模型，给第 1 章埋下的"多节点如何对外体现单机语义"铺开第一块理论地基。你在第 1 章接受的"网络不可靠"前提，正是第 2 章一切取舍的起点——而第 1 章你算的那笔"值不值得拆"的账，也会在读完第 2 章后变得更有底气。