架构设计 3-高可用架构之CAP理论架构设计

【架构设计 3-高可用架构之CAP理论】导读：《架构设计》系列为极客时间李运华老师《从0开始学架构》课程笔记。本文为第三部分，主要介绍分布式系统中的 CAP 理论以及相关的 ACID 理论和 BASE理论。对分布式系统架构有一个理论上的感知。
CAP 理论在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。

P 分区容忍性（Partition Tolerance）：当出现网络分区后，系统能够继续“履行职责”
A 可用性（Availability）：非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）
C 一致性（Consistency）：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果

CAP 特点：

分布式系统并不一定会互联和共享数据
CAP 关注的是对数据的读写操作，而不是分布式系统的所有功能

CAP 应用

CP - Consistency/Partition Tolerance
AP - Availability/Partition Tolerance

一些细节 CAP 关注的粒度是数据，而不是整个系统

在实际设计过程中，每个系统不可能只处理一种数据，而是包含多种类型的数据，有的数据必须选择 CP，有的数据必须选择 AP。
。但在实际设计过程中，每个系统不可能只处理一种数据，而是包含多种类型的数据，有的数据必须选择 CP，有的数据必须选择 AP。

CAP 是忽略网络延迟的
CAP 理论中的 C 在实践中是不可能完美实现的，在数据复制的过程中，节点 A 和节点 B 的数据并不一致。
正常运行情况下，不存在 CP 和 AP 的选择，可以同时满足 CA

CAP 理论告诉我们分布式系统只能选择 CP 或者 AP，但其实这里的前提是系统发生了“分区”现象。
架构设计的时候既要考虑分区发生时选择 CP 还是 AP，也要考虑分区没有发生时如何保证 CA

放弃并不等于什么都不做，需要为分区恢复后做准备

最典型的就是在分区期间记录一些日志，当分区故障解决后，系统根据日志进行数据恢复，使得重新达到 CA 状态。
分区期间放弃 C 或者 A，并不意味着永远放弃 C 和 A，我们可以在分区期间进行一些操作，从而让分区故障解决后，系统能够重新达到 CA 的状态。

ACID ACID 是数据库管理系统为了保证事务的正确性而提出来的一个理论：

Atomicity（原子性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会在中间某个环节结束
Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏
Isolation（隔离性）：数据库允许多个并发事务同时对数据进行读写和修改的能力。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

与 CAP 区别

ACID 中的 C 是指数据库的数据完整性，而 CAP 中的 C 是指分布式节点中的数据一致性
ACID 的应用场景是数据库事务，CAP 关注的是分布式系统数据读写
ACID 中的 A（Atomicity）和 CAP 中的 A（Availability）意义完全不同

这里需要补充一点，上述理解可以认为是将 ACID 限制在单机事务。如果放在分布式场景，ACID 特性理解为 CAP 中一致性的边界，最强的一致性。但这需要一些分布式协议来支持，如：二阶段提交协议，TCC协议等。
BASE 核心思想：即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。具有如下特点：