概述
本来觉得CAP原则挺简单的，但一搜网上一大堆，翻译的版本不一，对概念的解析也各不相同。甚至有种越看越蒙的感觉…
因此分享下CAP原则的理解，主要指出了很多版本说法存在的问题。
当然，这是个人理解，如果有错。欢迎各位指出。
CAP原则
- 一致性Consistency : 访问所有节点，得到结果一致。（特别是更新操作完成后)
这里不采用"同一时刻"的说法，因为数据同步是需要时间的。关键是访问得到的数据一致
-
可用性Availability :
客户端访问集群中任意一个节点，系统能在有限的时间内给出非错响应。
这里有两种处理方案都是违反A的：
- 阻塞客户端直至超时
- 返回出错响应，提示其重试
"得到"处理成功"的结果"的说法也是一个意思，不过这个描述很容易让人误解为 “结果是对的”，所以也不采用。 -
分区容错性 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到底是个什么意思？
最后
以上就是谨慎苗条为你收集整理的CAP原则“大总结“及单机集群redis的所属的全部内容，希望文章能够帮你解决CAP原则“大总结“及单机集群redis的所属所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复