CAP原则“大总结“及单机集群redis的所属

本来觉得CAP原则挺简单的，但一搜网上一大堆，翻译的版本不一，对概念的解析也各不相同。甚至有种越看越蒙的感觉…

因此分享下CAP原则的理解，主要指出了很多版本说法存在的问题。

当然，这是个人理解，如果有错。欢迎各位指出。

---

CAP原则

• 一致性Consistency : 访问所有节点，得到结果一致。（特别是更新操作完成后)

这里不采用"同一时刻"的说法，因为数据同步是需要时间的。关键是访问得到的数据一致

• 可用性Availability :

  客户端访问集群中任意一个节点，系统能在有限的时间内给出非错响应。

  这里有两种处理方案都是违反A的：

  1. 阻塞客户端直至超时
  2. 返回出错响应，提示其重试

  "得到"处理成功"的结果" 的说法也是一个意思，不过这个描述很容易让人误解为 “结果是对的”，所以也不采用。

• 分区容错性 Partition tolerance

  (有容错性、容忍性两种翻译，选择原因见下)

  部分节点故障，无法与其他节点通信，产生了网络分区。但系统仍能提供正常服务，除非整个网络都发生故障。

  常见故障：结点宕机、网络波动、Gc stop World，

  但因为只能根据time out判断，很难区分是哪种。

  这也是选择了容错性的原因：

  因为容忍性没有考虑到宕机的情况。

  正常服务：指提供满足**设计好的一致性和可用性**的服务。

  即系统原本是CP的，就仍然满足CP，AP同理。

  而不是某些翻译的：

  仍然能够保证对外提供满足一致性和可用性的服务，因为这本就是违反CAP三选二的。

  ---

  分界线，上面的内容基本没问题，下面的内容含个人理解比较多，可能有误。

  ---

  划重点：

  这里有一个容易混淆的点，就是高可用性（HA）不是由 A，而是由P来保证的。

  用下面要说的CA的单机应用为例，对CA的解释是：

  单个副本，自然没有一致性的问题。

  可用性方面，既然不需要同步到其他节点，自然也可以保证。

  A如定义，只要保证有限时间内回复即可，而宕机的处理是不考虑在内的。

  不要忘本了：单机应用，本就是不满足HA的，这也是为什么采用分布式系统的原因之一

  这里推荐阅读：为什么CAP理论在舍弃P的情况下，可以有完美的CA？

  ---

  最多同时满足两个特性，而分布式必须满足P

• CA : 非分布式系统，单个结点，可拓展性差。 eg : 传统数据库,oracle

• CP : 允许访问失效，因为系统等待期间不可用。

  可以返回一个出错信息给用户，提醒重试；或者什么也不返回，直到客户端超时。

  等到故障分区恢复，同步完成，才恢复服务。

  而维持C的是需要同步时间的，而且分区容错性的恢复时间不定，这种可能导致无限阻塞。

• AP ： 对一致性要求不高，但仍需保证最终一致性

  eg ：redis分布式集群，(大多数网站采用，因为可用性很影响用户体验)

---

关于redis的问题:

首先，集群redis肯定是不满足C的，毕竟主从复制时需要时间的，有疑问的可以看参考，redis中集群一致性问题。

但是对于单机redis属于哪种呢？

网上有资料说 Redis、Mongodb 属于CP。同时也在另一份资料中看到资料，更确定了是指单机Redis。（Mongodb笔者不熟悉不发表观点）。但按笔者的理解，应该是属于CA的，毕竟单机，又何谈P呢？

---

最后举个例子帮助理解：

eg :

• CP： 让Client A 的两个写操作同时失效，此时无法保证写操作的可用性
• AP：让对Server 1 的写操作生效，此时Client B、C读取数据不同

---

本文完。

推荐阅读：CAP理论中的P到底是个什么意思？