了解高可用架构之前—

CAP定理(布鲁尔定理)，在2000年的ACM PODC上提出的猜想

📓1 CAP理论

理论描述

第一版：any distributed system cannot guaranty C,A and P simultaneously
对于一个分布式计算系统，不可能同时满足一致性(Consistence)、可用性(Availability)和分区容错性(Partition Tolerance) 三个设计约束

第二版：in a distributed system (a collection of interconnected nodes that share data.), you can only have two out of the following three guarantees across a write/read pair： Consistency, Availability, and Partition Tolerance - one of them must be sacrificed
在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读/写操作时，只能保证一致性（ Consistence ）、可用性（ Availability ）、分区容错性（ Partition Tolerance) 三者中的两个，另外一个必须被牺牲

第二版定义了什么才是CAP理论探讨的分布式系统：interconnected和share data，主要是因为分布式系统不一定会互联和共享数据，如果不互联和共享数据，则不一定在CAP理论的范围内
第二版强调了 write/read pair，说明CAP关注的是对数据的读和写操作。不是分布式系统所有的功能

1.1 一致性（Consistency）

第一版：All nodes see the same data at the same time
所有节点在同一时刻都能看见相同的数据

第二版:A read is guaranteed to return the most recent write for a given client
对于某个指定的客户端来说，读操作保证能够返回最新的读写操作结果

第一版以node的角度描述，第二版以client客户端的角度描述
- 第二版更加符合我们观察和评估系统的方式，站在客户端的角度观察系统的行为和特征
第一版的关键词是see，第二版是read
- read相比于see更加准确，描述的是客户端读写角度的一致性
第一版强调同一时刻拥有相同数据，第二版没有强调，说明可能同一时刻有不同数据
- 原因是在系统执行事务时，事务执行过程中，系统就是处于一个可能数据不一致的状态，不同的节点的数据并不完全一致，事务的状态就决定了同一时刻的数据可能是不一致的

1.2 可用性

第一版：Every request gets a response on success/failure
每个请求都能的到成功或失败的响应

第二版：A non-failing node will return a resonable response within a reasonable amount of time(no error or timeout)
一个非故障的节点，会在合理的时间返回合理的响应(不是错误和超时响应)

第一版针对的是所有请求都会有响应，而第二点强调了对于一个没有故障的节点才能满足这个要求
第一版将响应分为成功和失败，第二版则强调在合理的时间和合理的响应，并且说明了不是错误和超时
- 因为第一版太宽泛了，如果超时了，此时会有一个timeout错误，但是这个错误明显不属于一个合理的错误

1.3 分区容忍性(Partition Tolerance)

第一版：System continues to work despite message loss or partial failure
尽管出现消息丢失或者分区错误，但系统能够继续运行

第二版：The system will continue to function when network partitions occur
当出现网络分区后，系统能够继续履行职责

第一版的word和第二版的function
- work强调运行，只要系统不宕机，即使返回错误也是work，但是function强调的是发挥作用，能够正常处理业务
第一版中把分区原因源于消息丢失，但是第二版中强调了网络分区，因为导致网络分区的原因不止是消息丢失，连接中断，丢包，拥塞都可能导致网络分区

🧰2 CAP应用

虽然CAP理论是三个要素中只能取两个，但放到分布式环境下思考，会发现必须选择P（分区容忍性），因为网络本身不能做到100%可靠，分区是必然出现的，同时导致了AC的互斥

2.1 CP

在这里插入图片描述

为了保证一致性，分区发生时，N1节点的数据y应该更新到N2，但是由于网络分区N2与N1之间的复制通道中断，y就无法同步到N2，所以当C访问N2时，N2需要响应error，告诉C，服务器发生错误->违背了Availability要求，所以满足了CP就不能满足A

2.2 AP

在这里插入图片描述

为了保证可用性，分区发生时，N1节点的数据y应该更新到N2，但是由于网络分区N2与N1之间的复制通道中断，y就无法同步到N2，所以当C访问N2时，N2为了保证可用，就把数据x给了C，但是此时的数据已经是y了，所以不满足一致性Consistency，所以满足了AP就不能满足C

💠3 CAP细节

CAP在理论上清晰简洁，但是忽略很多细节，导致应用于实践时，由于各种复杂情况，出现误差和偏差

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

虽然在理论解释中，出现了很多的system，node等系统级别的概念，但是我们要知道CAP关注的重点和粒度是数据，对于数据才有一致性，可用性和分区容忍性的关注点也都在数据上

设计时，要从数据的角度去选择CP和AP
不同的数据需要选择CP或者AP，没有规定哪种方式处理数据更好
一个系统不可能只会有一种数据，所以要根据不同类型的数据去抉择其处理方式是AP还是CP

CAP是忽略网络延迟的

布鲁尔定义一致性时，没有考虑延迟，所以当事务提交时，数据能瞬间复制到所有节点。

但实际上是，A节点复制到B节点，需要花费一定的网络开销。
在同一个机房，如果数据量不大或者网络I/O较大，那么通常是在几毫秒。
如果不同地点，可能就是几十毫秒，所以C是不一定完美实现的。
- 之所以说不一定完美实现是因为在一些要求实时一致性的分布式系统中，可以采用不同的负载均衡/分发策略来保证业务的实时一致性
- 比如商品扣减，金额扣减，这些作用个体是用户的情况，可以按照用户id来分发，这种解决办法会导致某一个节点挂了，那个节点的用户访问不了

正常情况下，不存在CP和AP时可以选择CA

CAP理论告诉我们分布式系统只能选AP或者CP，但是在系统不发生分区时，我们就可以保证CA，因为网络正常说明，数据能正常同步，并且每个节点都可以正常访问。所以同时满足了一致和可用。

但是理论上可以保证CA，但是具体实现不同的数据可能就有不同的实现方式

放弃≠等于不做，为分区后恢复做准备

很多时候，系统都是CA的，分区并不常见，所以我们要保证的是，发生分区后我们要让系统迅速恢复到CA的状态
可用性高的系统也不等于说100%高可用，因为一些因素，比如阿里的光缆被挖断，所以高可用的可用性一般是保证几个9

CP情况：用户注册场景，当用户在A节点注册成功后，由于B节点分区，B节点没有A节点的用户注册数据，所以可以在A节点存储日志，等分区结束后同步到B节点
AP情况：分区发生后，A、B节点都可以修改用户数据，但是修改的内容可能不一样，如用户1在A中修改数据为x，在B修改数据为y，那么可以将数据合并，或者根据最后修改优先情况，或者人工筛查

🗂️4 ACID、BASE

4.1 ACID

ACID:Atomicity、Consistency、Isolation、Durability

Atomicity(原子性)：整个操作是原子的不可分割，要么全部完成，要么全部不完成，不会卡在中间某个环节，发生错误会回滚到开始前，整个事务就像没有执行过
Consistency(一致性)：事务开始和结束前后，数据库完整性没有被破坏
Isolation(隔离性)：允许多个事务同时对数据进行读写的能力，防止多个事务并发执行时由于交叉执行导致数据不一致
Durability(持久性)：事务处理结束后，数据的修改是永久的，系统故障也不会导致数据丢失

4.2 BASE

BASE：Basically Available、Soft State、Eventually COnsistency
核心思想是即使无法做到强一致性(CAP就是强一致性)，但应用可以采用合适的方式达到最终一致性

Basically Available(基本可用)：分布式系统出现故障后，保证核心功能能够使用
- 重点在于如何抉择核心和非核心，每个用户看重的功能都是不同的
Soft State(软状态)：允许存在一个中间状态(CAP理论中的数据不一致)，且不影响系统整体可用性，
Eventually COnsistency(最终一致性)：系统中所有数据副本通过一定时间，最终达到一致的状态
- 不同的数据能容忍的时间是不同的，用户账号同步最好1分钟达到一致，因为用户的请求可能会发到其他节点，微博可容忍时间更长一点，因为用户看不看得到某个大V的微博影响不大