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

jiezi

3 年前

导读：《架构设计》系列为极客工夫李运华老师《从 0 开始学架构》课程笔记。本文为第三局部，次要介绍分布式系统中的 CAP 实践以及相干的 ACID 实践和 BASE 实践。对分布式系统架构有一个实践上的感知。

在一个分布式系统（指相互连贯并共享数据的节点的汇合）中，当波及读写操作时，只能保障一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被就义。

P 分区容忍性（Partition Tolerance）：当呈现网络分区后，零碎可能持续“履行职责”
A 可用性（Availability）：非故障的节点在正当的工夫内返回正当的响应（不是谬误和超时的响应）
C 一致性（Consistency）：对某个指定的客户端来说，读操作保障可能返回最新的写操作后果

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

CP – Consistency/Partition Tolerance
AP – Availability/Partition Tolerance

在理论设计过程中，每个零碎不可能只解决一种数据，而是蕴含多种类型的数据，有的数据必须抉择 CP，有的数据必须抉择 AP。
。但在理论设计过程中，每个零碎不可能只解决一种数据，而是蕴含多种类型的数据，有的数据必须抉择 CP，有的数据必须抉择 AP。

CAP 实践中的 C 在实践中是不可能完满实现的，在数据复制的过程中，节点 A 和节点 B 的数据并不统一。

CAP 实践通知咱们分布式系统只能抉择 CP 或者 AP，但其实这里的前提是零碎产生了“分区”景象。
架构设计的时候既要思考分区产生时抉择 CP 还是 AP，也要思考分区没有产生时如何保障 CA

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

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

Atomicity（原子性）：一个事务中的所有操作，要么全副实现，要么全副不实现，不会在两头某个环节完结
Consistency（一致性）：在事务开始之前和事务完结当前，数据库的完整性没有被毁坏
Isolation（隔离性）：数据库容许多个并发事务同时对数据进行读写和批改的能力。隔离性能够避免多个事务并发执行时因为穿插执行而导致数据的不统一。事务隔离分为不同级别，包含读未提交（Read uncommitted）、读提交（read committed）、可反复读（repeatable read）和串行化（Serializable）。
Durability（持久性）：事务处理完结后，对数据的批改就是永恒的，即使系统故障也不会失落。

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

这里须要补充一点，上述了解能够认为是将 ACID 限度在单机事务。如果放在分布式场景，ACID 个性了解为 CAP 中一致性的边界，最强的一致性。但这须要一些分布式协定来反对，如：二阶段提交协定，TCC 协定等。

核心思想：即便无奈做到强一致性（CAP 的一致性就是强一致性），但利用能够采纳适宜的形式达到最终一致性。具备如下特点：

根本可用（Basically Available）：分布式系统在呈现故障时，容许损失局部可用性，即保障外围可用。
软状态（Soft State）：容许零碎存在中间状态，而该中间状态不会影响零碎整体可用性。这里的中间状态就是 CAP 实践中的数据不统一。
最终一致性（Eventual Consistency）：零碎中的所有数据正本通过肯定工夫后，最终可能达到统一的状态。

BASE 实践实质上是对 CAP 的延长和补充，更具体地说，是对 CAP 中 AP 计划的一个补充。

AP 计划中就义一致性只是指分区期间，而不是永远放弃一致性。
CAP 实践是疏忽延时的，而理论利用中延时是无奈防止的。

从 0 开始学架构

退出移动版