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也是有不少的应用场景的。