架构设计 3-高可用架构之CAP理论
扫描左侧二维码 关注公众号 回复 “架构设计” 获取架构设计笔记完整思维导图
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 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。具有如下特点：
- 基本可用（Basically Available）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
- 软状态（Soft State）：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。
- 最终一致性（Eventual Consistency）：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
与 CAP 区别
BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。
- AP 方案中牺牲一致性只是指分区期间，而不是永远放弃一致性。
- CAP 理论是忽略延时的，而实际应用中延时是无法避免的。