金三银四精选面试题-你知道CAP定理和BASE理论吗？

你知道CAP定理和BASE理论吗？

CAP定理

• Consistency 一致性

• • 一致性指“all nodes see the same data at the same time”，即所有节点在同一时间的数据完全一致。
    

• • 一致性是因为多个数据拷贝下并发读写才有的问题，因此理解时一定要注意结合考虑多个数据拷贝下并发读写的场景。对于一致性，可以分为从客户端和服务端两个不同的视角。

• • 对于一致性，可以分为从客户端和服务端两个不同的视角。

• • • 客户端

• • • • 从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。

• • • 服务端

• • • • 从服务端来看，则是更新如何分布到整个系统，以保证数据最终一致。

• • 对于一致性，可以分为强/弱/最终一致性三类

• • • 从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。

• • • 强一致性

• • • • 对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。

• • • 弱一致性

• • • • 如果能容忍后续的部分或者全部访问不到，则是弱一致性。

• • • 最终一致性

• • • • 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

• Availability 可用性

• • 可用性指“Reads and writes always succeed”，即服务在正常响应时间内一直可用。

• • 对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。所以，一般我们在衡量一个系统的可用性的时候，都是通过停机时间来计算的。

• • 通常我们描述一个系统的可用性时，我们说淘宝的系统可用性可以达到5个9，意思就是说他的可用水平是99.999%，即全年停机时间不超过 (1-0.99999)*365*24*60 = 5.256 min，这是一个极高的要求。

• • 好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。一个分布式系统，上下游设计很多系统如负载均衡、WEB服务器、应用代码、数据库服务器等，任何一个节点的不稳定都可以影响可用性。

• Partition Tolerance分区容错性

• • 分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。
    

• • 分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，或者是机器之间有网络异常，将分布式系统分隔未独立的几个部分，各个部分还能维持分布式系统的运作，这样就具有好的分区容错性。

• • 简单点说，就是在网络中断，消息丢失的情况下，系统如果还能正常工作，就是有比较好的分区容错性。

那么CAP理论中的一致性、可用性和分区容忍性不能同时满足呢？

定理指出对于一个分布式系统来说不可能同时满足以上三种特性。 在理解CAP理论的最简单方式是想象两个节点分处分区两侧。 允许至少一个节点更新状态会导致数据不一致， 即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用， 那么又丧失了A性质。 除非两个节点可以互相通信， 才能既保证C又保证A，这又导致丧失了P性质。 也就是说，如图所示的三者交叉的位置，是不可能实现的。

既然CAP三者同时满足的条件是不可能的， 所以在系统设计的时候就需要作出取舍，比如弱化某些特性来支持其他两者。

弱化一致性 对结果不敏感的应用， 可以允许在新版本上线后过一段时间才能更新成功，不保证强一致性，保持最终状态的一致性。 典型的如，静态网站。

弱化可用性 对结果一致性很敏感的应用，如银行取款机，当系统发生故障时停止服务。 如清结算，转账等。 目前的paxos、raft等算法都是为保证强一致而设计的。这些系统会在 内部异常时拒绝或者阻塞客户端请求。

弱化分区容错性 现实中， 网络分区出现概率较小， 但难以避免。实践中，网络通信通过双通道等机制增强可靠性，达到高稳定的网络通信。

CP和AP架构的取舍

其实在实际工程中，可用性和一致性并不是完全对立的，我们往往关注的是如何在保持相对一致性的前提下，提高系统的可用性。

至于是使用CP或者AP架构，则取决于业务对一致性的要求。

CP架构：放弃可用性，追求一致性和分区容错性

举个栗子，ZooKeeper就是采用了CP一致性。

ZooKeeper是一个分布式的服务框架，主要用来解决分布式集群中应用系统的协调和移置性问题。在ZooKeeper中，对应每一个事务操作请求，ZooKeeper都会为其分配一个全局唯一的事务ID，每个事务ID对应一次更新操作，从这些事务ID中可以间接识别出ZooKeeper处理这些事务操作请求的全局顺序。

AP架构：放弃强一致性，追求分区容错性和可用性

举个栗子，Eureka就采用了AP可用性。

Eureka是Spring Cloud微服务技术栈中的服务发现组件。

Eureka的各个节点都是平等的，几个节点挂掉不影响正常节点的工作。剩余节点依然可以提供注册和查询服务，只要有一台Eureka在，就能保证注册服务可用。只不过查看的信息可能不是最新版本，不保证一致性。

BASE理论

• Basically Available（基本可用）  
  分布式系统在出现不可预知故障的时候，允许损失部分可用性

• Soft state（软状态）  
  软状态也称为弱状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据听不的过程存在延时。

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

那我们再来看看Base理论（Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致性）的缩写）；它基于CAP定理逐步演化来的，它是CAP中一致性和可用性权衡的结果，其核心思想是即使系统无法达到强一致性，可以根据应用自身的业务特点，采用适当的方式来使系统达到最终一致性。

基本可用是指当分布式系统发生故障的时候，允许损失部分可用性。常见的有以下几种情况：

• 响应时间上的损失：正常情况下，一个在线搜索引擎需要再0.5秒之内返回给用户响应的查询结果，但由于出现故障，查询结果的响应时间增加到了1~2秒。

• 功能上的损失：通常的做法是降级服务，如对于展示一些有序元素的页面，但部分组件出现故障时，这个时候可不展示有序元素，降级为无序元素列表。

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

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