3.1 共享什么决定架构边界
3.1 共享什么，决定架构边界
分布式架构的第一个分水岭是"多台节点共享什么"：共享磁盘、共享内存、还是什么都不共享只靠网络。本节先把这三种组合的坐标系立起来，说清每一种共享的资源在哪儿、瓶颈在哪儿，为后面三节的展开定好框架。
先别急着画拓扑线，先问一句"共享了谁"
讲架构习惯从"节点怎么连"讲起，那是网络工程师的画法。分布式数据库的架构分歧，其实首先回答另一个问题：这几台机器里，CPU、内存、磁盘，到底哪样是被大家公用的？答案不同，整套系统的走向就完全不同。先把这个问题钉死，拓扑图不过是它的必然结果。这一节就从"共享谁"这个原点出发，把三派立场一次性理清。
学习目标
阅读完本节，你应当能够：
- 用"节点+共享资源+通信方式"三元组描述一类架构。
- 指出共享磁盘、共享内存各自的天然瓶颈都在哪个共享点上。
- 初步判断"共享越少扩张越自由"这条架构主线为什么成立。
先暂停一下：架构不是"怎么连"，是"共享啥"
很多人一讲架构就想到网络拓扑：节点 A 怎么连节点 B、要拉几根线。但分布式数据库架构的真问题根本不是"线怎么接"，而是"几个节点之间，哪些资源被公用、哪些各自保藏"。同样是连成一圈的机器，你让他们共用一块磁盘，和让他们各自用各自的硬盘再靠消息对表，性质完全不同——前者是在共享，后者是在协作。理解架构，先从"共享哪个资源"下手。
一、三组分法：谁被公有化
把 CPU、内存、磁盘这三样资源拿出来，看集群如何处置，就得到了三大类：
Shared-Disk（共享磁盘）：多台节点各有自己的 CPU 和内存，但共用同一块(或同一套)存储。好处是"底层存储只有一份"，数据天然一致，管理简单；坏处也暴露得干脆——这块共享磁盘既是所有节点争抢的对象，又成了唯一的性能瓶颈和潜在单点。磁盘一慢，全部节点陪着慢；磁盘一坏，整个集群瘫痪。
Shared-Memory（共享内存）：多台节点共用同一块内存。内存比磁盘快好几个数量级，理论上协调极高效，但它几乎只在机器内部（多核）成立——把内存跨机器共享，成本高得离谱，扩展性也因此被死死限制在单机规模。它是这三类里最"快但最不大"的。
Shared-Nothing（不共享任何东西）：每个节点都有自己独享的 CPU、内存、磁盘，节点之间只通过网络交换消息协作。没有共享资源 = 没有共享瓶颈，理论上可以一直往下加节点换水平扩展；代价是所有共享带来的便利都得靠网络通信和小本本地化来重新实现，比如"你想看别人机器上的数据，就得先把消息发给它"。
三种共享类型的"资源边界"一图看穿
下面这张 SVG 把 CPU/内存/磁盘放在每个节点身上，用"共享连线的颜色"标出哪种资源被公有：
三大架构：哪块资源被公有化
二、为什么"共享越少，越自由"
把三种放一起比较，能看出一个规律：共享点越少，可扩展的上限越高。Shared-Disk 的扩张很快被"那块盘的带宽"卡死，Shared-Memory 的被"内存条只能在单机内"限制住，唯独 Shared-Nothing，理论上你每多一台节点就多一分独立的计算、存储、内存，瓶颈被压到只剩网络。这也是为什么绝大多数现代分布式数据库（TiDB、Cassandra、OceanBase）选择 Shared-Nothing 作为底座——这不是审美选择，而是对"我想要可持续水平扩展"的最朴素回应。
这里要泼一句冷水：Shared-Nothing 的"自由"是有入场券的，那张券就是"你得靠网络把数据搬来搬去、靠元数据知道数据在哪儿、靠共识保证副本一致"。这三件麻烦事，本书第 4、6 章会逐个讲。所以架构主线不是"哪种最好"，而是"接受哪套代价，换来哪项自由"。
三、一张对比表压维度
| 架构 | 谁被公有化 | 主要瓶颈 | 可扩展性 | 典型处境 |
|---|---|---|---|---|
| Shared-Disk | 磁盘 | 共享盘带宽、单点 | 有限 | 传统集群、共享存储方案 |
| Shared-Memory | 内存 | 仅限单机/少量机 | 极有限 | 多媒体数据库、单机多核 |
| Shared-Nothing | 无 | 网络 | 高 | 现代分布式库主流 |
四、一台能让你当场选型的中型机
理解了三个坐标系，落到一台实际要铺的集群上，选择就非常具体。假设你要为一套 8 节点、每节点 64G 内存的系统选架构：
选 Shared-Disk：你确实省了"副本同步"的麻烦，因为数据天然一处。可 8 个节点全去抢同一块盘的带宽，盘 I/O 就成了天花板；更糟的是盘要做故障容错时，还得整卷复制、甚至要引入跨节点的锁协调，省下来的同步功夫又都还回去。
选 Shared-Memory：数据全在内存，快是真快，但 8 台机器共享内存基本不现实——要么退化成一台超大内存的单机，要么引入昂贵又复杂的缓存一致性协议，扩展第一步就死在机内，根本走不到"加机器"那步。
选 Shared-Nothing：8 台各自为政 + 网络协作，看似要自己管副本、路由、共识，很麻烦；可换来的是每一台都能独立加资源、独立换盘，加一台机器就多一份容量与算力——这恰恰是"我要可持续扩容"最想要的结果。
| 架构 | 上手成本 | 是否好扩容 | 长期可持续 | 典型翻车点 |
|---|---|---|---|---|
| Shared-Disk | 低 | 否，卡在盘带宽 | 否 | 共享盘与跨节点锁协调 |
| Shared-Memory | 快未战先输 | 否，死在机内 | 否 | 扩展需共享内存做协调 |
| Shared-Nothing | 较高 | 是 | 是 | 靠协作换自由，先学调度 |
现在你明白为什么现代分布式库清一色选 Shared-Nothing 了吧：它把"瓶颈"从"谁也抢不动的共享资源"换成了"可以靠调度和学习解决的网络"。共享盘和共享内存的天花板是物理的、长不上去，网络虽然要协调，却是能一直加机器摊下去的——这是架构选择里最朴素的一条生意经。
本节要点回顾
- 架构的分水岭是"共享哪个资源"，不是"怎么连线"。
- 三类：共享磁盘、共享内存、什么都不共享。
- 趋势：共享点越少，扩展上限越高，瓶颈越向网络转移。
- 代价换自由：Shared-Nothing 的自由，要靠分布、路由、共识三件功课来买单。
三种形态里，Shared-Nothing 被现代系统几乎一致地选中——它到底怎么做到"既各自为政、又像一台整机"？下一节 3.2 走进它的内部，看看数据本地与网络协作是怎么共处的。