【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
CAP理论有以下两个版本：
- 第一个版本的解释：对于一个分布式计算系统，不可能同时满足一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三个设计约束。
- 第二个版本的解释：在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Avaliability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须牺牲。
对比两个版本的定义，有几个很关键的差异：
- 第二版定义了什么才是CAP理论讨论的分布式系统，强调了两点：interconnected和Share data (连接和数据共享)，为何要强调这两点呢？因为分布式系统并不一定会互联和共享数据。最简单的如Memcache集群，相互之间没有连接和数据共享，因此Memcache集群这类分布式系统不符合CAP理论探讨的对象；而Mysql集群就是互联和进行数据复制的，因此是CAP理论讨论的对象。
- 第二版强调了write/read pair，也就是说，CAP理论关注的是数据的读写操作，而不是分布式系统中的所有功能。如Zookeeper的选举机制就不是CAP探讨的对象。
所以，相比来说，第二版定义更加精确。
一致性
- 第一版：所有节点在同一时刻都能看到相同的数据。
- 第二版：对某个指定的客户端来说，读操作保证能返回最新的写操作结果。
两版的差异点表现：第一版从节点node角度描述，第二版从客户端client的角度描述。
可用性
- 第一版：每个请求都能得到成功或失败的响应。
- 第二版：非故障节点在合理的时间内返回合理的响应（不是错误和超时的响应）
分区容错性
- 第一版：出现消息丢失或都分区错误时系统能继续运行。
- 第二版：当出现网络分区后，系统能继续“履行职责”。
对比两版本解释，第一版直接说原因，即message loss造成了分区，但message loss定义有点侠隘，因为通常我们说的message loss（丢包）只是网络故障中的一种；第二版直接说现象，即发生了分区现象，不管是什么原因，可能是丢包，也可能是网络中断，还有可能是拥塞，只要导致了网络分区，都通通算在里面。
CAP应用
虽然CAP理论中定义的三个要素中只能取两个，但放到分布式环境下来考虑，我们会发现必须选择分区容错性，因为网络本身无法做到100%可靠，可能出现故障，所以分区是一个必然的现象。如果我们选择了CA,放弃了P，那么当发生分区现象时，为了保证C,系统需要禁写入，当有写入请求时，系统返回error,这又和A冲突了，因为A要求的是返回no error和no timeout。因此分布式系统理论上不可能选择CA架构，只能选择CP或AP。
CP -Consistency/Partition Tolerance
如图：
N1节点上的数据已经更新到了y,但N1和N2之前的复制通道中断，数据y无法同步到N2,N2节点上的数据还是x。为了保证一致性，当发生分区现象后，这时客户端C访问N2时，N2需要返回Error,提示客户端C"系统现在发生了错误"，这种处理方式违背了可用性（Availability）的要求，因此CAP三者只能满足CP。
AP -Availability/Partion Tolerance
如图
N1节点上的数据已经更新到了y,由于N1和N2之间的复制通道中断，数据y无法同步到N2,N2节点上的数据还是x。为了保证可用性，当发生分区现象后，这时客户端C访问N2时，N2将当前自己拥有的数据x返回给客户端C了，而实际上当前最新的数据已经是y了，这就不满足一致性（Consistency）的要求了，因此CAP三者只能满足AP。
来源：oschina
链接：https://my.oschina.net/u/3242075/blog/3145677