CAP定理

1. 什么是CAP定理

CAP定理（CAP theorem）又被称作布鲁尔定理，是分布式计算领域一个公认的定理。
any distributed system cannot guaranty C, A and P simultaneously.
对于一个分布式计算系统，不可能同时满足一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三个设计约束。

1.1. C 一致性(Consistence)

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

• 不需要保证同一时刻所有节点上的数据完全一致
• 事务过程中，读操作可以读到旧的数据，但是不能读到事务过程中的数据

1.2. A 可用性（Availability）

非故障节点在合理的时间内应返回合理的响应（不是错误或者超时）

1.3. P 分区容错性（Partition Tolerance）

当出现网络分区后，系统能后继续履行职责

• 网络分区包括 丢包、连接中断、堵塞等
• “继续履行职责”跟可用性差不多

2. CAP应用

虽然CAP理论中是三个要素只能选两个，但是放在分布式环境下，我们会发现必须选择P要素。因为网络本身无法做到100%可靠，所以分区是一个必然现象，那么就需要保证这种必现场景下的处理。

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

2.1. CP

CP架构需要保证一致性和分区容忍性

N1、N2是两台节点，同时持有数据x。此时N1上数据更新到了y，但是由于同步通道中断，N2上还是x。
当客户端C访问N1时，返回最新数据y。当访问N2时，由于要满足一致性，N2不能返回x，返回error。而这正好违背了可用性A。

2.2. AP

AP架构需要满足可用性跟分区容忍性

N1、N2是两台节点，同时持有数据x。此时N1上数据更新到了y，但是由于同步通道中断，N2上还是x。
当客户端C访问N1时，返回最新数据y。当访问N2时，由于要满足可用性，N2返回x。客户端访问两台节点时返回的数据不同，正好违背了一致性C。

3. CAP细节

3.1. CAP关注的粒度是数据，而不是整个系统

在实际设计过程中，系统会处理多种数据。做设计时有的数据可以选择AP、有的数据可以选择CP。不要从整个系统的角度去选择CP、AP，会顾此失彼。
以用户管理系统为例，用户管理系统包含用户账号数据（id、密码），用户信息数据（名字、兴趣、爱好、性别）。通常情况下，用户账号数据会选择CP、用户信息数据会选择AP。如果从系统层限定CP还是AP，则都不符合具体场景。

3.2. CAP是忽略网络延迟的

在实际生产中，数据同步存在延时，这个时延根据节点的物理距离而不同。当一个事务提交完成时，不同节点数据并不完全相同。一致性C不能完美实现。

3.3. 正常情况下，不存在CP和AP的选择，可以同时满足CA

当系统没有发生分区现象时，CA都可以保证。
以用户管理系统为例，对于实现CA，不同的数据实现方式可能不一样。用户账号数据可以采用消息队列来实现CA，消息队列可以较好的控制实时性。而用户信息数据可以采用 数据库同步来实现CA。

3.4. 放弃不等于什么都不做，需要为分区恢复后做准备

CAP理论告诉我们三者只能取两个，需要“牺牲”另外一个。但是这里的牺牲不代表什么都不做，可以做一些措施在故障恢复后快速达到可用状态。
对于用户信息数据，假设选择了AP，当分区发生后，节点1和节点2都可以修改用户信息，但修改可能不同。当分区恢复后，系统可以按照某种规则来合并这两条修改数据。比如谁的更新时间最新，直接覆盖原有的。或者将冲突报告出来，人工选择哪一条。