郑州大学网页设计与网站建设,深圳住建局官网登录入口,深圳中国电信网站备案,徐汇网站制作设计导航引言一、CAP 原则1.1 Consistency 一致性1.2 Available 可用性1.3 Partition tolerance 分区容错性1.4 CAP 的矛盾1.5 CAP 的组合场景二、BASE 理论2.1 基本可用2.2 软状态2.3 最终一致性2.3.1 因果一致性2.3.2 读自身所写2.3.3 会话一致性2.3.4 单调读一致性2.3.5 单调写一…
导航引言一、CAP 原则1.1 Consistency 一致性1.2 Available 可用性1.3 Partition tolerance 分区容错性1.4 CAP 的矛盾1.5 CAP 的组合场景二、BASE 理论2.1 基本可用2.2 软状态2.3 最终一致性2.3.1 因果一致性2.3.2 读自身所写2.3.3 会话一致性2.3.4 单调读一致性2.3.5 单调写一致性总结引言
本文介绍CAP原则和BASE理论。二者是分布式系统中重要的参考原则及指导方针。
其中 CAP 是由加州大学的计算机科学家 Eric Brewer 于1998 年提出代表了分布式系统的三个重要指标。
一、CAP 原则
CAP 是 Consistency 、Availability、Partition tolerance 的首字母缩写。所谓CAP原则简单的说就是不可能存在CAP即如下图所示CAP 三个指标只能实现其中两个而永远无法三者兼具。
1.1 Consistency 一致性
在系统中的所有数据备份在同一时刻要保持同样的值。
1.2 Available 可用性
在集群系统中一部分节点故障后集群整体依然可以响应外界请求。
简单来说只要用户发起请求系统就必须及时响应。响应的越快可用性越好。
1.3 Partition tolerance 分区容错性
分区指的是分布式系统中的多个网络节点之间无法通信导致分布在不同网络中的应用无法访问“失联的”数据。
解决分区问题的最好办法就是给数据备份备份在不同的网络中这样当网络通信出现故障就会降低数据访问不到的风险提高了分区容错性。
1.4 CAP 的矛盾
一般来说分区问题无法避免只能采用备份数据的方式尽可能提高分区容错性。因此可以认为 CAP 中的 P 总是要具备的。CAP 原则告诉我们剩下的 C 和 A 无法兼得。
简单来说为了提高分区容错性数据的备份是必要的备份的数量越多容错性越好但备份的越多保证一致性就越困难也势必就影响系统整体的响应速度可用性。
但是根据不同的业务场景CAP 三者可以达到一种平衡关系。
1.5 CAP 的组合场景
CA不允许分区的组合方式舍弃了分区容错性。则 C 一致性和 A可用性可以保证。但放弃 P 的同时也意味着放弃了系统扩展性即限制分布式节点这违背了分布式系统设计的初衷。满足CA 组合的系统例如传统的单体应用。CP不要求 A可用性相当于数据需要保证较强的一致性。而 P 分区会导致系统响应时间的延长一旦发生网络故障或消息丢失等情况就要牺牲用户体验。最典型的就是分布式系统如传统数据库 MySQL各种金融业务场景也需要优先保证CP指标也可以算作是CP组合。AP放弃一致性追求更高的系统响应。一旦分区发生节点之间的数据无法保持一致为了高可用每个节点只能使用本地数据提供服务。最典型的场景就是电商系统同一个商品可能前一秒还库存充足但秒杀一开始刚准备下单就提示下单失败商品已售完。Redis也是一种AP分布式结构。
二、BASE 理论
BASE 是 Basically Available基本可用、Soft state软状态、Eventually Consistent最终一致性三个短语的缩写。
BASE 是对大规模互联网分布式系统的实践结论是对 CAP 中 C 一致性 和 A 可用性的权衡策略。 其核心思想是即使无法做到强一致性但每个应用都可以根据自身业务特点采用适当的方式来使系统达到最终一致性。
2.1 基本可用
基本可用指的是当系统出现故障部分节点无法正常工作可以允许牺牲一定程度的用户体验但绝不允许系统完全不可用。
响应时间正常情况一个在线搜索引擎需要 0.5 秒内返回查询结果但由于出现异常查询时间增加到 1 ~ 2 秒。功能正常情况在一个电商系统购物消费者几乎可以顺利完成每一笔订单但是由于异常或消费者数量激增为了保证系统的稳定性部分消费者可能会被引导到一个降级页面。
2.2 软状态
什么是软状态呢相对于原子性而言要求多个节点的数据副本都是一致的这是一种“硬状态”。
软状态指的是允许系统中的数据存在中间状态并认为该状态不影响系统的整体可用性即允许系统在多个不同节点的数据副本存在数据延迟。
2.3 最终一致性
软状态允许数据备份延迟但最终这些数据都要保证一致性。这就是最终一致性。
最终一致性在软状态上加了一个时限这个时限取决于网络延时、系统负载、数据复制方案设计等。根据实际的业务场景最终一致性可被分为以下 5 种。
2.3.1 因果一致性
有果必有因。收到数据更新通知的节点应该使用更新后的新值即种下什么因就得什么果。
例如服务A更新了一个数据后通知给了服务B那么服务B如果要操作这个数据应该使用 A 更新后的新值。如果 C 和 A没有这种关系那么可以不受这一条件的限制。
2.3.2 读自身所写
自身写入的新值之后读取也应该是这个新值。这是一种特殊的因果一致性。
2.3.3 会话一致性
会话一致性将对系统数据的访问过程框定在了一个会话当中系统能保证在同一个有效的会话中实现“读自身所写”的一致性也就是说执行更新操作之后客户端能够在同一个会话中始终读取到该数据项的最新值。
2.3.4 单调读一致性
单调读一致性是指如果一个节点从系统中读取出一个数据项的某个值后那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
2.3.5 单调写一致性
单调写一致性是指一个系统要能够保证来自同一个节点的写操作被顺序的执行。 在实践中这5种一致性往往会结合使用以构建一个具有最终一致性的分布式系统 总结
CAP 原则分布式系统参考的三个重要指标。具体是指 Consistency 一致性、Availability 可用性、Partition tolerance 分区容错性。
CAP 原则指出在一个分布式系统中不可能同时满足三者而分区容错性一般是必须具备的重要指标这也是分布式系统的初衷因此实际的业务架构设计中往往都是对 C 一致性 和 A 可用性的权衡和取舍。
三种类型组合的常见案例 1、CA 破坏了分布式系统的设计初衷单体应用。 2、CP 传统数据库如 MySQL、各种涉及到银行、金融的交易系统。要求较高的一致性舍弃用户体验。 3、AP 电商系统秒杀等业务场景。但数据会实现最终一致性追求用户体验的响应性舍弃一部分实时的一致性如 Redis 。 BASE 理论是对CAP实践的进一步指导方针。是基本可用、软状态、最终一致性三个英文单词的缩写。
基本可用顾名思义即系统允许牺牲一部分用户体验但决不允许系统无法响应甚至崩溃。
软状态允许系统中的备份数据存在中间状态但也必须是不影响整体系统功能的前提下即数据备份允许延迟。
最终一致性在软状态之上增加了时限要努力达到数据最终是一致的。5 种最终一致性因果、读自写、会话、单调读、单调写。
