理论基础

# 理论基础

数据库的四大特性ACID，无法解决现在微服务调用链路长和调用数据库多的问题。在此基础上，有诞生了两个新的理论，用于指导在分布式环境下的数据一致性问题。

# CAP定理

CAP定理是由加州⼤学伯克利分校Eric Brewer教授提出来的，他指出WEB服务⽆法同时满⾜⼀下3个属性：

⼀致性(Consistency) ：客户端知道⼀系列的操作都会同时发⽣(⽣效)
可⽤性(Availability) ：每个操作都必须以可预期的响应结束
分区容错性(Partition tolerance) ：即使出现单个组件⽆法可⽤，操作依然可以完成

具体地讲在分布式系统中，⼀个Web应⽤⾄多只能同时⽀持上⾯的两个属性。因此，设计⼈员必须在⼀致性与可⽤性之间做出选择。

2000年7⽉Eric Brewer教授仅仅提出来的是⼀个猜想，2年后，麻省理⼯学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP理论，并且⽽⼀个分布式系统最多只能满⾜CAP中的2项。之后，CAP理论正式成为分布式计算领域的公认定理。

定理说明原文: https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/ (opens new window)

# 一致性

数据⼀致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同⼀时间的数据完全⼀致，不能存在中间状态。

分布式环境中，⼀致性是指多个副本之间能否保持⼀致的特性。在⼀致性的需求下，当⼀个系统在数据⼀致的状态下执⾏更新操作后，应该保证系统的数据仍然处理⼀致的状态。

电商系统⽤户下单操作，库存减少、⽤户资⾦账户扣减、积分增加等操作必须在⽤户下单操作完成后必须是⼀致的。不能出现类似于库存已经减少，⽽⽤户资⾦账户尚未扣减，积分也未增加的情况。如果出现了这种情况，那么就认为是不⼀致的。

数据⼀致性分为强⼀致性、弱⼀致性、最终⼀致性。

如果的确能像上⾯描述的那样时刻保证客户端看到的数据都是⼀致的，那么称之为强⼀致性。
如果允许存在中间状态，只要求经过⼀段时间后，数据最终是⼀致的，则称之为最终⼀致性。
此外，如果允许存在部分数据不⼀致，那么就称之为弱⼀致性。

# 可用性

系统提供的服务必须⼀直处于可⽤的状态，对于⽤户的每⼀个操作请求总是能够在有限的时间内返回结果。

两个度量的维度：

有限时间内

对于⽤户的⼀个操作请求，系统必须能够在指定的时间（响应时间）内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可⽤的。即这个响应时间必须在⼀个合理的值内，不让⽤户感到失望。
返回正常结果

要求系统在完成对⽤户请求的处理后，返回⼀个正常的响应结果。正常的响应结果通常能够明确地反映出对请求的处理结果，即成功或失败，⽽不是⼀个让⽤户感到困惑的返回结果。

# 分区容错性

即分布式系统在遇到任何⽹络分区故障时，仍然需要能够保证对外提供满⾜⼀致性和可⽤性的服务，除⾮是整个⽹络环境都发⽣了故障。

⽹络分区，是指分布式系统中，不同的节点分布在不同的⼦⽹络（机房/异地⽹络）中，由于⼀些特殊的原因导致这些⼦⽹络之间出现⽹络不连通的状态，但各个⼦⽹络的内部⽹络是正常的，从⽽导致整个系统的⽹络环境被切分成了若⼲孤⽴的区域。组成⼀个分布式系统的每个节点的加⼊与退出都可以看做是⼀个特殊的⽹络分区。

任何⼀个分布式系统都⽆法同时满⾜⼀致性（Consistency）、可⽤性（Availability）和分区容错性（Partition tolerance），最多只能同时满⾜两项。

在互联⽹领域的绝⼤多数的场景中，都需要牺牲强⼀致性来换取系统的⾼可⽤性，系统往往只需要保证最终⼀致性。

# CAP权衡

对于多数⼤型互联⽹应⽤的场景，主机众多、部署分散，⽽且现在的集群规模越来越⼤，所以节点故障、⽹络故障是常态，⽽且要保证服务可⽤性达到 N 个 9，即保证 P 和 A，舍弃C（退⽽求其次保证最终⼀致性）。虽然某些地⽅会影响客户体验，但没达到造成⽤户流程的严重程度。

对于涉及到钱财这样不能有⼀丝让步的场景，C 必须保证。⽹络发⽣故障宁可停⽌服务，这是保证 CA，舍弃 P。貌似这⼏年国内银⾏业发⽣了不下10 起事故，但影响⾯不⼤，报道也不多，⼴⼤群众知道的少。还有⼀种是保证 CP，舍弃 A。例如⽹络故障是只读不写。

# BASE定理

BASE基于CAP定理演化⽽来，核⼼思想是即时⽆法做到强⼀致性，但每个应⽤都可以根据⾃身业务特点，采⽤适当的⽅式来使系统达到最终⼀致性。主要是对CAP中AP模式的进一步补充。

# Basically Available（基本可⽤）

基本可⽤是指分布式系统在出现不可预知的故障的时候，允许损失部分可⽤性，但不等于系统不可⽤。

主要是损失下面两个方面，来提高系统的可用性。

响应时间上的损失 -> 当出现故障时，响应时间增加
功能上的损失 -> 当流量⾼峰期时，屏蔽⼀些功能的使⽤以保证系统稳定性（服务降级）

# Soft state（软状态）

与硬状态相对，即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可⽤性，即允许系统在不同节点的数据副本之间进⾏数据同步的过程存在延时。

# Eventually consistent（最终⼀致性）

强调系统中所有的数据副本，在经过⼀段时间的同步后，最终能够达到⼀个⼀致的状态。其本质是需要系统保证最终数据能够达到⼀致，⽽不需要实时保证系统数据的强⼀致性。

最终⼀致性可分为如下⼏种：

因果⼀致性（Causal consistency）

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

节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。
会话⼀致性（Session consistency）

系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
单调读⼀致性（Monotonic read consistency）

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

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

BASE理论是提出通过牺牲⼀致性来获得可⽤性，并允许数据在⼀段时间内是不⼀致的，但最终达到⼀致状态。在实际的实践中，这5种系统往往会结合使用，以构建一个具有最终一致性的分布式系统。

# BASE理论的特点

BASE理论⾯向的是⼤型⾼可⽤可扩展的分布式系统，和传统的事物ACID特性是相反的。

它完全不同于ACID的强⼀致性模型，⽽是通过牺牲强⼀致性来获得可⽤性，并允许数据在⼀段时间内是不⼀致的，但最终达到⼀致状态。

但同时，在实际的分布式场景中，不同业务单元和组件对数据⼀致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往⼜会结合在⼀起。

# ACID 和 BASE 的区别与联系

ACID 是传统数据库常⽤的设计理念，追求强⼀致性模型。BASE ⽀持的是⼤型分布式系统，提出通过牺牲强⼀致性获得⾼可⽤性。

ACID 和 BASE 代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对⼀致性要求是不同的，因此 ACID 和 BASE ⼜会结合使⽤。