免费营销软件网站,山东大标网络,简单好玩的网页游戏,眉山网络推广CAP原理详解 前言CAP一张图 一、概念1.1 关键词解读1.2 关于CAP#xff08;拆分解读#xff09;1.3 CAP原理精髓 二、CAP模拟场景举例理解三、CAP原理证明为什么不能同时满足#xff08;下面举例说明#xff09;3.1 必须满足分区容错性P下的处理方式3.2 不是必须满足分区容… CAP原理详解 前言CAP一张图 一、概念1.1 关键词解读1.2 关于CAP拆分解读1.3 CAP原理精髓 二、CAP模拟场景举例理解三、CAP原理证明为什么不能同时满足下面举例说明3.1 必须满足分区容错性P下的处理方式3.2 不是必须满足分区容错性P3.3 总结 四、CAP取舍策略如何选择策略及应用CAP三个特性只能满足其中两个那么取舍的策略排列组合后也就共有三种CP、CA、AP4.1 CA无P4.2 CP无A4.3 AP无C4.4 总结 五、其他5.1 事务的ACID与分布式系统的CAP5.1.1 事务的ACID5.1.2 区别5.1.3 CAP 和 ACID 的“C、A”是一样的吗 5.2 关于BASE 理论5.2.1概念5.2.2 核心思想5.2.3 关于BASE 5.3 BASE理论和CAP原则的区别与联系5.4 CAP原则注意事项 六、总结 前言
CAP一张图
概述互联网最重要任务莫过于海量数据处理即大规模分布式系统分布式是互联网的核心技术
一、概念
CAP原则又称CAP原理指的是在一个分布式系统(指互相连接并共享数据的节点的集合中当涉及读写操作时只能保证一致性Consistency、可用性Availability、分区容错性Partition Tolerance三者中的两个另外一个必须被牺牲。 也就是说在分布式系统的设计中没有一种设计可以同时满足这3个特性要么CA要么CP要么AP
1.1 关键词解读
上述中我们提及了2个关键词 互联和共享数据的分布式系统CAP原则探讨的对象 分布式系统并不一定会互联和共享数据。 例如 Memcache 的集群相互之间就没有连接和共享数据因此 Memcache 集群这类分布式系统就不符合 CAP 理论探讨的对象而 MySQL 集群就是互联和进行数据复制的所以才是 CAP 理论探讨的对象。传统的关系型数据库DBMSOracle、MySQL都是CA。 数据读写 CAP 关注的是对数据的读写操作而不是分布式系统的所有功能。
1.2 关于CAP拆分解读 一致性C在分布式系统中的所有数据备份在同一时刻是否有同样的值即写操作之后的读操作必须返回该值。 注意这里的一致性指的是强一致性也就是数据更新完访问任何节点看到的数据完全一致要和弱一致性最终一致性区分开来。 高可用性A在集群中一部分节点故障后集群整体是否还能响应客户端的读写请求。对数据更新具备高可用性 分区容忍性P以实际效果而言分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性就意味着发生了分区的情况必须就当前操作在C和A之间做出选择。
1.3 CAP原理精髓
CAP原理的精髓就是一个数据分布式系统不可能同时满足C和A和P这3个条件。CAP理论提出就是针对分布式数据库环境的所以P这个属性必须容忍它的存在而且是必须具备的。 所以系统架构师在设计系统时不要将精力浪费在如何设计能满足三者的完美分布式系统而是应该进行取舍。由于网络的不可靠性大多数开源的分布式系统都会实现P也就是分区容忍性之后在C和A中做抉择。 二、CAP模拟场景举例理解
以电商环境为例
假设某电商公司在北京、杭州、上海三个城市建立了仓库同时建立了对应的服务器{A, B, C}用于存储商品信息。比如某电吹风在北京仓库有 20 个在杭州仓库有 10 个在上海仓库有 30 个。那么CAP 这三个字母在这个例子中分别代表什么呢 首先我们来看一下C。C 代表 Consistency一致性是指所有节点在同一时刻的数据是相同的即更新操作执行结束并响应用户完成后所有节点存储的数据会保持相同。在电商系统中A、B、C 中存储的该电吹风的数量应该是 20103060。假设现在有一个北京用户买走一个电吹风服务器 A 会更新数据为 60-159与此同时要求 B 和 C 也更新为 59以保证在同一时刻无论访问 A、B、C 中的哪个服务器得到的数据均是 59。 接着看一下 A。A 代表 Availability可用性是指系统提供的服务一直处于可用状态对于用户的请求可即时响应。在电商系统中用户在任一时刻向 A、B、C 中的任一服务器发出请求时均可得到即时响应比如查询商品信息等。 最后我们看一下 P。P 代表 Partition Tolerance分区容错性是指在分布式系统遇到网络分区的情况下仍然可以响应用户的请求。网络分区是指因为网络故障导致网络不连通不同节点分布在不同的子网络中各个子网络内网络正常。在电商系统中假设 C 与 A 和 B 的网络都不通了A 和 B 是相通的。也就是说形成了两个分区{A, B}和{C}在这种情况下系统仍能响应用户请求。 三、CAP原理证明
重温概念
CAP原则在分布式系统中 C一致性、A可用性、P分区容错性 这三个特征不能同时满足只能满足其中两个
为什么不能同时满足下面举例说明
如下图所示有两台服务器Server1、Server2它们分别部署了数据库 DB1 和 DB2这两台机器组成一个服务集群DB1 和 DB2 两个数据库中的数据要保持一致共同为用户提供服务。
用户 User1 可以向 Server1 发起查询数据的请求用户 User2 可以向服务器 Server2 发起查询数据的请求它们共同组成了一个分布式系统。 以此系统为例分别满足 C、A 和 P 指的是在满足一致性 C 的情况下Server1 和 Server2 中的数据库始终保持一致即 DB1 和 DB2 内容要始终保持相同在满足可用性 A 的情况下用户无论访问 Server1 还是 Server2都会得到即时响应在满足分区容错性 P 的情况下Server1 和 Server2 之间即使出现网络故障也不会影响 Server1 和 Server2 分别处理用户的请求。
当用户发起请求时收到请求的服务器会及时响应并将用户更新的数据同步到另一台服务器保证数据一致性。具体的工作流程如下图和流程所示在网络环境稳定、系统无故障的情况下的工作流程 用户 User1 向服务器 Server1 发起请求将数据库 DB1 中的数据 a 由 1 改为 2 系统会进行数据同步即图中的 S 操作将 Server1 中 DB1 的修改同步到服务器 Server2 中使得 DB2 中的数据 a 也被修改为 2 当 User2 向 Server2 发起读取数据 a 的请求时会得到 a 最新的数据值 2。 在实际场景中网络环境不可能百分之百不出故障比如网络拥塞、网卡故障等会导致网络故障或不通从而导致节点之间无法通信或者集群中节点被划分为多个分区分区中内的节点之间可通信分区之间不可通信。
3.1 必须满足分区容错性P下的处理方式
这种由网络故障导致的集群分区情况通常被称为“网络分区”。在分布式系统中网络分区不可避免因此分区容错性 P 必须满足。否则user1向server1已经做了更改而user2从server2请求的时候还是之前的数据所以一般来说分布式系统必须满足分区容错性P。
接下来我们就来讨论一下在满足分区容错性 P 的情况下一致性 C 和可用性 A 是否可以同时满足。
假设Server1 和 Server2 之间网络出现故障User1 向 Server1 发送请求将数据库 DB1 中的数据 a 由 1 修改为 2而 Server2 由于与 Server1 无法连接导致数据无法同步所以 DB2 中 a 依旧是 1。这时User2 向 Server2 发送读取数据 a 的请求时Server2 无法给用户返回最新数据那么该如何处理呢
这里阐述两种处理方式
第一种处理方式是保证一致性 C牺牲可用性 AServer2 选择让 User2 的请求阻塞一直等到网络恢复正常Server1 被修改的数据同步更新到 Server2 之后即 DB2 中数据 a 修改成最新值 2 后再给用户 User2 响应。 第二种处理方式是保证可用性 A牺牲一致性 CServer2 选择将旧的数据 a1 返回给用户等到网络恢复再进行数据同步。 -
总结 除了以上这两种方案没有其他方案可以选择。可以看出在满足分区容错性 P 的前提下一致性 C 和可用性 A 只能选择一个无法同时满足。
3.2 不是必须满足分区容错性P
还是上面的例子我们分3个场景分析 在保证C一致性和P分区容错性的情况下 为了保证数据一致性server1需要将数据复制给server2即server1和server2需要进行通信。但是由于网络是不可靠的我们系统又保证了分区容忍性也就是说这个系统是可以容忍网络的不可靠的。这时候server2就不一定能及时的收到server1的数据复制消息当有请求向server2访问a数据时为了保证数据的一致性server2只能阻塞等待数据真正同步完成后再返回这时候就没办法保证高可用性了。 所以在保证C和P的情况下是无法同时保证A的。 在保证A高可用性和P分区容错性的情况下 为了保证高可用性server1和server2都有在有限时间内返回。同样由于网络的不可靠在有限时间内server2有可能还没收到server1发来的数据更新消息这时候返回给客户端的可能是旧的数据和访问server1的数据是不一致的也就是违法了C一致性。 所以在保证A和P的情况下是无法同时保证C的。 在保证A高可用性和C一致性的情况下 如果要保证高可用和一致性只有在网络情况良好且可靠的情况下才能实现。这样server1才能立即将更新消息发送给server2。但是我们都知道网络是不可靠的是会存在丢包的情况的。所以要满足即时可靠更新只有将server1和server2放到一个区内才可以也就丧失了P分区容错性这个保证。其实这时候整个系统也不能算是一个分布式系统了。 所以在保证A和P的情况下是无法同时保证C的。
3.3 总结
如上所述分布式系统是无法同时满足CAP三个特性的。 四、CAP取舍策略如何选择策略及应用
CAP三个特性没有谁优谁劣只是在不同的分布式场景适用不同的策略而取舍策略就是帮助我们面对不同的分布式场景时知道如何权衡这三个特征 举例对于涉及钱的交易时数据的一致性至关重要因此保 CP 弃 A 应该是最佳选择。
而对于其他场景大多数情况下的做法是选择 AP 而牺牲 C强一致性因为很多情况下不需要太强的一致性数据始终保持一致只要满足最终一致性即可 最终一致性不要求集群中节点数据每时每刻保持一致在可接受的时间内最终能达到一致就可以了 强一致性任何一次读都能读到某个数据的最近一次写的数据即复制是同步的 弱一致性数据更新后如果能容忍后续的访问只能访问到部分或者全部访问不到则是弱一致性
注关于一致性的具体描述请参考这篇帖子
CAP三个特性只能满足其中两个那么取舍的策略排列组合后也就共有三种CP、CA、AP
4.1 CA无P
在分布式系统中现在的网络基础设施无法做到始终保持稳定网络分区网络不连通难以避免。牺牲分区容错性 P就相当于放弃使用分布式系统。因此在分布式系统中这种策略不需要过多讨论。
如果不要求P不允许分区则C强一致性和A可用性是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性也就是分布式节点受限没办法部署子节点这是违背分布式系统设计的初衷的。单点系统满足 CA 特性比如 关系型数据库 DBMS比如 MySQL、Oracle部署在单台机器上因为不存在网络通信问题所以保证 CA 就可以了。
4.2 CP无A
如果一个分布式场景需要很强的数据一致性或者该场景可以容忍系统长时间无响应的情况下保 CP 弃 A 这个策略就比较适合。
若不要求A高可用性相当于每个请求都需要在服务器之间保持强一致而P分区会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)一个保证 CP 而舍弃 A 的分布式系统一旦发生网络分区会导致数据无法同步情况就要牺牲系统的可用性降低用户体验直到节点数据达到一致后再响应用户。
设计成CP的系统其实不少最典型的就是分布式数据库如 Redis、HBase、ZooKeeper等。对于这些分布式数据库来说数据的一致性是最基本的要求。
4.3 AP无C
如果一个分布式场景需要很高的可用性A或者说在网络状况不太好的情况下该场景允许数据暂时不一致那这种情况下就可以牺牲一定的一致性C了。
目前采用保 AP 弃 C 的系统也有很多比如 CoachDB、Eureka、Cassandra、DynamoDB 等。
网络分区出现后各个节点之间数据无法马上同步为了保证高可用分布式系统需要即刻响应用户的请求。但此时可能某些节点还没有拿到最新数据只能将本地旧的数据返回给用户从而导致数据不一致的情况。
适合保证 AP 放弃 C 的场景有很多。比如很多查询网站、电商系统中的商品查询等用户体验非常重要所以大多会保证系统的可用性而牺牲一定的数据一致性。典型的应用就如抢购手机场景可能前几秒你浏览商品的时候页面提示是有库存的当你选择完商品准备下单的时候系统提示你下单失败商品已售完。 举例 假如上海的网络出现了问题与北京和杭州网络均不通此时北京的用户通过北京服务器 A 下单购买了一个电吹风电吹风数量减少到 59并且同步给了杭州服务器 B。也就是说现在用户的查询请求如果是提交到服务器 A 和 B那么查询到的数量为 59。但通过上海服务器 C 进行查询的结果却是 60。 待网络恢复后服务器 A 和 B 的数据会同步到 CC 更新数据为 59最终三台服务器数据保持一致用户刷新一下查询界面或重新提交一下查询就可以得到最新的数据。而对用户来说他们并不会感知到前后数据的差异到底是因为其他用户购买导致的还是因为网络故障导致数据不同步而产生的。 这其实就是先在 A可用性方面保证系统可以正常的服务然后在数据的一致性方面做了些牺牲虽然多少会影响一些用户体验但也不至于造成用户购物流程的严重阻塞因为如果等到数据一致之后再给用户返回的话用户的响应太慢可能会造成严重的用户流失。
4.4 总结 五、其他
5.1 事务的ACID与分布式系统的CAP
5.1.1 事务的ACID
1.Atomicity原子性 一个事务中的所有操作要么全部完成要么全部不完成不会在中间某个环节结束。事务在执行过程中发生错误会被回滚到事务开始前的状态就像这个事务从来没有执行过一样。
2.Consistency一致性 在事务开始之前和事务结束以后数据库的完整性没有被破坏。
3.Isolation隔离性 数据库允许多个并发事务同时对数据进行读写和修改的能力。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别包括读未提交Read uncommitted、读提交read committed、可重复读repeatable read和串行化Serializable。
4.Durability持久性 事务处理结束后对数据的修改就是永久的即便系统故障也不会丢失。
5.1.2 区别
可以看到ACID 中的 AAtomicity和 CAP 中的 AAvailability意义完全不同而 ACID 中的 C 和 CAP 中的 C 名称虽然都是一致性但含义也完全不一样。ACID 中的 C 是指数据库的数据完整性而 CAP 中的 C 是指分布式节点中的数据一致性。
ACID 的应用场景是数据库事务CAP 关注的是分布式系统数据读写
5.1.3 CAP 和 ACID 的“C、A”是一样的吗
首先我们看一下 CAP 中的 C 和 ACID 中的 C 是否一致。
CAP 中的 C 强调的是数据的一致性也就是集群中节点之间通过复制技术保证每个节点上的数据在同一时刻是相同的。ACID 中的 C 强调的是事务执行前后数据的完整性保持一致或满足完整性约束。也就是不管在什么时候不管并发事务有多少事务在分布式系统中的状态始终保持一致。总结事务中的一致性是指满足完整性约束条件CAP中的一致性是指读写一致性。
其次我们看一下 CAP 中的 A 和 ACID 中的 A。
CAP 中的 A 指的是可用性Availability也就是系统提供的服务一直处于可用状态即对于用户的请求可即时响应。ACID 中的 A 指的是原子性Atomicity强调的是事务要么执行成功要么执行失败。
因此CAP 和 ACID 中的“C”和“A”是不一样的不能混为一谈。
5.2 关于BASE 理论
BASE是对CAP中一致性C 和高可用性A权衡的结果
5.2.1概念
BASE是Basically Available基本可用、Soft state软状态和Eventually consistent最终一致性三个短语的简写
5.2.2 核心思想
核心思想即使无法做到强一致性Strong consistency但每个应用都可以根据自身的业务特点采用适当的方式来使系统达到最终一致性Eventual consistency。
5.2.3 关于BASE
1. Basically Available基本可用
基本可用是指分布式系统在出现不可预知故障的时候允许损失部分可用性但请注意这绝不等价于系统不可用以下两个就是“基本可用”的典型例子
响应时间上的损失正常情况下一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果但由于出现异常比如系统部分机房发生断电或断网故障查询结果的响应时间增加到了1~2秒。功能上的损失正常情况下在一个电子商务网站上进行购物消费者几乎能够顺利地完成每一笔订单但是在一些节日大促购物高峰的时候由于消费者的购物行为激增为了保护购物系统的稳定性部分消费者可能会被引导到一个降级页面。
2. Soft state软状态
软状态也称弱状态和硬状态相对是指允许系统中的数据存在中间状态并认为该中间状态的存在不会影响系统的整体可用性即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
3. Eventually consistent最终一致性
最终一致性强调的是系统中所有的数据副本在经过一段时间的同步后最终能够达到一个一致的状态。
最终一致性的本质是需要系统保证最终数据能够达到一致而不需要实时保证系统数据的强一致性。
5.3 BASE理论和CAP原则的区别与联系
BASE 理论本质上是对 CAP 的延伸和补充更具体地说是对 CAP 中 AP 方案的一个补充。是对一致性C 和高可用性A权衡的结果
前面在剖析 CAP 理论时提到了其实和 BASE 相关的两点 CAP 理论是忽略延时的而实际应用中延时是无法避免的。 这一点就意味着完美的 CP 场景是不存在的即使是几毫秒的数据复制延迟在这几毫秒时间间隔内系统是不符合 CP 要求的。因此 CAP 中的 CP 方案实际上也是实现了最终一致性只是“一定时间”是指几毫秒而已。 AP 方案中牺牲一致性只是指分区期间而不是永远放弃一致性。 这一点其实就是 BASE 理论延伸的地方分区期间牺牲一致性但分区故障恢复后系统应该达到最终一致性。
综合上面的分析ACID 是数据库事务完整性的理论CAP 是分布式系统设计理论BASE 是 CAP 理论中 AP 方案的延伸。
5.4 CAP原则注意事项 CAP关注的粒度是数据对数据的读写操作而不是整个系统 CAP取舍策略不是一成不变的在 CAP 理论落地实践时我们需要将系统内的数据按照不同的应用场景和要求进行分类每类数据选择不同的策略CP 还是 AP而不是直接限定整个系统所有数据都是同一策略。 CAP 是忽略网络延迟的。 当事务提交时数据能够瞬间复制到所有节点。但实际情况下从节点 A 复制数据到节点 B总是需要花费一定时间的。如果是跨地域的机房例如北京机房同步到广州机房耗费的时间就可能是几十毫秒。这就意味着CAP 理论中的 C 在实践中是不可能完美实现的在数据复制的过程中节点 A 和节点 B 的数据并不一致。 取舍放弃并不等于什么都不做需要为分区恢复后做准备 CAP 理论告诉我们三者只能取两个需要“牺牲”另外一个这里的“牺牲”是有一定误导作用的因为“牺牲”让很多人理解成什么都不做。实际上CAP 理论的“牺牲”只是说在分区过程中我们无法保证 C 或者 A但并不意味着什么都不做。因为在系统整个运行周期中大部分时间都是正常的发生分区现象的时间并不长。例如99.99% 可用性俗称 4 个 9的系统一年运行下来不可用的时间只有 50 分钟99.999%俗称 5 个 9可用性的系统一年运行下来不可用的时间只有 5 分钟。分区期间放弃 C 或者 A并不意味着永远放弃 C 和 A我们可以在分区期间进行一些操作从而让分区故障解决后系统能够重新达到 CA 的状态。
六、总结
CAP顺口溜三者不可共存通常选AP
C要求数据完全一致A要求返回及时P要求分布式和数据同步 一致性高可用性低 一致性低可用性高 取舍策略 CA - 单点集群满足一致性可用性的系统通常在可扩展性上不太强大。 CP - 满足一致性分区容忍性的系统通常性能不是特别高。 AP - 满足可用性分区容忍性的系统通常可能对一致性要求低一些。
