CAP, BASE

CAP定理, CAP theorem 1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。 C, Consistency, 一致性 A, Availability, 可用性 P, Partition tolerance, 分区容忍性

CAP理论是分布式架构中重要理论, 它指出对于一个分布式计算系统来说，不可能同时满足CAP三点 CAP理论主张任何基于网络的数据共享系统，都最多只能拥有以下三条中的两条:

一致性, Consistency, C

所有节点访问同一份最新的数据副本；一致性(Consistency) (所有节点在同一时间具有相同的数据) Consistency 中文叫做"一致性”。意思是，写操作之后的读操作，必须返回该值。多个副本之间的一致性

在分布式系统中的所有数据备份，在同一时刻是否同样的值。 (等同于所有节点访问同一份最新的数据副本)

复制是导致出现数据一致性问题的唯一原因。如果只用一台数据库来处理所有的写入和读取请求，就一定不存在数据一致性的问题。但在中大型项目中，我们却经常需要将一份数据存储在超过一台数据库中 (即复制) ，原因有三:

即使一部分数据库出现故障，系统也能正常工作 (高可用)
使数据与用户在地理上接近 (降低延迟)
扩展可以处理读请求的机器数量 (可扩展性、提高读取吞吐量)

可用性, Availability, A

对数据更新具备高可用性 (A) ；(保证每个请求不管成功或者失败都有响应) 意思是只要收到用户的请求，服务器就必须给出回应。每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据

在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。 (对数据更新具备高可用性)

分区容忍/分区容错性, Partition tolerance, P

(系统中任意信息的丢失或失败不会影响系统的继续运作)

大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区 (partition) 。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。

以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。

CAP 原则的精髓就是要么 AP，要么 CP，要么 AC，但是不存在 CAP。如果在某个分布式系统中数据无副本，那么系统必然满足强一致性条件，因为只有独一数据，不会出现数据不一致的情况，此时 C 和 P 两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了 CP 系统，但是 CAP 不可同时满足。

Consistency 和 Availability 的矛盾

一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败 (即出现分区容错) 。

从CAP角度来看

有个思考，从CAP角度考虑，服务注册中心是CP系统还是AP系统呢？

首先，服务注册中心是为了服务间调用服务的，那么绝对不允许因为服务注册中心出现了问题而导致服务间的调用出问题。

再者，假如有node1,node2,node3,集群节点。保存着可用服务列表ip1，ip2，ip3，试想如果此时不一致，比如node1只保存了ip1,ip2，此时服务读取node1的节点，那么会造成什么影响？

调用node1的服务，顶多就是负载均衡时不会有流量打到ip3，然后等 node1同步回ip3后，又一致了，这对服务其实没什么太大影响。

所以，推出服务注册中心应该是个AP系统。

ZooKeeper其实比我想象的还要更多瓶颈，最近有遇到说下

ZooKeeper写是不可扩展的，当注册节点一定时，写性能会是瓶颈，发布应用时出现排队现象，表现出来的现象就是，应用的启动变得十分缓慢
ZooKeeper不支持跨机房的路由，不像eureka，有zone的概念，优先本地路由，当本机房路由，当本机房出现问题时，可以路由到另一个机房
ZooKeeper当节点过多时，如果有服务节点变更，需要同时通知机器，会发生"惊群效应”，瞬间打满网卡，且容易重复通知

BASE 理论

BASE 理论指的是基本可用 Basically Available，软状态 Soft State，最终一致性 Eventual Consistency，核心思想是即便无法做到强一致性，但应该采用适合的方式保证最终一致性。

BASE，Basically Available Soft State Eventual Consistency 的简写: BA: Basically Available 基本可用，分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。 S: Soft State 软状态，允许系统存在中间状态，而该中间状态不会影响系统整体可用性。 E: Consistency 最终一致性，系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。 BASE 理论本质上是对 CAP 理论的延伸，是对 CAP 中 AP 方案的一个补充。

柔性事务

不同于 ACID 的刚性事务，在分布式场景下基于 BASE 理论，就出现了柔性事务的概念。要想通过柔性事务来达到最终的一致性，就需要依赖于一些特性，这些特性在具体的方案中不一定都要满足，因为不同的方案要求不一样；但是都不满足的话，是不可能做柔性事务的。

幂等操作在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，支付流程中第三方支付系统告知系统中某个订单支付成功，接收该支付回调接口在网络正常的情况下无论操作多少次都应该返回成功。

https://xiaomi-info.github.io/2020/01/02/distributed-transaction/ https://www.ruanyifeng.com/blog/2018/07/cap.html https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86 https://my.oschina.net/u/867417/blog/1865971

Contents