如何深入理解分布式 CAP 原理？

幸福侠侣

如何深入理解分布式 CAP 原理？
原文地址：https://www.zhihu.com/question/487200329

检验医师

在分布式系统的世界里，CAP理论是一个绕不开的话题。Up在初次接触CAP理论时，感到不太好理解，尤其是对其中的P（分区容忍性）的理解。本文旨在通过通俗易懂的语言和例子，详细解析CAP理论的含义及其在实际应用中的体现。
提前划重点

• CAP分别的含义
  
• CP系统：即使发生网络分区，依然能保证一致性
  
• AP系统：即使发生网络分区，依然能保证可用性
  
• CA系统：一致性和可用性都可以保证，前提是不能发生网络分区
  

CAP分别的含义

CAP理论由加州大学伯克利分校的Eric Brewer教授在2000年提出，它指的是在一个分布式系统中，最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。

我们先分别看一下定义

• 一致性（Consistency）：一致性就是所有节点在同一时间具有相同的数据。也就是说，当一个节点更新了数据后，其他节点能够立即感知到这一变化，并保持数据的一致性。
  
• 可用性（Availability）：可用性是指每个请求都能收到一个（无论成功或失败的）响应，不会出现超时等情况。即系统能够持续不断地提供服务，不会因为某些节点的故障而导致服务中断。
  
• 分区容忍性（Partition tolerance）：分区容忍性就是系统在出现网络分区这种故障时，还能正常运行。Up这里详细解释一下这个特性，语义有点绕。
  网络分区，就是指网络故障导致部分节点之间无法通信。相当于原来是一个整体，现在因为不能相互通信，就像分成了几个区。那分区容忍就是指，即使出现了网络分区，系统照样能提供服务，该干嘛干嘛！
  

CAP理论告诉我们，这三个特性最多只能同时满足两个。所以，理论上会有三种系统--AP、CP、CA系统。这三种系统的特性，UP用更符合中文的语义总结了一下，下面我们来一一看一下。


CP系统：即使发生网络分区，依然能保证一致性

在CP系统中，一致性和分区容忍性是首要考虑的因素。这意味着，即使网络出现分区，系统仍然会保持数据的一致性。像一些银行系统，对于数据的一致性要求非常高，往往会倾向CP系统。
然而，这种一致性是以牺牲可用性为代价的。
举个例子，假设我们有一个分布式数据库系统，它采用了CP模型。当某个节点因为网络故障而无法与其他节点通信时（即出现分区），该节点会拒绝处理任何可能导致数据不一致的请求。这意味着，即使该节点能够继续运行，它也不会对外提供服务，直到网络故障恢复，它能够重新与其他节点保持数据一致性为止。
这种设计的好处是，它能够确保数据的绝对一致性。然而，缺点是它会导致系统的可用性降低。在网络故障频繁或持续时间较长的情况下，CP系统可能会因为无法提供服务而导致用户体验下降。
AP系统：即使发生网络分区，依然能保证可用性

与CP系统相反，AP系统更侧重于可用性和分区容忍性。在AP系统中，即使网络出现分区，系统仍然会保持对外提供服务的能力。然而，这种可用性是以牺牲一致性为代价的。
以分布式缓存系统为例，它通常采用AP模型。当某个节点因为网络故障而无法与其他节点通信时，该节点仍然会继续处理请求，并返回缓存中的数据。由于网络分区导致的数据不一致性，该节点返回的数据可能与其他节点中的数据不同。然而，这种不一致性对于某些应用场景来说是可以接受的，因为用户更关心的是系统的可用性和响应速度，而不是数据的绝对一致性。
AP系统的优点在于它能够确保系统的持续运行和快速响应。然而，缺点是它可能会导致数据的不一致性。在网络故障恢复后，系统需要通过某种机制（如数据同步或合并）来恢复数据的一致性。
CA系统：一致性和可用性都可以保证，前提是不能发生网络分区

CA系统没有分区容忍性，也就是说一旦发生网络分区，系统就不能正常提供服务了。
然而在现实中，网络分区是不可避免的。无论是物理网络的故障还是网络设备的故障，都可能导致网络分区的出现。因此，CA系统在实际应用中并不常见。我们上一讲说的两阶段提交，就是符合CA系统要求的。在不发生网络分区的时候，可以保证强一致性和可用性。感兴趣的朋友可以看一下：
程序猿Colin：通俗易懂讲分布式系统（一）：两阶段提交小结

好啦，今天就和大家聊到这里。CAP 理论虽然听起来有点抽象，但其实理解起来也没那么难。简单来说，就是分布式系统在设计时，需要在一致性、可用性和分区容忍性这三个要素之间做出权衡。不同的系统根据自己的需求和使用场景，会选择不同的侧重点，从而形成了 CP 系统、AP 系统和 CA 系统这三种不同的类型。

卡卡

一、背景

随着互联网规模和用户需求的不断增长，分布式系统成为构建大规模应用的必然选择。在分布式系统中，数据和计算资源被分散在多个节点上，带来了许多挑战。其中一个关键问题是如何在网络分区或故障情况下保持一致性和可用性。CAP理论由Eric Brewer于2000年提出，帮助我们理解在分布式系统中这三个重要特性之间的取舍。
二、CAP理论的原理



CAP理论指出，在一个分布式系统中，不可能同时满足以下三个属性：

• 一致性（Consistency）：所有节点在同一时刻是否看到相同的数据视图。
  
• 可用性（Availability）：每个请求是否都能在有限的时间内得到响应，不保证返回最新的数据。
  
• 分区容错性（Partition Tolerance）：即使在网络分区的情况下，系统仍能继续工作。
  

三、CAP理论的应用

在实际应用中，根据系统需求和业务场景，我们需要根据CAP理论权衡这三个属性。不同的系统可以在以下方式中进行选择：

• CA系统：在一些传统的关系型数据库系统中，一致性和可用性被认为是首要考虑的，而分区容错性则相对较弱。这意味着在网络分区发生时，系统会选择阻塞请求以保持数据的一致性，以确保所有节点看到的数据是相同的。这对于某些数据的强一致性需求很重要，但可能导致系统整体的可用性降低。典型代表如MySQL和PostgreSQL；
  
• CP系统：在一些分布式数据库系统中，一致性和分区容错性被认为是首要考虑的，而可用性可能会受到一些限制。系统将优先保持数据的一致性和容错性，但可能会在网络分区时牺牲一部分可用性。典型代表如Google的分布式存储系统Bigtable，以及基于Bigtable的开源实现HBase；
  
• AP系统：许多大规模互联网应用程序更倾向于追求可用性和分区容错性，而在一致性方面可能做出一些妥协。这些系统通常通过在不同节点之间进行数据复制来提高可用性，并允许在某些情况下返回部分陈旧的数据。典型代表如Amazon的分布式键值存储系统Dynamo；
  

四、关于CAP理论的思考

CAP理论是分布式系统设计中的一个重要指导原则，但它也存在一些缺陷和局限性。

• CAP理论将分布式系统的属性简化为三个二进制选择：一致性、可用性和分区容错性。实际上，分布式系统的属性是连续的，并且可以在不同的条件下进行灵活权衡。因此，CAP理论的二分法在某些情况下可能过于简化了问题，无法涵盖所有实际场景；
  
• CAP理论没有考虑网络延迟对系统行为的影响。在现实中，网络通信是分布式系统中的主要瓶颈之一，而且网络延迟是不可忽视的。CAP理论假设在有限的时间内完成通信和处理，但实际情况可能因为网络延迟而导致无法在有限时间内完成；
  
• CAP理论指出分布式系统不可能同时满足三个属性。然而，对于某些特殊情况和特定的系统设计，实际上可能会近乎同时满足这三个属性。因此，CAP理论在一定程度上可以被绕过或钻空子，不是一个严格的定理；
  

针对上述论述，我们可以找到一些典型代表作为参考

• Apache Cassandra：Cassandra是一个分布式、去中心化的NoSQL数据库系统。它在一致性、可用性和分区容错性之间采用了灵活的权衡策略。用户可以根据应用需求配置Cassandra的一致性级别，以获得最合适的系统行为。
  
• Apache Kafka：Kafka是一个高吞吐量的分布式发布-订阅消息传递系统。它更加注重可用性和分区容错性，而对于一致性有一些灵活性。Kafka使用分区复制机制来实现容错性，并允许用户根据需求设置消息传递的一致性级别。
  

所以，系统的CAP属性不是静态不变的，而是可以根据系统配置和设计进行调整。很多系统提供了一致性级别的配置选项，允许用户根据实际需求在一致性和可用性之间进行权衡。
五、总结

CAP理论为我们在设计和选择分布式系统时提供了一个重要的指导原则。我们需要根据系统的需求、数据的重要性以及对一致性和可用性的需求程度，来选择最适合的系统模型。权衡这三个属性，理解系统的妥协是设计可靠、高效分布式系统的关键。在实际应用中，可能需要综合运用不同的技术手段和策略，来达到最优的系统设计。
另外，我们也要考虑到CAP理论存在一些缺陷，开发人员和系统设计者在设计分布式系统时考虑CAP理论的同时，还需要综合考虑其他因素，并结合具体场景和需求来做出最优的系统设计决策。

本篇文章转载自天翼云官方网站开发者社区，了解更多云计算知识可登录天翼云官方网站开发者社区，点击专栏查看更多技术干货，与技术大咖促膝论道！


往期回顾：MongoDB之SCRAM认证- 知乎 (zhihu.com)

清风寡欲

分布式系统
分布式是指将一个系统或应用程序分散在多个计算机或节点上，这些计算机或节点通过网络连接进行通信和协作，共同完成系统或应用程序的任务。在分布式系统中，每个节点都可以独立地处理一部分任务，同时与其他节点协作完成整个系统的任务。分布式系统通常具有高可用性、可扩展性和容错性等优点。


高可用性：分布式系统可以将任务分散到多个节点上，当某个节点出现故障时，其他节点可以继续提供服务，从而保证系统的高可用性。
负载均衡：分布式系统可以通过负载均衡算法将请求分配到不同的节点上，从而避免单个节点负载过高，导致系统崩溃。
数据备份：分布式系统可以将数据备份到多个节点上，当某个节点出现故障时，可以从其他节点恢复数据，从而保证数据的可靠性和系统的可用性。
扩展性：分布式系统可以通过增加节点来扩展系统的处理能力，从而满足不断增长的用户需求。
三态： 分布式系统每一次请求与响应存在特有的“三态”概念，即成功、失败和超时。
重发： 分布式系统在发生调用的时候可能会出现 失败 超时 的情况. 这个时候需要重新发起调用。
幂等： 一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外）。也就是
说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。



select * from T where id = 1



update t set age = 18 where id = 1



update t set age = age +1 where id = 1

分片
分布式系统怎么将任务分发到这些计算机节点呢，很简单的思想，分而治之，即分片（partition）。对于计算，那么就是对计算任务进行切换，每个节点算一些，最终汇总就行了，这就是MapReduce的思想；对于存储，更好理解一下，每个节点存一部分数据就行了。当数据规模变大的时候，Partition是唯一的选择，同时也会带来一些好处：
　　（1）提升性能和并发，操作被分发到不同的分片，相互独立
　　（2）提升系统的可用性，即使部分分片不能用，其他分片不会受到影响
复制
在一些异常情况（单点故障：断电/进程Crash，网络故障：断网/高延迟）下，分布式系统还是需要继续稳定的对外提供服务，即需要较强的容错性。最简单的办法，就是冗余或者复制集（Replication），即多个节点负责同一个任务，最为常见的就是分布式存储中，多个节点复杂存储同一份数据，以此增强可用性与可靠性。但是引入了复制就在一定意义上使得保证强一致性变得很困难，就算是最终一致性，还需要考虑数据冲突的情况。



A/B为Partition，C为Replication，很多情况下，分片本身也会复制保证高可用，比如ElastiSearch

CAP

CAP理论是说对于分布式系统，最多只能同时满足一致性（C，Consistency）、可用性（A， Availability）、分区容错性（P，Partition Tolerance）中的两者。


一致性（C，Consistency）
一致性，是指对于每一次读操作，要么都能够读到最新写入的数据，要么错误。分布式数据一致性，指的是数据在多份副本中存储时，各副本中的数据是一致的。



Replication数据不一致

强一致性： 这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，
但实现起来往往对系统的性能影响大。但是强一致性很难实现。
弱一致性： 这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据
能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。
最终一致性：最终一致性也是弱一致性的一种，它无法保证数据更新后，所有后续的访问都能看到最新数值，而
是需要一个时间，在这个时间之后可以保证这一点（就是在一段时间后，节点间的数据会最终达到一致状态），而在这个时间内，数据也许是不一致的，这个系统无法保证强一致性的时间片段被称为「不一致窗口」。不一致窗口的时间长短取决于很多因素，比如备份数据的个数、网络传输延迟速度、系统负载等。


最终一致性在实际应用中又有多种变种： 因果一致性 -> 读己之所写一致性 -> 会话一致性，单调读一致性，单调写一致性。
因果一致性 -> 读己之所写一致性 -> 会话一致性
因果： 如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回进程A更新后的值。A和B具有因果关系。


读己之所写： 当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。


会话： 它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。


单调读一致性: 如果一个进程已经读取到一个特定值，那么该进程不会读取到该值以前的任何值


单调写一致性: 系统保证对同一个进程的写操作串行化


可用性（A， Availability）
可用性，是指对于每一次请求，都能够得到一个及时的、非错的响应，但是不保证请求的结果是基于最新写入的数据。
分区容错性（P，Partition Tolerance）
分区容错性，是指当节点之间出现网络问题时，整个系统能继续提供服务（提供一致性和可用性的服务）。允许网络丢失从一个节点发送到另一个节点的任意多条消息，即不同步。
CAP 权衡
CP (consistency + partition tolerance)：关注一致性和分区容忍性。它关注的是系统里大多数人的一致性协议。这样的系统只需要保证大多数结点数据一致，而少数的结点会在没有同步到最新版本的数据时变成不可用的状态。这样能够提供一部分的可用性。
对于银行来说，就是必须保证强一致性，也就是说C必须存在，如果保障了CP那么就具备了部分可用性。
AP (availability + partition tolerance)：这样的系统关心可用性和分区容忍性。因此，这样的系统不能达成一致性，需要给出数据冲突，给出数据冲突就需要维护数据版本。
对于互联网应用来说，机器数量庞大，节点分散，网络故障再正常不过了，那么此时就是保障AP，放弃C的场景，而从实际中理解，像网站这种偶尔没有一致性是能接受的，但不能访问问题就非常大了。
BASE理论

上面我们讲到CAP 不可能同时满足，而分区容错性是对于分布式系统而言，是必须的。如果系统能够同时实现 CAP 是再好不过的了，所以出现了 BASE 理论，BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写, Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是： 既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：响应时间上的损失，功能上的损失。
什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。软状态指的是：允许系统中的数据存在中间状态，并认为该状态不会影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
什么是最终一致性？上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素
分布式系统设计策略

心跳检测
用于检测一个节点是否出现了故障乃至无法工作了。以固定的频率向其他节点汇报当前节点状态的方式，心跳汇报时，一般也会携带一些附加的状态、元数据信息，以便管理。
周期检测心跳机制： Server端每间隔 t 秒向Node集群发起监测请求，设定超时时间，如果超过超时时间，则判断“死亡”。可以把该节点踢出集群
累计失效检测机制： 在周期检测心跳机制的基础上，统计一定周期内节点的返回情况（包括超时及正确返回），以此计算节点的“死亡”概率。另外，对于宣告“濒临死亡”的节点可以发起有限次数的重试，以作进一步判断。如果超过次数则可以把该节点踢出集群。
高可用HA
高可用(High Availability)是系统架构设计中必须考虑的因素之一,通常是指,经过设计来减少系统不能提供服务的时间。系统高可用性的常用设计模式包括三种：主备（Master-SLave）、互备（Active-Active）和（Cluster）模式。
主备模式就是Active-Standby模式，当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动（热备）或手动（冷备）方式将服务切换到主机上运行。在数据库部分，习惯称之为MS模式。MS模式即Master/Slave模式，这在数据库高可用性方案中比较常用，如MySQL、Redis、PostgreSQL等就采用MS模式实现主从复制。保证高可用，如图所示。


互备模式指两台主机同时运行各自的服务工作且相互监测情况。在数据库高可用部分，常见的互备是MM模式。MM模式即Multi-Master模式，指一个系统存在多个master，每个master都具有read-write能力，会根据时间戳或业务逻辑合并版本。


集群模式是指有多个节点在运行，同时可以通过主控节点分担服务请求。集群模式需要解决主控节点本身的高可用问题，一般采用主备模式。


脑裂
在高可用（HA）系统中，当联系两个节点的"心跳线"断开时(即两个节点断开联系时)，本来为一个整体、动作协调的HA系统，就分裂成为两个独立的节点(即两个独立的个体)。由于相互失去了联系，都以为是对方出了故障，两个节点上的HA软件像"裂脑人"一样，"本能"地争抢共享资源、争抢应用服务。
脑裂预防方案：

• 添加冗余的心跳线 ，即冗余通信的方法，同时用两条心跳线路 (即心跳线也HA)，这样一条线路坏了，另一个还是好的，依然能传送心跳消息，尽量减少"脑裂"现象的发生几率。
  

2. 仲裁机制, 当两个节点出现分歧时，由第3方的仲裁者决定听谁的。这个仲裁者，可能是一个锁服务，一个共享盘或者其它什么东西
3. 隔离(Fencing)机制,
3.1 共享存储fencing：确保只有一个Master往共享存储中写数据。
3.2 客户端fencing：确保只有一个Master可以响应客户端的请求。
3.3 Slave fencing：确保只有一个Master可以向Slave下发命令
容错性
容错的处理是保障分布式环境下相应系统的高可用或者健壮性，一个典型的案例就是对于缓存穿透问题的解决方案。
我们在项目中使用缓存通常都是先检查缓存中是否存在，如果存在直接返回缓存内容，如果不存在就直接查询数据库然后再缓存查询结果返回。这个时候如果我们查询的某一个数据在缓存中一直不存在，就会造成每一次请求都查询DB，这样缓存就失去了意义，在流量大时，或者有人恶意攻击如频繁发起为id为“-1”的条件进行查询，可能DB就挂掉了。


那这种问题有什么好办法解决呢？
1. 临时存放null值
2. 使用布隆过滤器


负载均衡
负载均衡：其关键在于使用多台集群服务器共同分担计算任务，把网络请求及计算分配到集群可用的不同服务器节点上，从而达到高可用性及较好的用户操作体验。负载均衡器有硬件解决方案，也有软件解决方案。硬件解决方案有著名的F5，软件有LVS、HAProxy、Nginx等。


以Nginx为例，负载均衡有以下6种策略：

负载均衡策略	说明
轮询	默认方式,每个请求会按时间顺序逐一分配到不同的后端服务器
预设 weight	权重方式,在轮询策略的基础上指定轮询的几率,权重越大,接受请求越多
客户端 ip_hash	依据ip分配方式,相同的客户端的请求一直发送到相同的服务器，以保证session会话
least_conn	最少连接方式,把请求转发给连接数较少的后端服务器
fair（第三方）	响应时间方式,按照服务器端的响应时间来分配请求，响应时间短的优先分配
url_hash（第三方）	依据URL分配方式,按访问url的hash结果来分配请求，使每个url定向到同一个后端服务

分布式架构服务调用
HTTP和RPC，HTTP跨平台效果更好但数据封装更臃肿，RPC基于TCP/IP协议，效率更高但开发迭代更慢。


HTTP 应用协议的通信框架
1. HttpURLConnection
java 原生 HttpURLConnection是基于http协议的，支持get，post，put，delete等各种请求方式，最常用的就是get和post
2. Apache Common HttpClient
HttpClient 是Apache Common 下的子项目，可以用来提供高效的、最新的、功能丰富的支持HTTP 协议的客户端编程工具包，并且它支持 HTTP 协议最新的版本。实现了所有 HTTP 的方法（GET,POST,PUT,HEAD 等）,支持 HTTPS 协议, 支持代理服务器等
3. OKhttp3
OKHttp是一个当前主流的网络请求的开源框架, 用于替代HttpUrlConnection和Apache HttpClient支持http2.0，对一台机器的请求共享一个socket。采用连接池技术，可以有效的减少Http连接数量。无缝集成GZIP压缩技术。支持Response Cache，避免重复请求。域名多IP支持
4. RestTemplate
Spring RestTemplate 是 Spring 提供的用于访问 Rest 服务的客户端，RestTemplate 提供了多种便捷访问远程Http服务的方法，能够大大提高客户端的编写效率，所以很多客户端比如 Android或者第三方服务商都是使用 RestTemplate 请求 restful 服务。面向 URL 组件，必须依赖于主机 + 端口 + URI。RestTemplate 不依赖于服务接口，仅关注 REST 响应内容。Spring Cloud Feign
RPC
RPC全称为remote procedure call，即远程过程调用。借助RPC可以做到像本地调用一样调用远程服务，是一种进程间的通信方式. 。常见的RPC框架有以下几种：
Java RMI（Romote Method Invocation）是一种基于Java的远程方法调用技术，是Java特有的一种RPC实现。


Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。


跨域
在分布式系统中, 会有调用其他业务系统,导致出现跨域问题，跨域实质上是浏览器的一种保护处理。如果产生了跨域，服务器在返回结果时就会被浏览器拦截(注意：此时请求是可以正常发起的，只是浏览器对其进行了拦截)，导致响应的内容不可用。


常见的解决方案
使用HttpClient内部转发
使用设置响应头允许跨域，response.setHeader(“Access-Control-Allow-Origin”, “*”); 设置响应头允许跨域.
基于Nginx搭建企业级API接口网关
使用Zuul搭建微服务API接口网关Zuul是spring cloud中的微服务网关。请求首先通过网关，进行路径的路由，定位到具体的服务节点上。可以使用zuul的过滤器的请求转发去解决跨域问题。
分布式协调技术和分布式锁
分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。
分布式锁两种实现方式：
1. 基于缓存（Redis等）实现分布式锁
获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID, 释放锁的时候进行判断。获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。释放锁的时候，通过UUID判断是不是该锁，若是该锁，则执行delete进行锁释放。
SETNX ：set一个key为value的字符串，返回1；若key存在，则什么都不做，返回0。
expire: 为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。
delete ：删除key
2. ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名, 基于ZooKeeper实现分布式锁的步骤如下：
创建一个目录mylock
线程A想获取锁就在mylock目录下创建临时顺序节点
获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁
线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点
线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁
服务削峰
瞬间流量巨大（高并发）,削峰从本质上来说就是更多地延缓用户请求，以及层层过滤用户的访问需求，遵从“最后落地到数据库的请求数要尽量少”的原则。
服务削峰方案

• 消息队列
  

要对流量进行削峰，最容易想到的解决方案就是用消息队列来缓冲瞬时流量，把同步的直接调用转换成异步的间接推送，中间通过一个队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息推送出去。
消息队列中间件主要解决应用耦合，异步消息， 流量削锋等问题。常用消息队列系统：目前在生产环境，使用较多的消息队列有 ActiveMQ、RabbitMQ、 ZeroMQ、Kafka、RocketMQ 等。在这里，消息队列就像“水库”一样，拦截上游的洪水，削减进入下游河道的洪峰流量，从而达到减免洪水灾害的目的。


2. 流量削峰漏斗：层层削峰
分层过滤其实就是采用“漏斗”式设计来处理请求的，这样就像漏斗一样，尽量把数据量和请求量一层一层地过滤和减少了。


分层过滤的核心思想
通过在不同的层次尽可能地过滤掉无效请求。
通过CDN过滤掉大量的图片，静态资源的请求。
再通过类似Redis这样的分布式缓存过滤请求
分层过滤的基本原则
对写数据进行基于时间的合理分片，过滤掉过期的失效请求。
对写请求做限流保护，将超出系统承载能力的请求过滤掉。
涉及到的读数据不做强一致性校验，减少因为一致性校验产生瓶颈的问题。
对写数据进行强一致性校验，只保留最后有效的数据。
服务降级
当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心服务正常运作或高效运作。
整个架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用或暂停使用。


从分布式，微服务架构全局的视角来看，降级处理方案：
页面降级 —— 可视化界面禁用点击按钮、调整静态页面
延迟服务 —— 如定时任务延迟处理、消息入MQ后延迟处理
写降级 —— 直接禁止相关写操作的服务请求
读降级 —— 直接禁止相关读的服务请求
缓存降级 —— 使用缓存方式来降级部分读频繁的服务接口
针对后端代码层面的降级处理策略，则我们通常使用以下几种处理措施进行降级处理：
抛异常
返回NULL
调用Mock数据
调用Fallback处理逻辑
服务熔断
在互联网系统中，当下游服务因访问压力过大而响应变慢或失败（调用链路的连锁故障，也叫做雪崩），上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。


Spring Cloud Hystrix 熔断机制实现
Spring Cloud Hystrix是基于Netflix的开源框架Hystrix实现，该框架实现了服务熔断、线程隔离等一系列服务保护功能。对于熔断机制的实现，Hystrix设计了三种状态：
熔断关闭状态（Closed）：服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制。
熔断开启状态（Open）：在固定时间内（Hystrix默认是10秒），接口调用出错比率达到一个阈值（Hystrix默认为50%），会进入熔断开启状态。进入熔断状态后， 后续对该服务接口的调用不再经过网络，直接执行本地的fallback方法。
半熔断状态（Half-Open）：在进入熔断开启状态一段时间之后（Hystrix默认是5秒），熔断器会进入半熔断状态。所谓半熔断就是尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。如果成功率达到预期，则说明服务已恢复，进入熔断关闭状态；如果成功率仍旧很低，则重新进入熔断开启状态。



集群和分布式的区别

我们的分布式系统都运行在集群上。集群可以运行一个或多个分布式系统，也可以没有运行分布式系统。
集群是指将多台计算机连接在一起，形成一个整体，共同完成某项任务。集群中的每台计算机都可以独立地运行应用程序，但它们之间可以相互通信和协作，以提高整个系统的性能和可靠性。
分布式是指将一个应用程序或系统分解成多个独立的部分，这些部分可以在不同的计算机上运行，通过网络进行通信和协作，最终完成整个系统的功能。
集群

集群是指由多台计算机组成的一个计算资源池，这些计算机通过网络互相连接，共同完成某个任务。集群可以提高系统的可靠性、可扩展性和性能，因为它可以将任务分配给多台计算机同时处理，从而提高计算速度和处理能力。集群通常由一个主节点和多个从节点组成，主节点负责协调和管理整个集群的工作，而从节点则负责执行具体的计算任务。
集群优势：
分布式计算：集群中的计算机可以同时处理多个任务，将任务分配给不同的计算机，从而实现分布式计算，提高计算效率。
负载均衡：集群可以通过负载均衡算法将任务均匀地分配给不同的计算机，避免某些计算机负载过重，导致系统性能下降。
高可用性：集群中的计算机可以相互备份，当某个计算机出现故障时，其他计算机可以接替其工作，保证系统的高可用性。
扩展性：集群可以通过增加计算机的数量来扩展系统的性能，当任务量增加时，可以通过增加计算机的数量来满足需求。

卡卡

​1. 引言

大家好，我是小❤，一个漂泊江湖多年的 985 非科班程序员，曾混迹于国企、互联网大厂和创业公司的后台开发攻城狮。
在计算机科学领域，分布式系统是一门极具挑战性的研究方向，也是互联网应用中必不可少的优化实践，而 CAP 理论和 BASE 理论则是分布式系统中的两个关键的概念。




今天，小❤将带大家深入浅出地探讨这些概念，帮助大家更好地理解分布式系统的奥秘。

2. 什么是分布式系统

首先，让我们来谈谈分布式系统。你可以将分布式系统想象成一个庞大的计算机网络，由多个计算机或服务器节点组成，它们可能分布在不同的地理位置上。




如图所示，应用层的三个节点都发布在不同的城市。这些节点之间可以相互通信和协作，共同完成复杂的任务。
想象一下，你是一名团队领导，有一项任务需要完成。如果你独自一人完成，可能需要花费很长时间。
但如果你将任务分解成几个子任务，分派给你的团队成员，他们可以并行工作，更快地完成任务。这就是分布式系统的核心思想。

3 CAP理论

接下来，让我们谈谈 CAP 理论，它是分布式系统设计中非常重要的一个原则。
CAP 是指在分布式系统中，Consistency（一致性）、Availability（可用性）和 Partition tolerance（分区容错性）这三个基本原则。

C - 一致性（Consistency）

一致性意味着无论你从分布式系统的哪个节点读取数据，你都会获得相同的数据副本，它确保了数据的准确性。
在分布式系统中，广泛的一致性分为三种，分别是强一致性、弱一致性和最终一致性。

强一致性

强一致性要求用户在分布式系统中访问数据时，不管是哪个节点的响应，数据都应该完全一致。
比如在订单系统中球鞋库存还剩 10 双，张三刚买了一双球鞋，数据更新完成后，接下来李四看到的球鞋数量就只有 9 双，否则就可能会出现超卖的情况。
但这需要更多的时间和精力来协调，就像李四在买鞋的时候，必须排队先等张三的购买动作结束后才可以继续，效率较低。

弱一致性

弱一致性是指，在分布式系统中的数据被更新后，也允许让后续的访问拿到更新之前的老数据。
就像参加聚会一样，每个人都有自己的钟表。各自的钟表时间可能会有点不一样，但是这不影响大家聚在一起玩耍。
弱一致性提高了业务的效率，但有时会导致一些混乱，想象一下如果聚会人员的时间差太多，就会陷入长久的等待。

最终一致性

最终一致性是弱一致性的特殊形式，要求系统的数据更新完成，在一段时间以后，后续的所有访问都能拿到最新的数据。
这就像朋友圈的消息传播。当你发了一条消息，它不会立刻被所有朋友看到，但最终，每个人都会看到相同的消息。
一般的业务系统基于性价比的考量，绝大多数都是采用最终一致性作为分布式系统的设计思想。




而 CAP 理论里的一致性，则要求是强一致性。正如官方文档中描述的那样：All nodes see the same data at the same time，所有节点在同一时间内数据完全一致。

A - 可用性（Availability）

可用性意味着分布式系统的每个请求都应该得到响应，而且应该在有限的时间内完成。
可用性确保了系统的稳定性和可靠性，它描述的是系统能够很好地为用户服务，不会出现用户操作失败或者访问超时的情况，影响用户体验。
即官方所说Reads and writes always succeed，服务在正常响应时间内一直可用。

P - 分区容错性（Partition Tolerance）

分区容错性是指系统能够在网络分区或通信故障的情况下继续运行，也就是节点之间的网络通信出现故障了，或者系统中的某一个节点出问题了，我们仍然需要保证业务系统可用。
即 The system continues to operate despite arbitrary message loss or failure of part of the system，分布式系统在遇到某个节点或者网络分区故障时，仍然能够对外提供满足一致性或可用性的服务。

4. CAP 的特点

4.1 分区容错的重要性

这时，有分布式基础的同学可能就会问了，CAP 理论确实很重要，但是这三个特性似乎不能同时满足，是吧？
没错，这就是 CAP 理论的核心观点。
CAP 理论告诉我们，在一个分布式系统中，我们最多只能同时满足其中 2 个特性，而无法同时满足 3 个。




为什么 C，A，P 三者不可兼得？首先，我们得知道，在分布式系统中，由于网络不可靠，为了保证服务可以时刻对外提供服务，所以分区容错性是一定要保证的。
试想如果只有一个分区，谈分布式就没有意义了。而多个分区，一定会有分区的故障问题，分布式系统中保证分区容错就变成最基本的诉求了。
所以现在我们只需考虑在分区容错的基础上，能否同时满足一致性和可用性，我们可以用反证法来证明。

4.2 AP Or CP

假设现在有两个分区 P1 和 P2，分区上都有同一份数据 D1 和 D2， 现在它们是完全相同的。




接下来，有一个请求 1 访问了 P1，更改了 D1 上的数据。然后又有一个请求 2 访问了 P2，去访问 D2 的同一份数据。
这时，我们需要权衡。

先保证一致性

如果先保证满足一致性和分区容错，即 CP。
这个过程很容易出现：D1 已经更新数据，但是查询 D2 时，数据返回的还是老数据。
为了保证 D2 和 D1 数据完全一致，必须在更新 D1 数据时给 P2 上的 D2 数据上锁，等待 D1 更新完成后再同步更新 D2。
这个过程中，锁住的 D2 就没法给请求 2 实时响应，也就是违背了 P2 上的可用性。
所以在满足一致性的前提下，CAP 无法同时满足。

先保证可用性

如果先保证满足可用性和分区容错，即 AP。
可用性要求 P1 和 P2 都可以实时响应，因此在 D2 刚更新完还未同步给 D1 时，两个 DB 的数据是不一致的，也就违背了 P1 和 P2 上的数据一致性。
所以在满足可用性的前提下，CAP 亦无法同时满足。

4.3 CAP 如何权衡





CAP 三者不可兼得，该怎么选择呢？一般根据我们的业务可以有以下选择。
满足一致性和分区容错CP

保证分区的强一致性（C），不要求可用（A）。
相当于请求到达某个系统之前，需要等待数据完全同步以后，才会得到系统的数据响应，一般在数据需严格保持一致的金融系统中会使用这种模式。

满足可用性和分区容错AP

保证分区的可用性（A），不要求强一致性（C）。
当请求访问某个分区的数据时，可能拿到未同步的老数据，这种模式一般只要求数据满足最终一致性，进而保证系统响应速度和高可用。
AP 在业界使用范围较广，比如著名的 BASE 理论（下文会细讲）。

满足可用和一致性AC

上文已经说过，分布式系统中无法同时保证系统的强一致性（C）和可用性（A）。
这是因为分布式系统中的分区是客观存在无法避免的，而单体系统中的数据库可以通过事务保证数据的一致性和可用性，比如 MySQL 中事务的四大特性（原子性、一致性、隔离性和持久性，简称 ACID）。

5. BASE 理论

BASE 理论是当今互联网分布式系统的实践总结，它的核心思想在于，既然在分布式系统中实现强一致性的代价太大，那不如退而求其次。




只需要各应用分区在提供高可用服务的基础上，尽最大能力保证数据一致性，也就是保证数据的最终一致性。
BASE 理论是 CAP 中保证分区容错（P）的前提下，对可用性（A）和一致性（C）的权衡，它由 Basically Available（基本可用），Soft State（软状态），Eventually-Consistent（最终一致性）三方面构成，简称 BASE 理论。
分布式系统中，CAP 理论提供了一个理论框架，而 BASE 理论则提供了一种实际操作的指导原则。

5.1 基本可用

BASE 理论认为，分布式系统在面临故障或异常情况时，可以选择降低性能或一致性要求，以保持基本的可用性。
这意味着系统可能会出现一些短暂的不一致性，但最终会达到一致状态。




正如一个银行系统的系统设计，一般有功能需求和非功能需求，我们首先需要保证核心功能需求的基本可用性。
功能需求

在银行系统里，用户提款、转账等交易模块就是核心功能，是用户的基本需求，不能出问题。
而非核心功能可以出现异常，但需要保证在一段时间内修复。

非功能需求

非功能需求是指用户业务不依赖的其它需求，比如性能相关的：要求用户转账在 0.5 秒内完成，但是由于网络延迟等原因，可以延迟响应至1~2 秒。
由于系统出现此类异常，从而影响了系统的高可用性，但核心流程依然可用，即基本可用性。

5.2 软状态

软状态是指系统服务可能处于中间状态，数据在保证一致性的过程中可能延迟同步，但不会影响系统的可用性。
比如我们在购买火车票付款结束之后，就可能处在一个既没有完全成功，也没有失败的中间等待状态。用户需要等待系统的数据完全同步以后，才会得到是否购票成功的最终状态。
BASE 理论认识到，在分布式系统中，状态可能会随时间变化而软化，而不是立即达到一致状态。




这意味着我们需要容忍一些状态的不确定性，比如我们在火车票候补排队时是不确定是否可以候补成功的。

5.3 最终一致性

最终一致性是 BASE 理论的核心思想。它指出，分布式系统可以在一段时间内保持不一致状态，但最终会收敛到一致状态。
它不像强一致性那样，需要分区数据保证实时一致，导致系统数据的同步代价过高。也不像弱一致性那样，数据更新后不保证数据一致，导致后续的请求只能访问到老数据。
当前业界的分布式系统，甚至关系数据库系统的数据，大都是用最终一致性实现的。比如 MySQL 的主从备份，就是在一段时间内通过 binlog 日志和监听线程让从库和主库的数据保持最终一致。




总的来说，BASE 理论其实就是牺牲了各节点数据的强一致性，允许不同节点的数据在一段时间内不一致，来获得更高的性能和高可用性。
在单体系统中，数据库还能通过 ACID 来实现事务的强一致性，但分布式事务需要考虑节点通信的延迟和网络故障。
所以，BASE 理论是我们在实际的分布式系统中经常使用的方案。

结语





感谢阅读观看，我们下期再见！
欢迎点赞分享，收藏加入在看。

队长是我

经历过技术面试的小伙伴想必对 CAP & BASE 这个两个理论已经再熟悉不过了！
我当年参加面试的时候，不夸张地说，只要问到分布式相关的内容，面试官几乎是必定会问这两个分布式相关的理论。一是因为这两个分布式基础理论是学习分布式知识的必备前置基础，二是因为很多面试官自己比较熟悉这两个理论（方便提问）。
我们非常有必要将这两个理论搞懂，并且能够用自己的理解给别人讲出来。
CAP 理论

CAP 理论/定理起源于 2000 年，由加州大学伯克利分校的 Eric Brewer 教授在分布式计算原理研讨会（PODC）上提出，因此 CAP 定理又被称作 布鲁尔定理（Brewer’s theorem）
2 年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 发表了布鲁尔猜想的证明，CAP 理论正式成为分布式领域的定理。
简介

CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。


CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候，并没有详细定义 Consistency、Availability、Partition Tolerance 三个单词的明确定义。
因此，对于 CAP 的民间解读有很多，一般比较被大家推荐的是下面   这种版本的解读。
在理论计算机科学中，CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个：

• 一致性（Consistency） : 所有节点访问同一份最新的数据副本
  
• 可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
  
• 分区容错性（Partition Tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务。
  

什么是网络分区？
分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫 网络分区。



partition-tolerance

不是所谓的“3 选 2”

大部分人解释这一定律时，常常简单的表述为：“一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到”。实际上这是一个非常具有误导性质的说法，而且在 CAP 理论诞生 12 年之后，CAP 之父也在 2012 年重写了之前的论文。

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。
简而言之就是：CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。

因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。 比如 ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构。
为啥不可能选择 CA 架构呢？ 举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。
选择 CP 还是 AP 的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证 CP 。
另外，需要补充说明的一点是：如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证。
CAP 实际应用案例

我这里以注册中心来探讨一下 CAP 的实际应用。考虑到很多小伙伴不知道注册中心是干嘛的，这里简单以 Dubbo 为例说一说。
下图是 Dubbo 的架构图。注册中心 Registry 在其中扮演了什么角色呢？提供了什么服务呢？
注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。


常见的可以作为注册中心的组件有：ZooKeeper、Eureka、Nacos...。

• ZooKeeper 保证的是 CP。 任何时刻对 ZooKeeper 的读请求都能得到一致性的结果，但是， ZooKeeper 不保证每次请求的可用性比如在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。
  
• Eureka 保证的则是 AP。 Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。 Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。
  
• Nacos 不仅支持 CP 也支持 AP。
  

  修正（参见：issue#1906）：
ZooKeeper 通过可线性化（Linearizable）写入、全局 FIFO 顺序访问等机制来保障数据一致性。多节点部署的情况下， ZooKeeper 集群处于 Quorum 模式。Quorum 模式下的 ZooKeeper 集群， 是一组 ZooKeeper 服务器节点组成的集合，其中大多数节点必须同意任何变更才能被视为有效。
由于 Quorum 模式下的读请求不会触发各个 ZooKeeper 节点之间的数据同步，因此在某些情况下还是可能会存在读取到旧数据的情况，导致不同的客户端视图上看到的结果不同，这可能是由于网络延迟、丢包、重传等原因造成的。ZooKeeper 为了解决这个问题，提供了 Watcher 机制和版本号机制来帮助客户端检测数据的变化和版本号的变更，以保证数据的一致性。
总结

在进行分布式系统设计和开发时，我们不应该仅仅局限在 CAP 问题上，还要关注系统的扩展性、可用性等等
在系统发生“分区”的情况下，CAP 理论只能满足 CP 或者 AP。要注意的是，这里的前提是系统发生了“分区”
如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。
总结：如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。
推荐阅读

• CAP 定理简化 （英文，有趣的案例）
  
• 神一样的 CAP 理论被应用在何方 （中文，列举了很多实际的例子）
  
• 请停止呼叫数据库 CP 或 AP （英文，带给你不一样的思考）
  

BASE 理论

BASE 理论起源于 2008 年， 由 eBay 的架构师 Dan Pritchett 在 ACM 上发表。
简介

BASE 是 Basically Available（基本可用）、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。
BASE 理论的核心思想

即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。
为什么这样说呢？
CAP 理论这节我们也说过了：

如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。因此，如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。

因此，AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。
BASE 理论三要素




BASE理论三要素

基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。
什么叫允许损失部分可用性呢？

• 响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。
  
• 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。
  

软状态

软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性

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

分布式一致性的 3 种级别：

• 强一致性：系统写入了什么，读出来的就是什么。
  
• 弱一致性：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
  
• 最终一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。
  

业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。

那实现最终一致性的具体方式是什么呢? 《分布式协议与算法实战》 中是这样介绍：

• 读时修复 : 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点的副本数据不一致，系统就自动修复数据。
  
• 写时修复 : 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败 就将数据缓存下来，然后定时重传，修复数据的不一致性。
  
• 异步修复 : 这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。
  

比较推荐 写时修复，这种方式对性能消耗比较低。
总结

ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。
分布式文章推荐 ：

• CAP & BASE理论详解
  
• Paxos 算法详解
  
• Raft 算法详解
  
• RPC 基础常见面试题总结
  
• Dubbo 常见面试题总结
  
• 分布式 ID 常见面试题总结
  
• 分布式ID设计指南
  
• API 常见面试题总结
  
• 分布式锁常见面试题总结