微服务分享--解析CAP理论

Posted 2021-05-01 程序员地铁时光

今日主题：分布式基础理论-CAP理论详解

今日内容：在我们日常的系统设计中，经常会出现一个CAP理论，CAP理论到底是什么，如何选择CAP，今天我们来仔细分享一下

---

微服务往期文章：

---

CAP理论

    CAP原则又称CAP定理，指的是在一个分布式系统中，，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CA 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。如下图

一、CAP理论解析

1.Partition tolerance：分区容错性

    大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区(Partition)分区容错的意思是，区间通信可能失败，比如一台机器放到北京，一台服务器放到上海，这就是两个区，他们之间可能无法通信。

2.Consistency：一致性

    写操作之后的读操作，必须返回该值，举例来说，客户端向SERVER-ONE写入数据DATA1，再次读取数据（无论是从SERVER-ONE，还是SERVER-TWO）DATA1的时候，会返回DATA1的数据，这种情况叫一致性。

    但是存在如果用户向SERVER-TWO发起读操作的时候，因为CLIENT没有向SERVER-TWO发起写操作，就会出现当从SERVER-TWO读取数据DATA1为空，这就不满足数据的一致性了，所以为了满足这种情况，就会在CLIENT向SERVER-ONE写数据的时候，SERVER-ONE向SERVER-TWO同时发送消息说明数据的添加，这样的话CLIENT去SERVER-TWO读取数据的时候，也能获取DATA1的数据。

如果从客户端角度看，一致性又可以分为以下几种：

• 强一致性（Strong Consistency）：在任何时候，用户或节点都可以读到最近一次成功更新的副本数据。这种一致性肯定是我们最想要的，但是很遗憾，强一致性在实践中很难实现，而且一般都会牺牲可用性。

• 弱一致性（Weak Consistency）：某个进程更新了副本的数据，但是系统不能保证后续进程能够读取到最新的值。

• 最终一致性（Eventual Consistency）：最终一致性是弱一致性的一种特例。某个A 进程更新了副本的数据，如果没有其他进程更新这个副本的数据，系统最终一定能够保证后续进程能够读取到A进程写进的最新值。但是这个操作存在一个不一致性的窗口，也就是 A 进程写入数据，到其他进程读取 A 写进去的值所用的时间。

3.Availability：可用性

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

可用性分类	可用水平（%）	年可容忍停机时间
容错可用性	99.9999	<1 min
极高可用性	99.999	<5 min
具有故障自动恢复能力的可用性	99.99	<53 min
高可用性	99.9	<8.8h
商品可用性	99	<43.8 min

    通常我们描述一个系统的可用性时，我们说淘宝的系统可用性可以达到5个9，意思就是说他的可用水平是99.999%，即全年停机时间不超过 (1-0.99999)*365*24*60 = 5.256 min这是一个极高的要求。一个分布式系统，上下游设计很多系统如负载均衡、WEB服务器、应用代码、数据库服务器等，任何一个节点的不稳定都可以影响可用性

二、Consistency 和 Availability 的不可兼容

通过最上面的图中我们发现CAP是不可同时存在的，主要原因所C和A不可同时存在，为什么呢？主要是因为可能出现通信失败（即出现分区容错）

• 情况一：如果要保证数据DATA1在SERVER-ONE和SERVER-TWO中的数据一致性，那么必须要在写入SERVER-ONE的同时对于SERVER-TWO进行读写操作的锁定，只有数据同步之后，再开发读写操作，那么SERVER-TWO在锁定阶段就是不可用的。

• 情况二：如果要保证SERVER-TWO的时刻可用性，那么就不能锁定它，这样就无法满足数据的一致性

• 情况三：如果不使用分区，那何谈分布式？

三、CAP的使用权衡

    对于分布式系统来说P是一个基本要求，所以我们主要在A和C之间进行权衡

• AP

    如果实现高可用，则需要放弃一致性，一旦网络出现问题，节点之间通讯失败，为了高可用，使得用户在访问时立即得到回应，则每个节点只能使用本地数据提供服务，但这样会导致全局数据的不一致性。

    这种主要在大型的电商使用比较多，比如你到淘宝参加秒杀活动，当你购买的时候，提示你可以正常下单，但是，当你点击支付的时候，会提示你已被抢购完毕，这主要是保证了服务的可用性，但是在一致性上做了牺牲，虽然会影响用户的体验，但是不致于访问流量发生堵塞。当然核心重点是，要保证数据的最终一致性

    对于大多数互联网应用，主机众多，部署分散，集群规模越来越大，所以网络故障，通信失败是很常见的，如果要保证服务的可用性极高，那么放弃一致性，选择数据的最终一致性是必不可少的。

• CP

    如果一个系统不要求强可用性的话，允许服务长时间停机或者长时间无响应的话，就可以保证CP而舍弃A。

    那大家要有疑问了，什么样的系统会设计成这样呢？最典型的就是分布式数据库，他们都是设计成CP，在发生极端的情况下，优先保证数据的一致性，如使用Redis、HBase等，数据一致性是最基本的要求，如果数据一致性都无法做到，那在实际生产环境中涉及到金钱方面的问题，将会是在灾难。

    其中包含有分布式协调组件zookeeper就是优先于保证CP的，而放弃了A。即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性。但是它不能保证每次服务请求的可用性，也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果

四、结论

    无论是CP还是AP或者是在极端情况下可能出现的CA，都是根据个人服务的场景来定的，合适的才是最好的

    如果设计到钱财方面，宁可网络发生故障，宁可服务停止，C（Consistency）：一致性，是必须保证的。不然服务再好，赔钱了，也没任何意义。其他的场景下，大部分是选择AP（Availability+Partition tolerance）：可用性+分区一致性，舍弃强一致性，退而求其次的使用数据的最终一致性来保证数据的安全性，大家有时间可以查一查分布式领域的另一个理论BASE理论。

    在实际情况下，比较常见的是：业务系统使用AP，而涉及到重要数据的如分布式数据库，使用CP；