cap 理论

cap是实现分布式系统的思想。

由3个元素组成。

Consistency（一致性）

在任何对等 server 上读取的数据都是最新版，不会读取出旧数据。比如 zookeeper 集群，从任何一台节点读取出来的数据是一致的。

Availability（可用性）

虽然系统内部会出现一些故障，但整体一直会对外提供服务，不至于崩溃。比如有10台 server，其中4台 server 出现了故障，经过特殊处理，把请求交给剩余的6台运行正常的 server，整体还在运行中，没有因为4台出现故障的 server 造成整体失效，实现高可用。

Partition Tolerance（分区容忍性）

有 C 和 D 两台 server，C 在中国，D 在美国，如果发生网络异常，则 C 和 D 在不同网络分区中可以正常运行。

实现分布式理论基本上通过算法 paxos 和 gossip 来作为理论指导

可以分成3种组合：CA、AP、CP

在网络环境中，网络不可能不出现故障，所以 P 一定是存在的，一定要保证 P 的功能是正常的。

在 P 必须存在的情况下，CAP 理论定义出两种组合，AP 和 CP

AP

代表在分区的情况下保证高可用，多台机器出现了问题至少有一个可用。

CP

代表在分区的情况下保障一致性，要么全部同步要么不同步。类似于关系数据库的事务特性ACID，全部sql要么全部执行成功，要么全部不成功，不成功的话需要回滚到之前状态。

为什么当 P 存在时，C 和 A 不能同时存在呢？

有 A 和 B 主从备份分布式系统，当 client1 向 A 写入数据时，为了保证两者的一致性，必须使用锁来避免 client2 从 B 读取出旧的数据，client1 向 A 和 B 写完数据后再释放锁。如果这样做就无法保证 A 的可用性，因为有锁的存在，client2 一直是阻塞状态，B 不能提供服务，所以一致性和高可用不可能同时存在。如果不在一个网络环境中，加锁的操作资源消耗是相当大。

如果发生网络分区（脑裂）的情况，则 A 和 B 的主从架构不能保证数据的一致性，client2 想要读取最新正确的数据是不能实现的，除非放弃高可用特性或放弃一致性特性，所以 C 和 A 不可能同时存在。

很多开源组件能看到这个理念的实践

zookeeper

cp，因为只要一个 leader，所有的写入只能通过 leader 执行，写入完成后同步给 follower。

redis 集群

ap，因为集群保证了是在高可用的基础上增加了分布式的功能，所以能做到ap，可以做到一致性，但是不是强一致性，是最终一致性，因为主从复制的异步导致的。

mysql 集群

ap 和 cp 都支持。

至于选择 ap 还是 cp，需要看实际情况侧重于高可用还是一致性，对于一致性要求是强一致性还是最终一致性，有的组件两种组合都支持。有的只支持一种，具体要看实际情况具体选择。

参考链接

Paxos、Raft、ZAB、Gossip 分布式一致性算法理解 - 简书