分布式事务 之 CAP不可能三角

不可能三角，又称三元悖论，来自经济学，即只能拥有其中两项，而不能同时拥有三项（资本自由流动、固定汇率和货币政策独立性）。
分布式系统的CAP定理，也是一个不可能三角。

CAP theorem - Wikipedia

CAP概念

  • Consistency 一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
  • Available 可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
  • Partition Tolerance 分区容错性：分布式系统，出现任何单个节点服务、网络故障，仍然可以对外提供满足一致性或可用性的服务。——虽然是一个分布式系统，但对于用户而言，看上去好像是一个运转正常的整体。（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。）

为什么CAP不可同时满足：

  • 满足一致性（C），所有节点数据时刻保持一致，比如用户更新A节点数据后，系统同步数据到B节点，保证一致性，阻塞用户请求，节点之间数据同步完成后才能正常访问系统。
  • 满足可用性（A），所有请求都可以得到正常响应。比如A节点数据发生变更，B节点尚未完成同步时，访问到B节点的用户可以正常请求到数据（变更前的数据），此时满足了可用性，但牺牲了一致性。
  • CA同时满足：放弃分区容错性，加强一致性和可用性，放弃了系统的扩展性，分布节点受限，无法部署子节点，其实就是传统的单机，这违背了设计分布式系统的初衷。

所以，P是分布式系统最基本的要求，只能在保证P的前提下，来优先C或者A，即CP或AP。

  • CP
    保证一致性牺牲可用性，网络等等异常时节点数据同步异常，为保证各节点数据一致，系统会停止服务。
  • AP
    网络异常时系统仍可以工作，但各节点数据可能不一致。

注册中心常见的，Eureka（Spring Cloud使用的）是AP，Zookeeper是CP。NoSQL数据库，HBase和Redis强调CP，Cassandra强调AP。

要实现强一致性的成本很高，尤其是存在很多数据副本的情况下，区块链的PoW及其衍生算法就是典型的代表，它的共识机制是概率强一致性（Probabilistic Strong Consistency），要求等待大多数节点都接受了这笔交易再真正接受它，但是带来的问题是交易的确认严重滞后。
大量工程实践表明，可用性、一致性都很重要，可以允许一定的时差，保证最终一致性：一定时间内达到一致即可。