简述 CAP 定理

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

CAP theorem (Brewer's theorem, 2000 ACM PODC)

Consistency: Every read receives the most recent write or an error

Availability: Every request receives a (non-error) response, without the guarantee that it contains the most recent write

Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

CAP 原理

• 一致性

• 可用性

• 分区耐受性

老师给出的是维基百科上的定义，极客时间《从零开始学架构》中，提到了 Rober Greiner 的阐述 http://robertgreiner.com/2014/08/cap-theorem-revisited/

In a distributed system (a collection of interconnected nodes that share data.), you can only have two out of the following three guarantees across a write/read pair: Consistency, Availability, and Partition Tolerance — one of them must be sacrificed.

其中强调了 interconnected 和 share data，分布式系统并不一定会互联和共享数据，比如 Memcached 集群，share nothing，不符合 CAP 理论探讨的范围；而 MySQL 集群是互联和数据复制的，属于 CAP 探讨的对象。

其次，强调了 write/read pair，也就是说 CAP 关注读写操作，而不是其他功能，比如 ZooKeeper 的选举机制，就不是 CAP 的探讨范围。

Consistency: A read is guaranteed to return the most recent write for a given client.

对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。从客户端角度描述，read，从读写角度来描述一致性

Availability: A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout)

非故障节点在合理的时间内返回合理的相应（不是错误和超时的相应）。只有非故障节点才能满足可用性要求，并且明确不能超时、不能出错，结果不一定“正确”，但是合理。

Partition Tolerance: The system will continue to function when network partitions occur.

当出现网络分区后，系统能够继续“履行职责”。function 强调履行职责，即可用性；另外只要出现 network partitions 分区现象，不管什么原因，可能是丢包，也可能是连接中断，还可能是拥塞……

对一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受性是必须要保证的，那么在可用性和一致性上就必须二选一。

在分布式系统必须要满足分区耐受性的前提下，可用性和一致性无法同时满足。

分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。

CAP 定理的使用场景是同构副本性（主从、多主）类型的架构，其中一致性是指顺序一致性、读写一致性。

HBase、MongoDB、ZooKeeper 属于 CP 架构，Cassandra、CounchDB 属于 AP 系统

zk 多数节点正常就可以正常运行，分区中的少数节点会进入 leader 选举状态，这个状态不能处理读写操作，因此不符合 A，如果不考虑实时一致性，zk 基本满足 CP 的要求

CAP 关注的粒度是数据，而不是系统。在实际设计过程中，每个系统不可能只处理一种数据，而是包含多种类型的数据，有的数据必须选 CP，有的数据必须选 AP。比如用户管理系统中，用户账号数据（用户 ID、密码） CP，而用户信息数据（昵称、兴趣、爱好、性别、自我介绍） AP

CAP 是忽略网络延迟的。CAP 理论中的 C 在实践中是不可能完美实现的，在数据复制的过程中，节点 A 和节点 B 的数据并不一致。

如果节点间的网络连接一切正常，也就是 P 不存在的情况下，没有必要放弃 C 或者 A，可以同时满足 CA。

放弃不等于什么都不做，CAP 理论的牺牲 sacrificed 只是说在分区过程中。在系统整个运行周期中，大部分时间都是正常的，99.99% 的可用性，一年不可用的时间只有 50 分钟，5 个 9 的可用性系统，一年下来不可用的时间只有 5 分钟。分区期间放弃 C 或者 A，并不意味着永远放弃 C 和 A，可以在分区期间进行一些操作（比如记录日志），当分区故障解决之后，系统重新达到 CA 状态。