架构设计读书笔记-高可用（一）- CAP定理

来源

加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的ACM PODC上提出的一个猜想，也因此被叫做布鲁尔定理。在 2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了 CAP 定理的证明，让它成为分布式系统领域公认的一个定理。

定义

第一版：对于一个分布式计算系统，不可能同时满足（Consistency），可用性（Availability）和分区容错性（Partition Tolerance）三个设计约束。

第二版：在一个分布式系统（跨区域网络连接，并共享数据的节点的集合）中，一致性（Consistency），可用性（Availability）和分区容错性（Partition Tolerance） 这三个约束属性最终只能同时满足二个，另外一个必须被牺牲。

一致性(Consistency)

第一版：所有节点在同一时间具有相同的数据

第二版：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果

解读：明显第二版更符合实际，只要还有写的操作，分布式系统永远无法保证任意时刻数据一致性，但只要保证读取的时候，获取的是最新的数据，那么就可以认为是一致的。

典型场景：电商库存（特别是秒杀场景）、金融系统扣款转账等

可用性(Availability)

第一版：保证每个请求不管成功或者失败都有响应

第二版：非故障的节点在合理的时间内返回合理的响应（非错误和超时的响应）

解读：这里的合理并不保证一定是正确的值，比如一致性没有保证的情况下，某个节点可用且返回了自身存储的旧的值，那么系统即为可用。超时以及错误的响应不能算可用

典型场景：代码库、Eurka、Cassandra

分隔容忍(Partition tolerance)

第一版：系统中任意信息的丢失或失败不会影响系统的继续运作

第二版：当出现网络分区后，系统能够继续“履行职责”

解读：分布式系统节点一般部署在多个网络环境下，通信难免出现一些网络故障，如网络丢包，网络消息延迟，网络中断等情况，会导致节点间的通信出现问题，数据同步操作无法完成，分区容错性就要求了系统即使在网络分区出现的情况下，能仍继续对客户端提供服务。

典型场景：无法必须保证

CAP应用

网络交互和数据同步的情况下，就一定会有延迟和数据丢失的情况，对于这种情况我们又必须接受且保证系统不能挂掉。所以分区容错性(Partition tolerance)是必须要保证的。最终系统就在一致性和可用性之间进行取舍

CP应用：

优先保证一致性。以读写库为例，当读写库之间链接终端，访问读库可能出现数据不准确的情况，要保证一致性，那么访问读库就只能响应系统错误，而不能响应旧值。CP应用比较多，比如HBase，MongoDB，ZooKeeper，Etcd，Consul等都是放弃了一定可用性而选择 CP 属性。

AP应用：

优先保证可用性。比如一些电商的商品信息、比如系统日志信息等，当出现分区不一致时，优先进行系统响应，保证了用户的使用体验。又比如我司的Gerrit代码库，主从库代码同步会有几秒，特殊情况会同步失败。从从库拉取代码的时候，不管主从库代码是否一致，都可以拉取到当前从库的代码。

能否同时满足CA？

正常情况下，系统没有出现分区现象，那么CA是同时满足的。也就是分区(P)虽然没法百分百满足，但是可以99.99%的情况下，系统都是没有问题的。

CAP关注的是具体的数据，而不是整个系统。

如一个系统中，账号密码存储需要满足CP，也就是登录校验必须以最新数据为准，但是登录后的信息数据，可以按照AP来满足，如用户的昵称、兴趣、爱好、自我介绍等信息，可以存在一定程度的不准确。

不管CP、AP都需要在系统P恢复正常后，为数据恢复做准备，让系统到达CA状态。

也就是都需要记录分区问题期间的修改操作，对CP架构的系统，系统恢复后，写节点同步到其它节点，对AP系统而言，需要按照一定规则，如“最后修改优先”、“字数最多优先”等进行数据同步。