cap理论

一、基本概念

cap有两个版本，第二版觉得更精确，下面开始论述

第一版解释：对于一个分布式计算系统，不可能同时满足一致性（consistence），可用性（Availability），分区容错性（PartitionTolerance）三个设计约束

第二版解释：在一个分布式系统（互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性，可用性，分区容错性三者中的两个，另外一个必须被牺牲。

对比两个版本的定义，有几个很关键的差异性：

1.第二版定义了什么才是CAP理论探讨的分布式系统，强调了两点：

互相连接 和共享数据，为何要强调这两点呢？因为分布式系统不一定会互联和共享数据。最简单的memcache集群，相互之间就没有连接和共享数据，因此memcache集群这类分布式系统就不符合CAP理论探讨的对象；而mysql集群就是互联和进行数据复制的，因此是CAP理论探讨的对象。

2.第二版强调了write/read  pair,这点其实是和上一个差异点，一脉相承的。也就是说，CAP关注的是对数据的读写操作，而不是分布式系统的所有功能。例如，ZooKeeper的选举机制就不是CAP探讨的对象。

相比来说，第二版的定义更加精确

第二版除了基本概念，三个基本的设计约束页进行了重新阐述，我来详细分析一下。

1.一致性（consistency）

第一版：所有节点在同一时刻都能看到相同的数据

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

两版差异：

1.第一版从节点node的角度描述，而第二版从客户端client角度描述

2.第一版的关键词是see，第二版的关键词是read

3.第一版强调同一时刻拥有相同数据，第二版并没有强调这点（这就意味着实际上对于节点来说，可能同一时刻拥有不同数据，这和我们通常理解的一致性是有差异的，为何做这样的改动呢？对于系统执行事务来说，在事务执行过程中，系统其实处于一个不一致的状态，不同的节点的数据并不完全一致，因此第一版的解释是不严谨的，因为事务在执行过程中，client是无法读取到未提交的数据的，只有等到事务提交后，client才能读取到事务写入的数据，而如果事务失败则会进行回滚，cliient也不会读取到事务中间写入的数据，可以理解为，只有事务正常执行完后，从节点才会复制数据，所以才能读到，但是主节点其实有数据了，所以不一致？）

2.可用性（availability）

第一版的解释：每个请求都能得到成功或者失败的响应。

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

差异：

1.第一版是每一个请求，第二版强调了一个非故障节点

显而易见如果节点故障了，发给节点的请求不一定能得到一个响应。

2.第一版的响应分为成功和失败，第二版用了两个合理，合理的响应和合理的时间，而且特别强调了不是错误或者超时

第一版的成功失败的定义太泛了，几乎任何情况，无论是否符合CAP理论，我们都可以说请求是成功和失败，因为超时也算失败，错误也算失败，异常也算失败，结果不正确也算失败；即使是成功的响应，也不一定是正确。例如，本来应该返回100，但实际上返回了90，这就是成功的响应，但没有得到正确的结果。相比之下，第二版的解释明确了不能超时，不能出错，结果是合理的，注意没有说正确的结果。例如，应该返回了100但实际上返回了90,肯定是不正确的结果，但可以是一个合理的结果。

3.分区容错性（Partition Tolerance）

第一版解释：出现消息丢失或者分区错误时系统能够继续运行

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

差异：

1.第一版用的是work，第二版用的是function；work强调运行，只要系统不宕机，我们都可以说系统在work，返回错误也是work，拒绝服务也是work；而function强调发挥作用，履行职责，这点和可用性是一脉相承的。也就是说，只有返回合理的响应才是function。

2.第一版描述分区用的是消息丢失或者分区错误，第二版之间用网络分区

第一版直接说原因，即消息丢失造成了分区，但是消息丢失的定义有点狭隘，因为通常我们说的丢包，只是网络故障中的一种；第二版直接说现象，即发生了分区现象，不管是什么原因，可能是丢包，也可能是连接中断，还可能是拥塞，只要导致了网络分区，就通通算在里面。

二、CAP应用

虽然CAP理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择p要素，因为网络本身无法做到100%可靠，有可能出现故障，所以分区是一个必然的现象。如果我们选择了CA而放弃了P，系统返回error（例如，当前系统不允许写入），这又和A冲突了，因为A要返回no error和no timeout。因此分布式理论上不可能选择CA架构，只能选择CP或者AP架构。

1.CP（consistency/partition Tolerance）

如下图所示，为了保证一致性，当发生分区现象后，N1节点上的数据已经更新到y，但由于N1和N2之间的复制通道终端，数据y无法同步到N2，N2节点上的数据还是x。这时客户端C访问N2时，N2需要返回Error，提示客户端C“系统现在发生了错误”，这种处理方式违背了可用性的要求，因此CAP三者只能满足CP

2.AP（Availability/Partition Tolerance）

如下图所示，为了保证可用性，当发生分区现象后，N1节点上的数据已经更新到Y，但由于N1和N2之间的复制通道中断，数据y无法同步到N2，N2节点上的数据还是x。这时客户端C访问N2时，N2将当前自己拥有的数据x返回给客户端C了，而实际上当前最新的数据已经是y了，这就不满足了一致性，因此CAP三者只能满足AP。注意，这里N2节点返回x，虽然不是一个正确的结果，但是一个合理的结果，因为x是旧的数据，并不是一个错乱的值，只是不是最新的数据而已。

 

总结：

什么是cap理论？

一致性，可用性，分区容忍性，并且定理指出，在系统实现时，这三者最多坚固两点。

互联网，最常见的实践是这样的：

1.节点连通性，多节点扩展性，连通性异常的处理必须保证，满足p

2.一致性c与可用性A一般二选一

3.选择一致性C，举例：传统单库水平拆分，就是这类选型的典型

4.选择可用性A，举例：双主库同步高可用，就是这类选型的典型

强一致性很难怎么办？

单点串行化，虽然能保证”强一致“，但对系统的并发性能，以及高可用有较大影响，互联网的玩法，更多的是最终一致性，短期内未必能读到最新的数据，但在一个可接收的时间窗口之后，能够读到最新的数据。

例如：数据库主从同步，从库上的数据，就是一个最终的一致。

CAP可以理解为一致性，可用性，联通与扩展性

CAP三者只能取其二

最常见的实践是AP+最终一致性