第3章 分布式数据库架构
第3章 分布式数据库架构
本章跟着一条线走：把第 2 章定好的一致性语言落地到物理世界里——节点之间到底共享什么东西，决定了整个集群的天性与上限。这条线从"共享磁盘"走到"共享内存"再走到"什么都不共享只靠网络"（Shared-Nothing），并一路看清集群里谁是协调者、谁是存储、谁是副本。
本章路线图
一条主线
一致性是语义，架构是它的承重墙。想象给一支乐队排座位：有的人共用一份乐谱（共享数据）、有的人各看各的谱靠指挥对齐（不共享数据靠网络协作）。这一章主线是一条物理设计的取舍线：共享的资源越多，单体协调越容易，但瓶颈越集中；共享的资源越少，扩展越自由，但节点间协作要做的功课越多。 我们沿这条线从"共享根最深"一直走到"几乎不共享"，最后落在当今主流产品几乎统统选择的 Shared-Nothing 上。
沿途站点
- 3.1 共享什么决定架构边界：先把"共享 CPU/内存/磁盘"这三种组合摆开，确立理解后面三节的坐标系。主线推进到：架构的分野就在"共享哪个资源"。
- 3.2 Shared-Nothing 数据各自为政：每个节点独享 CPU/内存/磁盘，只通过网络协作——主线落脚的方案，也是 TiDB、Cassandra 的共同底座。主线推进到：主流为何选它。
- 3.3 共享资源的两极：Shared-Disk 共享磁盘、Shared-Memory 共享内存，讲清楚它们各自的极简与极限。主线推进到：两条被性能门槛堵住的方向。
- 3.4 集群里的角色分工：从"节点"抽象出协调者、存储节点、副本、路由等角色，把整座调度室的骨架立起来。主线推进到：为第 4 章的路由与第 6 章的共识铺好场地。
拐点与结论
本章最关键的认知转折是："共享"越少，恰恰是为了让"扩展"越多。Shared-Disk 和 Shared-Memory 看起来资源利用率高、协调轻松，但它们的"共享点"恰恰成了不可伸缩的瓶颈与单点；Shared-Nothing 把资源共享切到最小，逼着靠网络协作，反而换来水平扩展的自由——代价是必须解决分布、路由、一致性这些本书后几章逐个攻克的难题。所以"主流都选 Shared-Nothing"不是偶然，是取舍后的必然。
读完你应该
- 画出"共享那项资源"从磁盘、内存到完全独立的三类架构形态。
- 说明 Shared-Nothing 的水平扩展优势来自哪里、代价落在哪里。
- 解释 Shared-Disk 为何存储成为天然瓶颈，Shared-Memory 为何难以规模化。
- 在一张架构图里标出协调者、存储节点、副本、路由代理的角色与职责。
三句口诀：一眼看懂任何架构
落地到真实产品时，用三句白话就能把主流架构归类。Shared-Memory 是"一台胖机器"：所有节点共用同一套内存，像一人意见大的人在一间屋里拍板，最协调但也最难扩到很大；Shared-Disk 是"一群大脑共用一张纸"：各节点各跑各的，但数据统一落在共享磁盘上，写一把锁就把扩展锁死了，恰恰是存储成为瓶颈的那一类（如 Oracle RAC 的痛点）；Shared-Nothing 是"一群独立小分队只靠对讲机"：谁的数据谁揣着，需要时发消息协作，正是 TiDB、Cassandra 底层都在用的底座。这三句口诀能帮你从"这张架构图讲什么"直接跳到"它的瓶颈会在哪"。
下一章的接力
架构把节点组织起来了，但"数据到底住在哪个节点、来一个请求该敲哪扇门"还不知道答案——这正是第 4 章数据分布与路由要解决的：分片把数据按下棋格摊开，元数据和路由代理变成那张"该敲哪扇门"的电话簿。第 3 章的节点骨架，到第 4 章才算真正各就各位。