过时的CAP理论

1. CAP简介

这里主要是学习一下分布式系统的基础理论CAP理论,这个理论在之前被认为是理解CAP系统的起点，CAP理论认为对于一个分布式系统，存在以下3个不能同时满足的指标

• Consistency
• Availability
• Partition tolerance

CAP实际上是取了三个的首字母构成，CAP理论认为分布式系统最多能够满足三个指标中的两个（实际上这个描述是有问题的，下面会聊到）

2. CAP详情

我们可以假想一下我们的分布式系统有三个节点，假如我们的集群有三个节点（node01,node02,node03）
node01在美国
node02在中国
node03在日本

同时有两个个client ,client01,client02

每个数据都有都有三个副本,也就是说数据在每个节点上都有一个副本

1. Consistency, 一致性

这里的分布式的一致性理解都来源于《数据密集型系统设计一文》和raft的相关论文，
这里的一致性意味着server端对于client端具备线性化的一致性，这里面有几个含义：

线性一致性（linearizability）,（也称为原子一致性（atomic consistency），强一致性（strong consistency），立即一致性（immediate consistency）或外部一致性（external consistency ））。线性一致性的精确定义相当微妙,但是基本的想法是让一个系统看起来好像只有一个数据副本，而且所有的操作都是原子性的。有了这个保证，即使实际中可能有多个副本，应用也不需要担心它们。

在raft当中是这样描述的

Our goal for Raft is to implement linearizable semantics (each operation appears to execute instantaneously,
exactly once, at some point between its invocation and its response)

也就是每个client请求的操作执行都可以被看做一个瞬时态，这个瞬时态必须处在在client的请求发起到请求返回之间。
这里包含的有多个意思,对这些意思的理解参考了《数据密集型系统设计》一文
client的请求一般包括两类，write(写)和read(读)

1. 瞬时态意味着当前操作的过程对其他操作不可见（就像事务之间的隔离性一样,是一个原子操作，可以类比对寄存器的操作），如果client01在发起了一次write操作log01,那么在client01发起request和获得到response之间（因为存在网络延迟，所以应该说在在server端处理完client01的这个请求之前），这个log01对client02是不可见的，不管client02怎么请求都不能得到值log01。

2. 在write操作返回成功的response之后（因为存在网络延迟，所以应该说在在server端处理完client01的这个请求之后），这个数据对当前client后续的操作（在时间维度上的后续）就是可见的了

3. 如果服务端对client01的某一次read请求返回了最新的值，那么服务端会对后续（在时间维度上的后续）任何client的请求返回最新值

4. 返回没有成功写入，那么这个数据对后续也是不可见的

5. 假如服务端超时，这个时候其实是不知道server端对这个请求是完成了还是拒绝了，理论上需要使用一次查询请求来看看是否成功了(服务超时一般是网络丢包或者是服务端出现了master宕机导致)

2. Availability

某个副本即使与其他副本断开连接，也可以独立处理请求（例如多主复制）。在这种情况下，应用可以在网络问题前保持可用，但其行为不是线性一致的,也就是说当你想要A的时候C就已经无法保证了。

3. Partition tolerance

这分区容忍性实际上是必须做的，因为网络分区是必然发生的

3. 再谈CAP

  之前理解CAP的时候，总是觉得过于晦涩，虽然网上相关的资料博客千千万，但是理解起来很别扭，尤其是分区容忍性这一块儿，什么叫分区容忍性，比如如果一个系统选择了CA，那么发生了网络分区，他怎么办，继续工作的话肯定无法满足Consistency, 返回失败的话肯定就无法满足Avaliablity。而网络上的各种资料更多的介绍都是CAP三个指标我们只能选两个，如果按照这个逻辑来说的话,这个CAP的应该是CA理论才对。因为网络故障是必然发生的而不是你选择有没有网络故障发生。
  每次看这个理论都看得很痛苦，终于从**《设计数据密集型系统》**这本书中找到了答案，而且也印证了我的想法是正确的。

CAP最初是作为一个经验法则提出的，没有准确的定义，目的是开始讨论数据库的权衡。那时候许多分布式数据库侧重于在共享存储的集群上提供线性一致性的语义，CAP定理鼓励数据库工程师向分布式无共享系统的设计领域深入探索，这类架构更适合实现大规模的网络服务。 对于这种文化上的转变，CAP值得赞扬 —— 它见证了自00年代中期以来新数据库的技术爆炸（即NoSQL）。

CAP定理没有帮助
CAP有时以这种面目出现：一致性，可用性和分区容错性：三者只能择其二。不幸的是这种说法很有误导性，因为网络分区是一种错误，所以它并不是一个选项：不管你喜不喜欢它都会发生。
在网络正常工作的时候，系统可以提供一致性（线性一致性）和整体可用性。发生网络故障时，你必须在线性一致性和整体可用性之间做出选择。因此，CAP更好的表述成：在分区时要么选择一致，要么选择可用。一个更可靠的网络需要减少这个选择，但是在某些时候选择是不可避免的。

在CAP的讨论中，术语可用性有几个相互矛盾的定义，形式化作为一个定理不符合其通常的含义。许多所谓的“高可用”（容错）系统实际上不符合CAP对可用性的特殊定义。总而言之，围绕着CAP有很多误解和困惑，并不能帮助我们更好地理解系统，所以最好避免使用CAP。

CAP定理的正式定义仅限于很狭隘的范围，它只考虑了一个一致性模型（即线性一致性）和一种故障（网络分区，或活跃但彼此断开的节点）。它没有讨论任何关于网络延迟，死亡节点或其他权衡的事。 因此，尽管CAP在历史上有一些影响力，但对于设计系统而言并没有实际价值。

在分布式系统中有更多有趣的“不可能”的结果，且CAP定理现在已经被更精确的结果取代，所以它现在基本上成了历史古迹了。
比如CAC理论

参考

https://zhuanlan.zhihu.com/p/42239873?utm_source=wechat_timeline&utm_medium=social&from=timeline&isappinstalled=0
https://zhuanlan.zhihu.com/p/47025699