8.1 NewSQL 要扩展也要 ACID
8.1 NewSQL：要水平扩展，也要 ACID
NewSQL 是"我全都要"的产物——既要关系数据库的 ACID 与 SQL 体验，又想拿到 NoSQL 式的水平扩展。TiDB、CockroachDB 是这条路上的代表。本节拆它的两层套路：用共享无盘分片拿扩展、用共识与分布式事务把一致性补回来，回答它凭什么敢说"两者兼得"、代价又落在哪儿。
学习目标
阅读完本节，你应当能够：
- 说明 NewSQL 的设计目标与它试图同时满足的两类需求。
- 用"分片 + 共识 + 分布式事务"三步复述 NewSQL 的架构骨架。
- 判断你的业务是否真的需要 NewSQL，而非又被它的口号带偏。
一句"我全都要"引发的野心
回看第 2 章你会发现关系型传统库和 NoSQL 像是两个极端：一边 ACID 强到死、一边为规模把一致性松掉。总有人不死心问"为什么不能同时要"。NewSQL 的回答是：能，只要你在架构上舍得下功夫。它的野心一句讲清——对用户保持"还是熟悉的 SQL 和事务"，对底下用分布式换来"想扩就扩"。 TiDB、CockroachDB、谷歌的 Spanner 是这派的旗手。它们不是"缝合怪"，而是把前面几章的硬手段砌成了一套可运转的整机。
一、NewSQL 的三板斧
第一板斧：Shared-Nothing 分片。 数据按第 4 章的哈希/范围切块，落到多台节点，从根上拿到水平扩展的底子。这一板斧让"容量和并发不够就加机器"成为可能。
第二板斧：共识把多副本对齐。 每一片都放多份副本，用 Raft/Paxos（第 6 章）保证主副本变更时多数一致，副本间不打架、故障还能自动选、新主。这一板斧兜住了"分片后数据不能丢、不能乱"的可靠性。
第三板斧：分布式事务把 ACID 补回去。 这是 NewSQL 与大多数 NoSQL 决胜的一手——它仍给用户完整的 ACID 事务（第 5 章那套 2PC/MVCC 的强化版），让"改订单时要扣库存可以是一个原子动作"这种被 NoSQL 长期放弃的体验回来了。
NewSQL 的架构骨架
二、凭什么敢说"两者兼得"，代价又在哪
它敢这么说，正是因为三板斧把"扩"和"稳"在架构上分开做到了。但世上没有白拿的午饭：NewSQL 的风险与成本同样突出。一是复杂度——共识、事务、规划这些层叠在一起，无论实现还是运维都远超传统库；二是性能——为了强一致与 ACID，短事务有时要走多数确认、写路径并不总比纯 NoSQL 快；三是运维心智——节点多、状态多，出问题排查链路比单机库深得多。所以 NewSQL 最辩证的位置是：它适合"既要大表、又要强事务、还要能扩展"的核心交易型业务（订单、账务、风控），而不是一切业务的万能选项。
三、一张与 NoSQL 的分野对照
把 NewSQL 和下一节的 NoSQL 摆一起，分歧一目了然：
| 维度 | NewSQL | 典型 NoSQL |
|---|---|---|
| 事务 | 完整 ACID | 多最终一致、少强一致 |
| SQL | 保留关系型 | 多非关系模型 |
| 一致性 | 围绕强一致设计 | 常作最终一致取向 |
| 适配 | 核心交易型 | 海量非结构化、高并发扩流 |
| 例举 | TiDB、CockroachDB | Cassandra、Mongo、Redis |
四、把三板斧装进一台真实库看看
拿 TiDB（NewSQL 里的代表）当例子，把三板斧落一遍你就不抽象了。第一板斧：TiDB 的 TiKV 把数据按范围切成很多 Region，散落在多台 TiKV 节点上，这就是"分片拿扩展"，Region 多了就自动调度、拆分、迁移。第二板斧：每个 Region 默认放 3 份副本（存储在三台不同节点上），靠 Raft 让三份副本就日志达成一致，主副本变了其他自动同步、故障自动选新主，这就是"共识保可靠"。第三板斧：最上层一个专门的 TIDB Server 负责解析 SQL、生成分布式执行计划，执行时用两阶段提交保证跨 Region 的写入要么全成要么全不成，这就是"分布式事务补 ACID"。三层一叠，你看见的仍是"熟悉的 SQL + 完整事务"，底下的分片与共识早已悄悄把扩展和可靠一起做了。
五、什么样业务才真地需要它，别被口号带走
有上面的底子，判断就冷静多了。真该考虑 NewSQL 的，往往同时满足三件事：数据量或流量大到单机库放不下或扛不住（否则你没动机付复杂度）、要求强 ACID 不可妥协（否则 NoSQL 更轻）、且核心负载是交易型而非纯分析（分析有更划算的 OLAP）。而不该只冲着"NewSQL=先进"就去换的，是这些情况：数据量并不大、一个从库就够、或你只是想要 SQL 体验——那传统库或云数据库托管反而更省心。用一句大白话收束：NewSQL 是给"既要大又要硬"的生意准备的，不是给"喜欢新技术"的人准备的。 想清楚这一点，选型地图上你就已经赢在起跑线。
六、动手前的一张三问自测表
怕你被 NewSQL 的口号冲昏头，把它适不适配用三问自测一遍：一、数据量或流量是否已经大到单机放不下、或抗不住？ 没到，别急着付复杂度的账；二、是否强 ACID 不可妥协、且是核心交易型而非纯分析？ 是，才值得 NewSQL；三、是否真愿意为强一致扛下"分区时宁可延迟也不给错"的取向？ 这一点最容易被忽略——NewSQL 给你强 ACID，也继承了"分区时先拒单也不出错"的取向，它不是万金油。三问都能痛快点头，NewSQL 才该进你的候选池；只要有一问犹豫，就往传统库、云托管或 NoSQL 那边退——退并不意味着落后，而是匹配。
本节要点回顾
- NewSQL 目标：SQL + ACID + 水平扩展，三者我都要。
- 三板斧：分片拿扩展、共识保可靠、分布式事务补 ACID。
- 不白拿：复杂度、性能与运维成本都高于传统库。
- 合身才是真：适合核心交易型业务，不是万能药。
NewSQL 用"补回 ACID"回应了 NoSQL 在一致性上的让步，但 NoSQL 的诱人之处——那份拿关系型纪律换取的海量高并发扩展——自有它不可替代的价值。下一节 8.2 我们看看 NoSQL 各族（文档、键值、列族）到底各自兑了什么、收了多少代价。