NewSQL 的分布式事务

以 Spanner、TiDB 为代表的 NewSQL，在内部集群多节点间，实现了 ACID 的事务，即提供给用户的事务接口与普通本地事务无差别，但是在内部，一个事务是支持多个节点多条数据的写入，此时无法采用本地 ACID 的 MVCC 技术，而是会采用一套复杂的分布式 MVCC 来做到 ACID。大多数的 NewSQL 分布式事务技术都采用这篇论文 Percolator 介绍的核心技术。

那么从 CAP 的角度看，三者不能同时兼备，那么 NewSQL 选择了什么，牺牲了什么呢？

• 首先我们看 C（一致性），这是数据库类的应用必须具备的。只要数据写入了，后续的读，一定能获取到最新写入的结果。你可以想象如果不是这样，那么你的应用处理关键事务如订单时，如果读到的结果不是最新的，那么你就无法确定订单的当前准确状态，就无法进行正确处理，更无从谈起 ACID 特性。

• 然后我们看 P（分区），只要是分布式系统，那么 P 就是必然有概率发生的，因此 P 是分布式系统必须处理，必须具备的特性。

• 最后我们再看 A（可用性），由于架构的发展，系统出现网络分区的频率可以大幅降低。另外分布式共识算法的发展，可以在较短的时间，正确的达成共识，从而从分区故障中恢复。谷歌分布式锁 Chubby 的公开数据显示，集群能提供 99.99958％的平均可用性，一年也就 130s 的运行中断。这样的可用性相当高，对实际应用的影响微乎其微。

也就是说随着现代工程和共识算法的发展，可以构造出满足 CP 的系统，同时接近于满足 A，可以称之为 CP+HA，这里 HA 代表的是非 100%的 A，而是很高的可用性。公开的数据显示，谷歌的 Spanner 支持 ACID 的事务特性，同时提供了高达的 5 个 9 的可用性，因此这是一个 CP+HA。既然 NewSQL 已经达到了 CP+HA，那么从 CAP 的角度看，BASE 中的典型 Dynamo 系统等，只达到了 AP，他们是否就可以退出历史舞台了呢？不会！NewSQL 和 BASE 的系统之间，性能上差异可能是巨大的，因此在实际高性能高并发应用上，BASE 也是有不少的应用场景的。