分布式理论CAP和BASE

CAP理论

C: Consistency（一致性）
——强调数据一致性。
A: Availability（可用性）
——强调服务可用性。分布式系统中某些节点挂掉了，但是不会影响整体的业务。
P: Partition tolerance（分区容错性）
——分布式系统出现网络分区的时候，仍然能够对外提供服务。
——网络分区：网络故障/节点宕机都叫分区。

什么是可用性？
——分布式系统中的可用性指的是，当一个节点故障或网络出现问题时，系统仍然可以继续工作，保证用户的请求可以$得到响应$。
又或者用户请求不能得到及时响应，比如要求服务$0.5秒$即返回响应，但实际上要$5秒$，这也算是$不可用$。

P 是必然存在的情况

在分布式系统内， P 虽然发生概率低，但也是必然存在的问题。
在没有发生分区问题时，分布式系统是可以保证 C 和 A ；
如果不选 P，一旦发生分区错误，整个分布式系统就完全无法使用了，这是不符合实际需要的。
所以，对于分布式系统，我们只能考虑当发生分区错误时，如何选择一致性和可用性。

框架	AP	CP	算法
Nacos	✔	✔	AP:Distro / CP:Raft
Zookeeper	✘	✔	ZAB
ETCD	✘	✔	Raft
…	…	…	…

BASE理论

B: Basically Available(基本可用)
——保证基本可用，可以接受一定延迟响应。
比如要求服务$0.5秒$即返回响应，但实际上要$1秒$，但也可以满足业务需求。
可以通过流量削峰等手段来保障系统的核心功能的正常，从而实现基本可用。

S: Soft state(软状态)
——软状态是指数据的状态。因为BASE是强调数据最终一致性，那在数据完成最终一致性前，数据是处于一种临时状态。

允许系统中的数据存在临时状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

E: Eventually consistent(最终一致性)
——可以接受数据短暂不一致性，但最终数据要一致性。

在实际工程实践中，最终一致性分为 5 种：

1. 因果一致性（Causal consistency）

指的是：如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。

2. 读己之所写（Read your writes）

这种就很简单了，节点 A 更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。

3. 会话一致性（Session consistency）

会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

4. 单调读一致性（Monotonic read consistency）

单调读一致性是指如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。

5. 单调写一致性（Monotonic write consistency）

指一个系统要能够保证来自同一个节点的写操作被顺序的执行。

然而，在实际的实践中，这 5 种系统往往会结合使用，以构建一个具有最终一致性的分布式系统。实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的，比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。