论 在单机的数据库系统之中，我们很容易实现一套满足ACID 特性的 事务处理系统， 事务的一致性不存在问题。 但是在分布式系统之中，由于数据分布在不同的主机结点上，如何对着些数据进行分布式的事务处理就具有非常大的挑战，CAP 理论的出现，让我们对于分布式事务的一致性有了另外一种看法。 什么是CAP 理论？ 在计算机科学理论，CAP 理论 （也称Brewer 定理） 又有称为 CAP原则，CAP定理，是由计算机科学家Eric Brewer 在 2000 年 提出的 ，其理论观点是， 在分布式计算机系统中，不可能存在同时提供 以下全部三个保证。 Consistency（一致性）： 所有节点同一时间看到的是相同的数据。在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） Availability（可用性）：不管是否成功，确保每一个请求都能接收到响应。在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） Partition tolerance（分区容错性）：系统任意分区后，在网络故障时，仍能操作。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 　　 CAP原则是NOSQL数据库和分布式系统的基石。 为什么说CAP 只能三选二？ 举个栗子： 下图 显示了在一个网络中,N1，N2 是两个节点，他们共享数据块V 其中一个 值V0， 运行在N1 的A 程序可以认为是安全的，无Bug，可预测的和可靠的，运行在N2 的是B 程序，在这个例子中，A 将写入V的新值。而B从V 中读取值。 系统预期执行下面的操作： 写入一个V 的新值 V1 。 然后消息（M） 从N1 更新V 的副本到N2. 从B 处读取返回的V1 如果网络是分区的，当N1到N2 的消息不能传递的时候，就会出现虽然N2 能访问到V 的值（可用性），但是实际上与N1 的V 值已经不一致了。 如下图： CAP 常见模型： 既然 CAP 理论已经证明一致性，可用性和分区容错性三者不可能通知达成。 那么在实际应用中，我们可在其他某一方面来放松条件，从而达到妥协，下面是一些常用的模型。 牺牲分区 (CA 模型) 牺牲分区容错性意味着把所有机器搬到一台机器内部，或者放到一个“要死一起上死”的机架上面（机架也可能出现部分失效），这明显就违背了我们希望的可伸缩性。 常见例子: 单站点数据库 集群数据库 LDAP xFS 文件系统 实现方式： 两阶段提交， 缓存验证协议。 2. 牺牲可用性(CP 模型） 牺牲可用性意味着一旦系统出现分区这样的错误， 系统就直接停止服务。 常见例子： 分布式数据库 分布式锁定 绝大部分协议 实现方式： 悲观锁， 少数分区不可用。 3 . 牺牲一致性（AP 模型） 常见例子： Coda Web缓存 DNS 实现方式： 到期/租赁， 解决冲突， 乐观。 CAP 的意义： 在系统架构时，应该是根据具体的业务场景来权衡CAP， 比如 对于大多数互联网应用来说（如门户网站），因为 机器数量庞大，部署结点分散，网络故障是常态的，所以可用性是必须的所以只有舍弃一致性来保证服务的AP 而对于银行等需要确保一致性的场景，通常会权衡CA， 和CP 模型。 CAP 的最新发展： Eric Brewer 在2012 年发表文章指出了CAP里面三选二的做法存在一定的误差性，主要体现在： 由于分区很少发生，那么在系统中不存在分区的情况下，没有什么理由牺牲C或A 。 C与A 之间的取舍可以在同一系统内以非常细小的粒度反复发生，而每一次的决策可能因为具体的操作，乃至因为牵涉特定的数据或用户而有所不同。 这三种性质都可以在一定程度上衡量，并不是非黑即白的有或无。可用性显然是在0% 到100% 之间连续变化的，一致性分很多级别，连分区也可以细分不同的含义，如系统内的不同部分对于是否存在分区可以有不一样的认知。 理解CAP 理论最简单的方式 是想象两个节点分处于分区两侧，允许至少一个节点更新状态会导致数据不一致，即丧失了C 性质，如果为了保证数据的一致性，将分区一侧的节点设置为不可用， 那就丧失了A 性质，除非两个节点可以相互通讯，才能既保证A 又保证C ，但这又会丧失P 性质，一般来说 跨区域的系统，设计师无法舍弃P 性质，那么就只能在数据一致性和可用性上做一个艰难选择， 不确切的说，NoSQL 运动的主题其实是创造各种可用性优先，数据一致性其次的方案，而传统数据库坚守ACID 特性，做的是相反的事情。 BASE ： BASE 来自于互联网的电子商务领域的实践，它是基于CAP 理论逐步演化而来的，核心思想是即便不能达到强一致性，但可以根据应用特点采用适当的方式来达到最终一致性的效果。BASE 是对CAP 中C和A 的延伸。 其含义如下 ： Basically Available 基本可用 Soft state 软状态/柔性事务，即状态可以有一段时间的不同步。 Eventual consistency 最终一致性。 __EOF__ 作　　者：TheLovelyBugFly 出　　处：https://www.cnblogs.com/thelovelybugfly/p/9852055.html 关于博主：编程路上的小学生，热爱技术，喜欢专研。评论和私信会在第一时间回复。或者直接私信我。 版权声明：署名 - 非商业性使用 - 禁止演绎，协议普通文本 | 协议法律文本。 声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！ 个人能力所限，不足之处，还请多多指教。 分类: 分布式 标签: CAP 好文要顶 关注我 收藏该文 thelovelybugfly 关注 - 4 粉丝 - 1 +加关注 2 0 « 上一篇：日期时间处理类 posted @ 2018-10-25 19:25 thelovelybugfly 阅读(141) 评论(0) 编辑 收藏 刷新评论刷新页面返回顶部 注册用户登录后才能发表评论，请 登录 或 注册，访问网站首页。 MENUhttps://www.cnblogs.com/thelovelybugfly/p/9852055.html