5.3　分布式系统理论

5.3.1　了解CAP定理

CAP是分布式系统的基础理论，它由三个单词的首字母组成，分别代表一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）。下面我们对这三个特性做具体介绍。

1. 一致性

在分布式环境中，一份数据往往有多个数据副本，在强一致性的场景下，这些数据副本在同一时刻的值是相同的。也就是说，一个“读”操作在多个数据副本下读到的值也是相同的。

2. 可用性

可用性通常被称作“高可用”，当集群中的某些节点出现故障不能响应请求的时候，集群中其他正常工作的节点依然能够正常提供服务，使集群仍然处于可用状态。

3. 分区容错性

在分布式系统中某个节点或者网络分区出现故障、区间通信可能失败的情况下，要保证其他节点可以继续对外提供服务。

正所谓鱼和熊掌不可兼得，对分布式系统来说，以上三个特性中的一致性和可用性也只能二者选其一。背后的原因不难理解：保证强一致性就必然要牺牲一部分的可用性，在所有数据副本达到一致状态之前不能对外提供服务；同理，可用性优先的系统往往采用了“最终一致性”的同步方案，这种方案允许暂时的数据不一致，但在未来的某个时间点会达到数据的最终一致，因此可用性优先的系统不能保证强一致性。

下面我们用一个ZooKeeper的例子来说明一致性和可用性之间的矛盾。ZooKeeper是一个一致性（CP）优先的系统，在任何时刻访问ZooKeeper都可以获取一致的数据，为了确保ZooKeeper各节点的数据强一致性，某些情况下ZooKeeper可能会丢弃一些请求，因而并不能保证可用性。而ZooKeeper的leader选举过程也体现了一致性优先的策略，在ZooKeeper集群环境中有一个leader的角色，leader可以看作Master节点。在某些网络异常的情况下，集群内的其他节点可能无法连接到leader节点，这时ZooKeeper会从剩余节点中重新选出一个leader。在这个过程中，为了保证数据的强一致性，在leader没有选出之前，整个ZooKeeper集群都不能对外提供服务。

由于可用性和一致性无法被同时满足，目前主流的注册中心一般是在AP方案（可用性 + 分区容错性）和CP方案（一致性 + 分区容错性）之间二选一。

5.3.2　高并发应用在CAP中的偏向性

对高并发应用来说，其每秒承载的用户请求访问量是非常惊人的。以最近一次双11大促场景为例，支付宝核心主链路每秒峰值交易处理量是52万。对于这类应用，我们在可用性和一致性二者之间更偏向于可用性优先，这主要是从时间和资源的角度来考量的。

1. 时间角度

为了保证数据的强一致性，需要花费较长时间将数据副本同步完成之后才可以对外提供服务，这个时间成本在大访问量基数下将被迅速放大，最终导致服务响应时间大幅拉长，因此无法保证系统的可用性。

2. 资源角度

以强一致性的XA事物解决方案为例，为了保证数据库事物提交的强一致性，在每个分支事物完成之前，数据库连接不会得到释放，在大访问量下数据库连接资源会被快速消耗，进而导致服务不可用。

因此，从系统的整体可用性角度来考虑，高并发场景下我们更加倾向于优先保证系统的可用性，而对应的一致性解决方案通常采用“最终一致性”方案，即在未来的某一个时间点可以达到数据一致。