导航
- 引言
- 一、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 种最终一致性:因果、读自写、会话、单调读、单调写。
创作挑战赛新人创作奖励来咯,坚持创作打卡瓜分现金大奖