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