分布式理论与分布式一致性算法详解

Posted 2021-04-24 好胖子的大数据之路

1. 分布式背景

1.1 集中式服务

所谓集中式系统就是指由一台或多台主计算机组成中心节点，数据集中存储于这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统所有的功能均由其集中处理。也就是说，集中式系统中，每个终端或客户端机器仅仅负责数据的录入和输出，而数据的存储与控制处理完全交由主机来完成。

集中式服务的优点：

1、结构简单
2、部署简单
3、项目架构简单

集中式服务的缺点：

1、大型主机的研发人才和维护人才培养成本非常高
2、大型主机非常昂贵
3、单点故障问题，主机一挂，所有服务终止运行
4、大型主机的性能扩展受限于摩尔定律

摩尔定律：

摩尔定律是由英特尔（Intel）创始人之一戈登·摩尔（Gordon Moore）提出来的。其内容为：当

价格不变时，集成电路上可容纳的元器件的数目，约每隔18-24个月便会增加一倍，性能也将提升

一倍。换言之，每一美元所能买到的电脑性能，将每隔18-24个月翻一倍以上。

所以说摩尔定律告诉了我们：纵向扩展理论上是有上限的，所以只能考虑横向扩展，从理论上来讲，横向扩展理论上不受限！

1. 纵向扩展：提升服务器性能，有上限

2. 横向扩展：提升服务器数量（分布式）

总结：一台服务器服务器搞定所有的事情！！！

1.2 分布式服务

在《分布式系统概念与设计》这一书中，对分布式系统做了如下定义：分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

简单来说就是一群独立计算机集合共同对外提供服务，但是对于普通的用户来说，就像是一台计算机在提供服务一样。

分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，cpu、内存、存储资源等也就越多，能够处理的并发访问量也就越大。

一个由分布式系统实现的网上商城，在功能上可能被拆分成多个应用，分别提供不同的功能，组成一个分布式系统对外提供服务。

而系统内的各个子系统之间通过网络进行通信和协调，如异步消息或者RPC/HTTP请求调用等。

所以，分布式系统中的计算机在空间上几乎没有任何限制，这些计算机可能被放在不同的机柜上，也可能被部署在不同的机房中，还可能在不同的城市中，对于大型的网站甚至可能分布在不同的国家和地区。

分布式系统的特点：

分布性：分布式系统中的多台计算机都会在空间上随意分布，同时他们的分布情况也会随时变动
对等性：集群中的每个工作节点的角色是一样的。注意副本这个概念
并发性：多个机器可能同时操作一个数据库或者存储系统，可能引发数据不一致的问题
缺乏全局时钟：分布式系统中的多个主机上的事件的先后顺序很难界定（分布式场景最难的问题之一）
故障总是发生（要对生产环境抱有敬畏）：组成分布式系统的所有计算机，都有可能发生任何形式的故障。

和集中式系统相比，分布式系统的性价比更高、处理能力更强、可靠性更高、也有很好的扩展性。

但是，分布式在解决了网站的高并发问题的同时也带来了一些其他的问题

首先 ，分布式的必要条件就是网络，这可能对性能甚至服务能力造成一定的影响。

其次 ，一个集群中的服务器数量越多，服务器宕机的概率也就越大。

另外 ，由于服务在集群中分布式部署，用户的请求只会落到其中一台机器上，所以，一旦处理不好就很容易产生数据一致性问题。

总结：分布式集群发挥人多力量大的优势

1.3 分布式异常问题

• 通信异常： 网络不可用（数据延迟或者丢失），会导致分布式系统内部无法顺利进行一次网络通信，所以可能造成多节点数据丢失和状态不一致，还有可能造成数据乱序。

• 网络分区： 网络不连通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域，分布式系统就会出现局部小集群造成数据不一致

• 分布式三态： 即成功、失败和超时，分布式环境中的网络通信请求发送和结果响应都有可能丢失，所以请求发起方无法确定消息是否处理成功。

• 存储数据丢失：  对于有状态节点来说，数据丢失意味着状态丢失，通常只能从其他节点读取、恢复和存储的状态。

• 异常处理原则： 被大量工程实践所检验过的异常处理黄金原则就是：任何会发生的异常问题一定会在系统中发生，所以请尽量

1.4 衡量分布式系统的性能指标

• 性能：下面的性能指标往往会相互制约，追求高吞吐就很难低延迟，延迟长就很难QPS高

吞吐：系统在某一时间内可以处理的数据总量，通常可以用系统每秒处理的总数据量来衡量
响应延迟：完成某一项功能需要使用的时间
并发能力：可以同时完成某一功能的能力，通常用QPS来衡量

• 可用性：系统的可用性指系统在面对各种异常时可以正确提供服务的能力，系统的可永兴可以用系统停服务的时间比例来衡量，5个9 一年只有5分钟的宕机时间，6个9也就是31秒

• 可扩展性：系统的可扩展性指分布式系统通过扩展集群机器规模提高系统性能（吞吐、延迟、并发）、存储容量、计算能力的特性。好的分布式系统总在追求
  “线性扩展性”，也就是使得系统的某一指标可以随着系统中的机器数量线性增长。

• 一致性：分布式系统为了提高可用性，总是不可避免的使用副本的机制，从而引发副本的一致性问题，越是强的一致性，用户使用起来会越简单

1.5 一致性理解

• 强一致性： 写操作完后才能之后，读操作一定能读到最新的数据。在分布式场景中，很难实现。Paxos算法、Quorum机制、ZAB协议可以实现

• 弱一致性：不承诺立即可以读取到写入的值，也不承诺多久之后数据能够达成一致，但是会保证尽可能在一个时间范围内达成一致

1. 一种方案是对于一些特定的内容我们每次都去主库读取。
2. 或者我们设置一个更新时间窗口，在刚更新的一段时间内，我们默认都从主库读取，过了这个窗口之后，我们会挑选最近更新的从库进行读取
3. 我们直接记录用户的更新时间戳，在请求的时候吧这个时间戳带上，凡是更新时间小于这个时间戳的从库都不予响应。

• 单调读一致性：本次读到的数据不能比上次读到的旧、多次刷新返回旧数据出现灵异事件。解决方案：通过hash映射到同一台机器

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

• 最终一致性：是所有分布式一致性模型当中最弱的，不考虑中间的任何状态，只保证经过一段时间后，最终系统内数据正确。它最大程度上保证了系统的并发能力，也因此，他是高并发场景下使用最广的一致性模型

1.6 分布式一致性的作用

1. 为了提高系统的可用性，以防止单点故障引起的系统不可用

2. 提高系统的整体性能，通过负载均衡技术，能够让分布在不同地方的数据副本，都能够为用户提供服务

我们已经知道了分布式数据一致性的重要性，那么我们如何解决呢，我们应该深入思考，因为有人花费了毕生的时间来研究这个问题

2. 分布式事务

2.1 2PC两阶段提交

2.1.1 第一阶段：请求表决阶段

1、在分布式事务发起者向分布式事务协调者发送请求的时候，事务协调者会向所有参与者发送事务预处理请求

2、这个时候参与者会开启本地事务并开始执行本地事务，执行完成后不会commit，而是向事务协调者报告是否可以处理本次事务

2.1.2 第二阶段：提交、执行、回滚阶段

分布式事务协调者收到所有参与者反馈后，所有参与者节点均响应可以提交，则通知参与者和发起者执行commit，否则rollback

2.1.3 2PC的问题

1. 性能问题（同步阻塞）

从流程上面可以看出，最大的缺点就是执行过程当中节点都处于阻塞状态，各个操作数据库的节点都占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知进行全局commit/rollback，参与者进行本地事务commit/rollback之后才会释放资源，对性能影响较大

2. 单点故障问题（协调者可能宕机）

事务协调者是整个分布式事务的核心，一旦事务协调者出现故障，会导致参与者收不到commit/rollback的通知，从而导致参与者节点一直处于事务无法完成的中间状态。

3. 数据不一致（消息丢失问题）

在第二阶段的时候，如果发生局部网络问题，一部分事务参与者收不到commit或rollback消息，那么就会导致节点间数据不一致问题。

4. 太过保守（没有容错机制）

必须受到所有参与的正反馈才提交事务：如果有任意一个事务参与者的响应没有受到，则整个事务失败回滚

2.2 3PC三阶段提交

3PC即三阶段提交，是2阶段提交的稿近半，其将二阶段提交协议的“提交事务请求”一份为2，形成了 cancomiit、precommit、docommit三个阶段

除了在2PC的基础上增加了cancommit阶段还引入了超时机制，一旦事务参与者指定时间没有受到协调者的commit、rollback指令，就会自动本地commit，这样可以解决协调者单点故障问题

2.2.1 第一阶段 cancommit阶段 （提交询问）

分布式事务协调者询问所有参与者是否可以进行事务操作，参与者根据自身健康状况，是否可以执行是否操作，响应Y/N

2.2.2 第二阶段 precommit阶段 （预提交）

1、 如果参与者返回的都是同意，协调者则向所有参与者发送预提交请求，并进入prepared阶段

2、参与者受到预提交请求后，执行事务操作，并保存undo和redo信息到事务日志中

3、参与者执行完本地事务之后（uncommitted），会向协调者发送ack表示已经准备好提交，并等待协调者下一步指令

4、如果协调者收到预提交响应为拒绝，或者超时，则执行中断事务操作，通知各参与者中断事务（abort）

5、参与者受到中断事务（abort）或者超时等待，都会主动中断事务/直接提交

2.2.3 第二阶 docommit阶段 （最终提交）

1、协调者收到所有参与者的Ack，则从预提交进入提交阶段，并向参与者发送提交请求。

2、参与者受到提交请求，正式提交事务（commit），并向协调者反馈提交结果Y/N。

3、协调者收到所有反馈消息，完成分布式事务。

4、如果协调者超时没有收到反馈，则发送中断事务指令（abort）

5、参与者收到中断事务指令后，利用事务日志进行rollback

6、参与者反馈回滚结果，协调者接收反馈结果或者超时，完成中断事务。

2.2.4 3PC优点和缺点

1. 降低阻塞范围

相对于二阶段提交，三阶段提交协议的最大的有点就是降低了事务参与者的阻塞的范围，并且能够在出现单点故障后继续达成一致，对于协调者和参与者都设置了超时机制（在2PC中，只有协调者拥有超市机制，即如果在一定时间内没有收到参与者的消息则默认失败），主要是避免了参与者在长时间无法与协调者节点通讯（例如协调者挂了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制胡子爱超时后，自动进行本地commit从而进行释放资源，而这种机制也侧面的降低了事务的阻塞时间和范围。

2. 最后提交以前的状态一致

通过can commit、precommit、docommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。

3. 依然可能数据不一致

三阶段提交协议在去除阻塞的同时也引入了新的问题，那就是参与者接收到了precommit消息后，如果出现了网络分区，此时协调者所在的节点和参与者无法进行正常的网络通信，在这种情况下，该参与者依然会进行事务的提交，这必然出现数据的不一致性。

3. 分布式一致性算法详解

网络分区是一定会存在的。消息的延迟和丢失的可能性一定会有，就需要在就算发生了网络分区，也需要保证分布式数据一致性问题

3.1 Paxos算法

Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。

Paxos由Lamport于1998年在《The Part-Time Parliament》论文中首次公开，最初的描述使用希腊的一个小岛Paxos作为比喻，描述了Paxos小岛中通过决议的流程，并以此命名这个算法，但是这个描述理解起来比较有挑战性。后来在2001年，Lamport觉得同行不能理解他的幽默感，于是重新发表了朴实的算法描述版本《Paxos Made Simple》。

自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。Google的很多大型分布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。开源的ZooKeeper，以及mysql 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题。

然而，Paxos的最大特点就是难，不仅难以理解，更难以实现。

1、Client：系统外部角色，请求发起者。2、Propser：接受Client请求，向集群提出提议（propose）。并在冲突发生时，起到冲突调节的作用。3、Accpetor（Voter）：提议投票和接收者，只有在形成法定人数（Quorum，一般即为majority多数派）时，提议才会最终被接受4、Learner：提议接受者，backup，备份，对于集群一致性没什么影响。
   
     
     
   

    
      
      
    


    
      
      
    
 
     

 
    
   
     
     
   

3.1.1 Basic Paxos

步骤、阶段（phases）：

1. Phase 1a: Prepare

proposer提出一个提议，编号为N，此N大于这个proposer之前提出提议编号。请求acceptors的quorum接受。

2. Phase 1b: Promise

如果N大于此acceptor之前接受的任何提议编号则接受，否则拒绝。

3. Phase 2a: Accept

如果达到了多数派，proposer会发出accept请求，此请求包含提议编号N，以及提议的内容

4. Phase 2b: Accepted

如果此acceptor在此期间没有收到任何编号大于N的提议，则接受此提议内容，否则忽略

流程：

首先我们来看看没有冲突的流程

这个图描述的意思就是

• Client提出一个提议，交给Proposer来进行执行

• Proposer计算出提议编号，然后把提议编号发送给所有的Acceptor，这里并不携带任何提议内容，只是编号确认

• Acceptors收到协议之后，判断这个是不是比我的接收过的提议要大，大的话就接收这个提议，并且返回响应也就是Promise（1，{Va,Vb,Vc}）

• Proposer发现返回的响应大于半数也就是Quorum机制，发现都成功，这个时候就把提议内容和我的提议编号发送给Acceptors

• Acceptors收到协议之后，如果提议编号比我的都大，那么这个时候就接收这个提议，返回给Proposer，同时Learner开始学习，学习成功后返回

我们来看看假如有Acceptor单节点失败怎么办

其实单点失败并不影响最终结果，只要Acceptor的响应大于半数就可以，其他的和基本流程是一样的

我们来看看假如Proposer失败怎么办

• Client提出一个提议，交给Proposer执行，Proposer会计算出来提议编号，发给Acceptors

• Acceptors接收了这个提议，并且返回成功，但是这个时候Proposer失败了，那么这个提议并没有被接受，也就是说只是编号之间的预处理阶段

• 那么这个时候就会启动另一个Proposer来继续进行提议，这个时候已经提议过1编号了，此时自增这个编号，继续进行提议剩下的和以上的流程都是一样的了

Paxos算法的活锁问题

• 首先Proposer1 提出一个提议 编号为1，这个时候发送给所有的Acceptors，他们达到了半数响应返回给了Proposer1，这个时候Proposer1开始准备发送提议了

• 但是这个时候Proposer2提出了一个提议编号为2，这个时候Acceptor发现我当初承诺小于1的我就不要了，但是比我大的我能接受，于是都接受了Proposer2

• 但是这个时候Proposer1，发送提议的时候，发现。我靠我的提议被人干死了，不行，我要继续提议，于是自增自己的编号为3，开始提议，

• Proposer2也会有这样的问题，那么也自增自己的编号，这个时候就会出现一个问题，那就是谁的提议都不会被执行（工程里面可以增加一个等待时间就可以解决这个问题）

这个时候我们发现了Basic Paxos的问题，也就是难实现，效率低（2轮RPC）、活锁问题

3.1.2 Multi Paxos

在 Basic Paxos的基础上，踢出多个Propser，只保留了一个Propser

新概念，Leader：唯一的propser，所有的请求都需要经过此Leader

这个流程是什么意思呢？

• Client发出了一个提议给唯一的Proposer（这个是选举出来的）

• Proposer首先发送给Acceptors告诉他们我是第几任Proposer，因为在分布式领域可能有节点宕机的问题，所以Proposer可以会出现宕机

• Acceptors就会告诉Proposer，你是leader我们承认你

• Proposer就会开始发送协议，告诉他们协议是什么，你们执行就完了

• Acceptors就会把结果告诉Proposer，执行完成后，Learner就会进行学习，其实learner是什么呢，其实就是备机，例如mysql的从机进行复制的

上面的这个图的意思就是，选举已经结束了，这个时候，只需要发给Leader来进行数据操作就好了。

其实Multi Paxos就是减少了角色，并且减少了RPC的次数，没有活锁问题了，并且更加容易实现

3.2 Raft算法

可以理解为Multi Paxos 的简化版本

• Raft算法将分布式领域的问题，划分成了三个子问题，认为只要解决了这三个子问题，我就认为解决了分布式数据一致问题

• Leader Election（选举Leader）

• Log Replication（副本同步）

• Safety （数据安全）

• 三个子问题：

• 重定义角色

• Leader （主节点）

• Follower（从节点）

• Candidate（观察者）

原理动画演示：http://thesecretlivesofdata.com/raft/

3.2.1 Leader Election

一个节点可能有三个状态

• Follower

• Leader

• Candidate

选举流程

• 集群启动的时候是没有Leader的，所以所有人都是Follower

• 假如有一个人要成为Leader那么就会先成为Candidate状态

• 然后向其他的Follower进行投票，如果其他的Follower同意，那么他就成为了Leader

3.2.2 Log Replication

• Client会发送请求给Leader来进行数据处理

• Leader收到请求的时候会把数据的处理分发给所有的Follower，此时不提交

• 当Leader收到多于半数的Follower收到了这个消息，那么Leader首先会自己提交

• 然后Leader会告诉其他Follower你们也进行提交

3.2.3 Safety

选举

• 每个Follower，会对Leader的心跳会进行倒计时，当倒计时时间到了之后，最先到的那个人成为观察者也就是Cadidate并且有一个leader的编号类似于递增的，就像第几任总统一样

• 其他的和上面的选举是一样的

• Leader选举之后，就开始每间隔一段时间会发送给心跳给其他的Follower，同时心跳会发送一些操作信息

• 每一次发送心跳，Follower接收到之后都会更新自己的超时时间

• 假如leader宕机了，这个时候，每个follower开始统计自己的超时时间，谁快谁成为观察者，然后投票成为leader，然后更改自己的term也就是相当于第几任总统

• 假如有四台机器，有两台机器都成为了观察者，这个时候观察者都会随机一个等待时间，谁先起来的时候，谁就是leader

复杂的 Log Replication

假如出现了网络分区的情况

这个时候我们可以看到，下面网络分区的这个集群，会出现，他并不能成功的处理客户端的请求，所以不会真正的处理事件请求，但是上面三个节点是可使用了，因为是达到半数的，网络分区恢复的话，会发现我的term是1，发现有term是2的。所以我就自动成为follower并且恢复term2的数据

3.3 ZAB协议

Zookeeper的底层实现：ZAB协议

Zookeeper的底层工作机制，就是依靠ZAB实现的，实现了崩溃恢复和消息广播两个主要功能。

ZAB协议需要确保那些已经在leader服务器上提交的事务最终被所有服务器都提交。

ZAB协议需要确保丢弃那些只在leader服务器上被提出的事务。

如果让leader选举算法保证新选举出来的leader服务器拥有集群中所有机器的最高事务编号（ZXID）的事务proposal，那么就可以保证这个新选举出来的leader

一定具有所有已经提交的提议。

ZAB两种基本的模式：崩溃恢复和消息广播

ZAB协议和Raft算法其实是一样的，只是心跳和Raft算法相反，是follower来进行发送心跳给leader

基本是和Raft相同的，在一些名词叫法上有些区别：如ZAB将某一个leader的周期称为epoch，而Raft则称为term

实现上也有些许不同：如raft保证日志连续性，心跳方向为leader至follower。ZAB则相反。

4. 抽屉原理、鸽巢原理

鸽巢原理，又狄利克雷抽屉原理、鸽笼原理

鸽笼原理

其中一种简单的表述法为：

若有n个笼子和n+1只鸽子，所有的鸽子都被关在笼子里，那么至少有一个笼子有至少两只鸽子

另一种为：

若有n个笼子和kn+1只鸽子，所有的鸽子都被关在鸽笼里面，那么至少有k+1只鸽子

抽屉原理

2个抽屉如果每个抽屉最多容纳2个苹果，现在有三个苹果无论怎么放，其中的一个抽屉里面肯定会有2个苹果，那么我们把抽屉原理变形，2个抽屉一个放了2个红苹果，另一个放了2个青苹果，我们取出三个苹果，无论怎么取至少有一个是红苹果，我们可以吧红苹果看成更新了的有效数据，青苹果看成未更新的无效数据，这样可以看出来，不需要拿全部数据（并非全部都是红苹果），我们想要得到有效数据，只要拿最少拿3个就可以拿到我们想要的东西了。

5. Quorum NWR机制

Quorum NWR：Quorum机制是分布式场景中常用的，用来保证数据安全，并且在分布式环境中实现最终一致性算法的投票算法，这种算法的主要原理就来自于鸽巢原理。他最大的优势，就是既能实现强一致性，而且还能自定义一致性的级别

Write to all copies with latest version N, wait synchronously for W success Read from all

copies, wait for first R responses, pick the highest version number

N：复制的节点数，即一份数据被保存的副本数

W：写操作成功的节点数，即每次数据写入写成功的副本数，W肯定是小于等于N的。

R：读操作获取最新版本数据所需的最小节点数，即每次读取成功至少需要读取的副本数

总结：这是哪个因素决定了可用性，一致性和分区容错性。只要保证（W+R>N）就一定能读取到最新的数据，数据一致性级别完全可以根据读写副本数的约束来达到强一致性！

W=1,R=N ，Write Once Read All

在分布式环境中，写一份，如果我们想要获取到最新的数据，需要把所有节点全部读取，才能获取到最新值，写操作性能高，但是读效率低，分区容错性差，

可用性低，一致性高

R=1,W=N，Read Only Write All

在分布式环境中，所有节点都写成功，才能读取，这样写操作效率低，读操作高效，分区容错性好，一致性差，实现难度高，可用性高

W=Q,W=Q where Q = N/2 +1

可以理解为 写超过半数节点，那么读也超过一半的节点，取得读写性能平衡，一半适用于 读写性能取平衡，分区容错性，可用性，一致性取得一个平衡

6. CAP理论和BASE理论详解

6.1 CAP理论

CAP 理论：2000 年 7 月份被首次提出，CAP 理论告诉我们，一个分布式系统不可能同时满足 C,A,P 三

个需求

C：Consistency，强一致性

分布式环境中多个数据副本保持一致

A：Availability，高可用性

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

P：Partition Tolerance 分区容错性 

分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务

既然一个分布式系统不能同时满足 C,A,P 三个需求，那么如何抉择呢？

放弃 P：最简单的极端做法，就是放置在一个节点上，也就只有一个数据副本，所有读写操作就集

中在一台服务器上，有单点故障问题。放弃 P 也就意味着放弃了系统的可扩展性，所以分布式系

统一般来说，都会保证 P

放弃 A：一旦系统遇到网络分区或者其他故障时，服务需要等待一段时间，在等待时间内就无法正

常对外提供服务，即服务不可用

放弃 C：事实上，放弃一致性是指放弃数据的强一致性，而保留最终一致性，具体多久达到数据同

步取决于存储系统的设计

CAP只能3选2，因为在分布式系统中，容错性P肯定是必须有的，所有这个时候无非就两种情况，网络问题导致要么错误返回，要么阻塞等待，前者牺牲了一致性，后者牺牲了可用性。

经验总结：

• 架构师不要花费精力浪费在设计同时满足CAP的分布式系统

• 分区容错性往往是分布式系统必然要面对和解决的问题，所以架构师应该把精力放到如何根据业务特点在A和C之间寻求平衡

• 对于单机软件，因为不用考虑P，所以肯定是CA型，比如Mysql

• 对于分布式软件，因为一定会考虑P，所以又不能兼顾A和C的情况下，只能在A和C之间做权衡，比如HBase、Redis等，做到服务基本可用，并且数据最终一致即可。

6.2 BASE 理论

多数情况下，其实我们也并非一定要求强一致性，部分业务可以容忍一定程度的延迟一致，所以为了兼顾效率，发展出来了最终一致性理论 BASE，来自 ebay 的架构师提出。BASE理论全称：全称：

Basically Available(基本可用)

Soft state（软状态）

Eventually consistent（最终一致性）

三个 短语的缩写。核心思想是：即使无法做到强一致性，但每个应用都可 以根据自身业务特点，采用适当的方式来使系统达到最终一致性。一句话概括，做事别走极端，BASE 是对 CAP 理论中的 C 和 A 进行权衡

得到的结果。

不是强一致，而是最终一致
不是高可用，而是基本可用

Basically Available（基本可用）：

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用响应时间的损失：出现故障或者高峰，查询结果可适当延长，以用户体验上限为主。

功能上的损失：例如淘宝双11，为保护系统稳定性，正常下单，其他边缘服务可暂时不可用。

不是强一致，而是最终一致

不是高可用，而是基本可用。

Soft State（软状态）：

软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。通俗的讲：允许存在不同节点同步数据时出现延迟，且出现数据同步延迟时存在的中间状态也不会影响系统的整体性能

Eventually Consistent（最终一致）：

最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况，要求最终达到一致，而不是实时强一致