分布式CAP原理：一致性、可用性、分区容错

CAP概念

分区容错（Partition tolerance）

一致性（Consistency）

可用性（Availability）

一致性和可用性之间的矛盾

使用场景

CAP概念

单机系统由于所有的处理都在单机完成的，所以不存在数据一致性问题，但是如果系统崩溃了，就导致服务不可用。

分布式系统可以实现服务的高可用，现有的大型网站几乎都是分布式的，特别是微服务的出现，使得分布式系统正变得越来越重要。

分布式系统最大的难点，就是各个节点的状态如何同步。CAP原理给分布式系统的实现带来了指导思路，它也是理解分布式系统的重要理论。

CAP由以下三个指标组成：

C（Consistency）：一致性

A（Availability）：可用性

P（Partition tolerance）：分区容错

CAP之间的关系，如图：

可以看出，CAP这三个指标不能同时做到。

分区容错（Partition tolerance）

分区容错，意思是允许分区之间的通信失败。

一般来说，网络的通信失败是无法避免的，如通信超时的情景：A区向B区发送请求，但是由于网络环境的随机复杂性，导致响应超时，这时A区并不知道B区的处理是否成功。

如图：

所以，分布式系统要允许分区之间通信的失败，也就是CAP中的P总是成立的，但是剩下的 C 和 A 是无法同时做到的。

一致性（Consistency）

一致性，意思是在一个分区进行写操作后，所有分区的数据都要保持一致的读操作。

如开始时，A区和B区的数据都为v0，客户端修改了A区的v0为v1，此时，客户端读取A区是v1，但是读取B区的还是v0，这就不满足一致性了。如图：

为了满足一致性，A区需要向B区发起数据同步操作，把B区的改成v1，这时，客户端读取任意一个分区，都返回一致性的数据v1。如图：

可用性（Availability）

可用性，意思是只要收到请求，系统就必须给出响应。

分布式系统有多个分区，即使有少数分区的服务崩溃了，还能继续提供服务，这就是服务的可用性。

一致性和可用性之间的矛盾

一致性和可用性不能同时做到的原因是：出现了分区容错，也就是可能通信失败。

如上例子，如果要保证B区的一致性，那么在A区进行写操作时，必须给B区的数据加上读写锁，在锁定期间，客户端不能读写该数据。只有数据同步后，才释放掉锁，B区才重新开放读写。这样，保证了一致性，但是没有了可用性。

如果要保证B区的可用性，就不能对B区加上读写锁，这样又缺少了一致性。

因此，一致性和可用性是不能同时做到的。在设计分布式系统时，如果追求一致性，那么无法保证所有分区的可用性；如果追求所有分区的可用性，那么就没法做到一致性。

使用场景

注重一致性：很多事务型的交易系统都要求具有一致性，如抢车票系统，同一时刻，所有用户看到的必须是最新的车票状态，不能是一部分用户看到有余票，另一部分用户看到无票。

注重可用性：CDN（内容发布网络）服务，网页的更新不是特别强调一致性，短期内，用户浏览到不同版本的网页，但是，最终所有人都能看到最新版本，也就是最终保持了一致性。