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