目录
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,需要看实际情况侧重于高可用还是一致性,对于一致性要求是强一致性还是最终一致性,有的组件两种组合都支持。有的只支持一种,具体要看实际情况具体选择。
参考链接