CAP、BASE和ACID解析

什么是CAP、BASE和ACID及其关系

1 目的

这3个原则提出的目的：在分布式系统中，为了容错，会对数据复制多份副本，也可以提高可用性和读写并发。但由此引入多副本的数据一致性问题。怎么设计系统，在合适的场景中让客户端读取到最合适的数据？CAP，BASE和ACID是该问题的三大基本原则。本文将介绍这3个原则，并对其进行区分。

2. CAP

• CAP分别指Consistency、Availability和Partition Tolerance
  • Consistency：不管访问哪个节点，系统给客户端返回的都是绝对一致的最新写入的数据，要么读取失败。强调数据正确
  • Availability：任何来自客户端的请求，不管访问哪个非故障节点，都能得到响应数据，但不保证是同一份最新数据。强调服务可用，但数据不一定正确
  • Partition Tolerance：不管系统内部出现什么样的数据同步问题，系统都会一直运行
• CAP不可能三角：CAP只能满足其中两个。
• 系统不能停止运行，因此需要保证P。也就是说，只能选择如下两种情况
  • CP：客户端一定会读到最新的数据或者收到失败信息，不会读到旧数据。如果因为消息丢失、延迟过高发生了网络分区，此时当集群节点接收到来自客户端的读请求时，为了不破坏一致性，可能会因为无法响应最新数据，而返回出错信息（对于客户端来说，系统返回了出错信息，表示不可用了）
    • 代表：基于Raft的系统。Etcd，Consul和HBase
  • AP：系统会给客户端返回数据，不会返回出错，但返回的数据不一定保证是最新数据
    • 代表：Eureka、Cassandra

3. ACID

• 分别指原子性Atomicity、一致性Consistency、隔离性Isolation、持久性durability。其中一致性Consistency是目的，其他三者为实现一致性的手段。

• ACID强调的是事务一致性，关注的是多对象、多操作在单副本上的一致性（强调多事务）。CAP强调的是单对象、单操作在多副本上的一致性（强调多副本）

• 实现原子性和持久性的方法：

  • 问题：写入磁盘这个操作不是原子的，存在“正在写”的状态，如果此时恰巧发生Crash，后面如何进行恢复，使得数据是正确的？
  • 方法
    • Commit Logging
      • 对于数据的修改操作，以日志的形式记录到磁盘。崩溃重启后根据日志重新恢复。
      • 缺点：性能低。所有对数据的真实修改都必须发生在事务提交、日志写入了 Commit Record 之后，即使事务提交前磁盘 I/O 有足够空闲、即使某个事务修改的数据量非常庞大，占用大量的内存缓冲，无论何种理由，都决不允许在事务提交之前就开始修改磁盘上的数据，这一点对提升数据库的性能是很不利的
    • Write-Ahead Logging
      • 允许在事务提交之前，提前写入变动数据，相关日志技术有Redo Log和Undo Log。

• 实现隔离性的方法：

  • 隔离级别：

    • READ UNCOMMITTED（读未提交）
      在RED UNCOMMITTED级别，事务中的修改，即使没提交，对其他事务也是可见的。事务可以读取未提交的数据，这被称为“脏读”（Dirty Read），因为读取的很可能是中间过程的脏数据，而不是最终数据。

    • READ COMMITTED（读已提交）
      大多数数据库系统默认的隔离级别都是RED COMMITTED，但是MYSQL不是。RED COMMITTED说的是，一个事务只能读到其他事务已经提交的数据，所以叫提交读。这个事务级别也叫做不可重复读（nonrepeatableread），因为两次同样的查询，可能会得到不同的结果。

    • REPEATABLE READ（可重复读）
      REPEATABLE READ解决了脏读的问题。该级别保证了在同一事务中多次读取同样的记录结果是一致的。但是无法解决幻读的问题，所谓幻读，指的是当某个事务再读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围内的记录时，发现多了一行，会产生幻行。

    • SERIALIZABLE（可串行化）
      SERIALIZABLE是最高级别的隔离。它通过强制事务串行执行，避免了前面说的幻读的问题。简单来说，SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。

    • MVCC是一种读取优化策略，它在读取时不需要加锁的情况下，实现了提交读和可重复读的隔离级别。
      可重复读：总是读在事务启动前就已经提交完成的数据。

  • 实现隔离的方法：对锁的运用

    • 可串行化：读锁+写锁+范围锁
    • 可重复读：读锁+写锁
    • 读已提交：写锁+读完就释放的读锁

4 BASE

• 基本可用（Basically Available）、软状态（Soft state）和最终一致性（Eventually consistent）
• CAP 理论中，分布式系统中要实现强一致性必然会影响可用性。比如，在采用两阶段提交协议的集群系统中，因为执行提交操作，需要所有节点确认和投票。
• 基本可用的实现方法：流量削峰、延迟响应、体验降级、过载保护
• 最终一致性：能容忍短暂的一致性的延迟
  • 实现方法：
    • 读时修复
    • 写时修复
    • 异步修复（定时）

5 三者的区别

• CAP和ACID的区别
  • ACID强调的是事务一致性，关注的是多对象、多操作在单副本上的一致性（强调多事务）。CAP强调的是单对象、单操作在多副本上的一致性（强调多副本数据一致性）
• ACID和BASE的区别
  • ACID 理论是传统数据库常用的设计理念，追求强一致性模型。BASE 理论支持的是大型分布式系统，通过牺牲强一致性获得高可用性。BASE 理论在很大程度上，解决了事务型系统在性能、容错、可用性等方面痛点。BASE 理论在 NoSQL 中应用广泛，是 NoSQL 系统设计的事实上的理论支撑。
• CAP和BASE的区别
  • CAP 理论中，分布式系统中要实现强一致性必然会影响可用性。比如，在采用两阶段提交协议的集群系统中，因为执行提交操作，需要所有节点确认和投票。BASE则是在可用性和一致性上进行折中，采用基本可用和最终一致性。