系统实践：案例与传统方案
0. 引言
前文各章分别讲了分片、复制、一致性、共识与事务——本章看它们如何组合成真实产品。先分析三个典型系统的架构与取舍，再回顾传统数据库的分布式探索（共享存储、读写分离、分库分表、中间件），最后落到 NewSQL 与 HTAP 的融合趋势。
1. 典型案例分析
1.1 TiDB：计算存储分离的 HTAP
TiDB 是兼容 MySQL 协议的分布式关系型数据库：
- 计算层（TiDB）：无状态 SQL 节点，解析并下推计算；
- 存储层（TiKV）：基于 Raft 的分布式 KV 存储，数据按 Range 分片（Region），每个 Region 多副本由 Raft 保证一致；
- 调度层（PD）：管理元数据与 Region 调度。
特点：计算、存储独立水平扩展；OLTP 表现强，并通过 TiFlash 列存支持 HTAP。
1.2 PolarDB-X：分库分表 + Paxos
阿里云的分布式数据库，兼容 MySQL，面向高并发 OLTP：
- 计算节点（CN）：无状态 SQL；
- 存储节点（DN）：基于 Paxos / Raft 的多副本，数据按分库分表；
- 元数据（GMS）：全局元数据与时间戳。
特点：强一致、高可用，适合金融级事务场景。
1.3 Cassandra：无主架构的最终一致
Apache Cassandra 是去中心化的列式 NoSQL，源自 Dynamo + Bigtable 思想：
- 无主架构：客户端可向任意节点读写，写入按一致性级别（ONE / QUORUM / ALL）要求若干副本确认；
- LSM 存储：高写入吞吐（详见《存储引擎与查询》）；
- 最终一致：基于 Gossip 与反熵收敛。
特点：极致可用与线性扩展，牺牲强一致，适合写多、可容忍最终一致的场景。
1.4 对比与性能取舍
| 产品 | 模型 | 一致性 | 扩展 | 事务 |
|---|---|---|---|---|
| TiDB | 关系型 / HTAP | 强（Raft） | 计算存储分离 | 分布式事务 |
| PolarDB-X | 关系型 | 强（Paxos） | 分库分表 | 强事务 |
| Cassandra | 列族 NoSQL | 可配置最终 | 无主线性 | 单行 / 轻事务 |
- 强一致（Raft/Paxos）需多数派往返，延迟高于最终一致；
- 无主架构消除 Leader 瓶颈，但跨行事务弱；
- 计算存储分离提升弹性，但引入网络开销。
这些取舍正是前文分片、复制、共识、事务各章原理的综合体现。
2. 传统方案与局限
在原生分布式数据库成熟前，业界用四种方式"扩展"单机数据库：
| 手段 | 机制 | 扩展性 | 一致性 | 事务 | 主要局限 |
|---|---|---|---|---|---|
| 共享存储（Oracle RAC） | 多计算节点共享 SAN/集群文件系统 | 低（垂直） | 强 | 强 | 共享存储是瓶颈与单点，受存储吞吐约束 |
| 读写分离 | 主库写、只读副本读 | 中（读） | 最终 | 写强 | 副本复制延迟，强一致读需走主库，写仍集中 |
| 分库分表（ShardingSphere 类） | 应用/中间件层水平拆分到多库 | 高 | 需应用保证 | 弱/复杂 | 跨库事务、JOIN、全局索引需自行处理，扩容迁移复杂 |
| 分布式缓存前置 | Redis/Memcached 缓解读压力 | 中（读） | 最终 | — | 一致性与持久性仍需底层数据库保障 |
这些方案在"兼容存量"与"真正分布式能力"之间妥协，催生了原生分布式数据库。
3. 数据库中间件
中间件是位于应用与传统数据库之间的中间层，把分片、路由、读写分离等分布式能力从应用下沉到基础设施，是传统数据库向分布式过渡的桥梁。
3.1 典型能力与代表
- SQL 解析与路由：解析 SQL，按分片键路由到目标库表；
- 读写分离：将读请求导向只读副本；
- 结果归并：对跨分片查询结果做合并、排序、分页；
- 分布式事务：提供弱 XA 或 TCC 等事务协调。
| 产品 | 形态 | 特点 |
|---|---|---|
| ShardingSphere | JDBC / Proxy 双形态 | 分库分表、读写分离、加密 |
| MyCat | Proxy | 兼容 MySQL 协议 |
| Vitess | Proxy | 面向 MySQL 的云原生分片，支撑大规模部署 |
3.2 局限与定位
- 跨分片 JOIN、分布式事务能力有限，复杂查询需下推或受限；
- 引入额外网络跳数与单点（Proxy 模式）；
- 与底层数据库版本耦合，升级受限。
中间件在"不替换数据库"的前提下获得部分分布式能力，但一致性、全局索引、弹性扩容仍不及原生分布式数据库。随着原生方案成熟，新系统更倾向直接使用原生分布式数据库，中间件多用于存量系统迁移过渡。
4. NewSQL：兼得 SQL 与扩展
NewSQL 指兼具 SQL 接口 / ACID 事务与水平扩展能力的分布式数据库——NoSQL 解决了扩展却牺牲了 SQL 与事务，关系型保有一致性却难扩展，NewSQL 试图兼得二者。
4.1 代表产品
| 产品 | 核心理念 | 一致性 |
|---|---|---|
| Google Spanner | 全球分布式，TrueTime + Paxos + 2PC（详见《事务与恢复》） | 外部一致（线性） |
| CockroachDB | 受 Spanner 启发，无共享架构、Range 分片 + Raft 复制，兼容 PostgreSQL 协议 | serializable |
| TiDB | 计算存储分离，TiKV（Raft）+ 无状态 SQL 层，兼容 MySQL | 强（Raft） |
| VoltDB | 内存优先、确定性执行，追求极低延迟 | serializable |
4.2 共性技术
- 数据分片：Range / 哈希分片；
- 多副本复制 + 共识：Raft / Paxos 保证副本一致；
- 分布式事务：2PC / 共识化原子提交。
4.3 与 HTAP 的融合
NewSQL 进一步向 HTAP 演进：同一系统内同时服务 OLTP 与 OLAP（如 TiDB 行存 + TiFlash 列存），一条 SQL 链路兼顾事务与分析负载。
5. 小结
- 三种典型架构：计算存储分离（TiDB）、分库分表 + Paxos（PolarDB-X）、无主 LSM（Cassandra）——一致性、扩展、事务各有取舍；
- 传统四方案（共享存储/读写分离/分库分表/缓存前置）在兼容存量与分布式能力间妥协；
- 中间件把分片路由下沉到基础设施，但一致性、全局索引、弹性仍不及原生方案；
- NewSQL 用"分片 + 共识复制 + 分布式事务"兼得 SQL 与扩展，并继续向 HTAP 演进。
下一章讲解概念解析与选型：云原生、HTAP、图数据库与内存数据库。