分布式系统核心理论之CAP、BASE理论

迷南。 2023-01-21 12:28 19阅读 0赞

## CAP ##

CAP是Consistency、Availablity、Partition-tolerance的缩写，由计算机科学家埃里克·布鲁尔在2000年提出的，所以又称布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点。

*  Consistency（一致性）：如果对任意一个节点的数据就行修改成功后，所有其他节点都能读取到最新的值，那么这个系统就被认为具有严格的一致性。
 *  Availability（可用性）：每次请求都能获取到非错的响应，即单节点宕机可从其他节点获取到响应，但是不能保障获取到的数据为最新的数据，即和一致性互斥
 *  Partition tolerance（分区容错性）：当节点间出现网络分区（不同节点处于不同的子网络，子网络之间是联通的，但是子网络之间是无法联通的，也就是被切分成了孤立的集群网络），照样可以提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。

任何一个分布式系统只能满足三选二，即只能AP或 CP，必须要有P 。为什么是如此，我们来作简单的分析。  
由于我们是分布式系统，所以我们必须要将系统部署在多节点，多网络分区，这才是分布式系统，而存在网络分区，我们就必须要保证P，，分区容错性

假设我们有两个节点A和B，不在同一个网络。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNjUxOTA0_size_16_color_FFFFFF_t_70]

此时A、B之间的网络断开。此时如果我们要满足分区容错性继续对外提供服务，那么我们还能同时满足一致性和可用性吗？  
假设现在用户对A节点进行了数据修改操作，而B与A直接网络通信断开了，A的数据修改操作没发同步给B，用户又对B进行了数据请求，那么他们之间的数据就不一致了。这时我们就只能二选一了：

1.  牺牲数据一致性©，将B的旧值返回给用户，保障可用性,选择AP
2.  牺牲可用性(A)，等待A、B之间的网络通信，阻塞用户的请求，满足一致性，选择CP

在设计系统时是选择CP还是AP就要看自己系统的业务所决定，不过在一些开源分布式系统中比如zookeeper、mongodb、hbase 他们都是基于CP来实现的即强一致性，如果发生网络分区导致数据不一致则都不能提供服务

## BASE ##

BASE 是由 Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致性）缩写而来的。BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性，让CAP三者同时基本实现。

*  Basically Available：基本可用，就是在某个节点宕机或者发生网络分区的情况，可以让所有请求都强制走主节点，这样保证了数据的一致性可可用性，如果主节点压力比较大可以触发降级熔断机制等，或者限流等，让原先0.5秒响应的请求以更长的时间去相应
 *  Soft state：软状态相对原子性来说各个要求都有所降低，原子性（硬状态），要求多个节点的数据副本都是一致的,这是一种"硬状态"。软状态（弱状态）允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延迟
 *  Eventually consistent：最终一致性，一致性也分强一致性和弱一致性，而最终一致性属于弱一致性，就是系统并不保证连续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。但会尽可能保证在某个时间级别（比如秒级别）之后，可以让数据达到一致性状态。

## 参考 ##

[维基百科][Link 1]  
[博客][Link 2]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNjUxOTA0_size_16_color_FFFFFF_t_70]: /images/20221020/2b6b0cd07be843d89b223330e28ba97c.png
[Link 1]: https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
[Link 2]: https://segmentfault.com/a/1190000018019595