| title | date | order | categories | tags | permalink | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
CAP 和 BASE |
2021-11-08 00:15:33 -0800 |
3 |
|
|
/pages/1c5cc28c/ |
一致性（Consistency）指的是多个数据副本是否能保持一致的特性。
在一致性的条件下，分布式系统在执行写操作成功后，如果所有用户都能够读取到最新的值，该系统就被认为具有强一致性。
数据一致性又可以分为以下几点：
- 强一致性 - 数据更新操作结果和操作响应总是一致的，即操作响应通知更新失败，那么数据一定没有被更新，而不是处于不确定状态。
- 弱一致性 - 系统在写入数据成功后，不承诺立即能读到最新的值，也不承诺什么时候能读到，但是过一段时间之后用户可以看到更新后的值。那么用户读不到最新数据的这段时间被称为“不一致窗口时间”。
- 最终一致性 - 最终一致性作为弱一致性中的特例，强调的是所有数据副本，在经过一段时间的同步后，最终能够到达一致的状态，不需要实时保证系统数据的强一致性。
ACID 是数据库事务正确执行的四个基本要素的单词缩写：
- 原子性（Atomicity）
- 原子是指不可分解为更小粒度的东西。事务的原子性意味着：事务中的所有操作要么全部成功，要么全部失败。
- 回滚可以用日志来实现，日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。
- 一致性（Consistency）
- 数据库在事务执行前后都保持一致性状态。
- 在一致性状态下，所有事务对一个数据的读取结果都是相同的。
- 隔离性（Isolation）
- 同时运行的事务互不干扰。换句话说，一个事务所做的修改在最终提交以前，对其它事务是不可见的。
- 持久性（Durability）
- 一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。
- 可以通过数据库备份和恢复来实现，在系统发生奔溃时，使用备份的数据库进行数据恢复。
一个支持事务（Transaction）中的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性。
- 只有满足一致性，事务的执行结果才是正确的。
- 在无并发的情况下，事务串行执行，隔离性一定能够满足。此时只要能满足原子性，就一定能满足一致性。
- 在并发的情况下，多个事务并行执行，事务不仅要满足原子性，还需要满足隔离性，才能满足一致性。
- 事务满足持久化是为了能应对系统崩溃的情况。
1998 年，Brewer 提出了分布式系统领域大名鼎鼎的 CAP 定理。
CAP 定理提出：分布式系统有三个指标，这三个指标不能同时做到：
- 一致性（Consistency） - 在任何给定时间，网络中的所有节点都具有完全相同（最近）的值。
- 可用性（Availability） - 对网络的每个请求都会收到响应，但不能保证返回的数据是最新的。
- 分区容错性（Partition Tolerance） - 即使任意数量的节点出现故障，网络仍会继续运行。
CAP 就是取 Consistency、Availability、Partition Tolerance 的首字母而命名。
在分布式系统中，分区容错性是一个既定的事实：因为分布式系统总会出现各种各样的问题，如由于网络原因而导致节点失联；发生机器故障；机器重启或升级等等。因此，CAP 定理实际上是要在可用性（A）和一致性（C）之间做权衡。
对网络的每个请求都会收到响应，即使由于网络分区（故障节点）而无法保证数据一定是最新的。
选择 AP 模式，偏向于保证服务的高可用性。用户访问系统的时候，都能得到响应数据，不会出现响应错误；但是，当出现分区故障时，相同的读操作，访问不同的节点，得到响应数据可能不一样。
如果由于网络分区（故障节点）而无法保证特定信息是最新的，则系统将返回错误或超时。
选择 CP 模式，一旦因为消息丢失、延迟过高发生了网络分区，就会影响用户的体验和业务的可用性。因为为了防止数据不一致，系统将拒绝新数据的写入。
CAP 定理在分布式系统设计中，可以被应用与哪些方面？
一个最具代表性的问题是：服务注册中心应该选择 AP 还是 CP？
在微服务架构下，服务注册和服务发现机制中主要有三种角色：
- 服务提供者（RPC Server / Provider）
- 服务消费者（RPC Client / Consumer）
- 服务注册中心（Registry）
注册中心负责协调服务注册和服务发现，显然它是核心中的核心。主流的注册中心有很多，如：ZooKeeper、Nacos、Eureka、Consul、etcd 等。在针对注册中心进行技术选型时，其 CAP 设计也是一个比较的维度。
- CP 模型 - 代表有：ZooKeeper、etcd。系统强调数据的一致性，当数据一致性无法保证时（如：正在选举主节点），系统拒绝请求。
- AP 模型 - 代表有：Nacos、Eureka。系统强调可用性，牺牲一定的一致性（即服务节点上的数据不保证是最新的），来保证整体服务可用。
对于服务注册中心而言，即使不同节点保存的服务注册信息存在差异，也不会造成灾难性的后果，仅仅是信息滞后而已。但是，如果为了追求数据一致性，使得服务发现短时间内不可用，负面影响更严重。
所以，对于服务注册中心而言，可用性比一致性更重要，所以应该选择 AP 模型。
CAP 定理在分布式系统领域大名鼎鼎，以至于被很多人视为了真理。然而，CAP 定理真的正确吗？
网络分区是一种故障，不管喜欢还是不喜欢，它都可能发生，所以无法选择或逃避分区的问题。在网络正常的时候，系统可以同时保证一致性（线性化）和可用性。而一旦发生了网络故障，必须要么选择一致性，要么选择可用性。因此，对 CAP 更准确的理解应该是：当发生网络分区（P）的情况下，可用性（A）和一致性（C）二者只能选其一。
CAP 定理所描述的模型实际上局限性很大，它只考虑了一种一致性模型和一种故障（网络分区故障），而没有考虑网络延迟、节点失效等情况。因此，它对于指导一个具体的分布式系统设计来说，没有太大的实际价值。
值得一提的是，在 CAP 定理提出十二年之后，其提出者也发表了一篇文章 CAP Twelve Years Later: How the “Rules” Have Changed，来阐述 CAP 定理的局限性。
BASE 是 基本可用（Basically Available）、软状态（Soft State） 和 最终一致性（Eventually Consistent） 三个短语的缩写。BASE 定理是对 CAP 定理中可用性（A）和一致性（C）权衡的结果。
BASE 定理的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
- 基本可用（Basically Available） - 分布式系统在出现故障的时候，保证核心可用，允许损失部分可用性。例如，电商在做促销时，为了保证购物系统的稳定性，部分消费者可能会被引导到一个降级的页面。
- 软状态（Soft State） - 指允许系统中的数据存在中间状态，并认为该中间状态不会影响系统整体可用性，即允许系统不同节点的数据副本之间进行同步的过程存在延时。
- 最终一致性（Eventually Consistent） - 强调的是所有数据副本，在经过一段时间的同步后，最终能够到达一致的状态，不需要实时保证系统数据的强一致性。
BASE 定理的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
ACID 要求强一致性，通常运用在传统的数据库系统上。而 BASE 要求最终一致性，通过牺牲强一致性来达到可用性，通常运用在大型分布式系统中。
在实际的分布式场景中，不同业务单元和组件对一致性的要求是不同的，因此 ACID 和 BASE 往往会结合在一起使用。
- Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services，解读 - 经典的 CAP 定理，即：在一个分布式系统中，当发生网络分区时，那么强一致性和可用性只能二选一。
- CAP Twelve Years Later: How the “Rules” Have Changed, 解读 - CAP 定理的新解读，并阐述 CAP 定理的一些常见误区。
- BASE: An Acid Alternative，译文 - BASE 定理是对 CAP 中一致性和可用性的权衡，提出采用适当的方式来使系统达到最终一致性。