楔子
前面我们介绍了 zookeeper，了解了它的基本使用。但对于任何一个分布式系统而言，数据同步永远都是重中之重。因为一个集群当中会有很多节点，那么客户端每次写数据的时候，是只向一个节点写入，还是向所有节点写入。
如果向所有节点写入，假设节点个数为 N，那么客户端的一次写请求就会被放大 N 倍，因为每个节点都要写一遍，显然这么做是非常不明智的。因此我们应该让客户端只向一个节点写入，然后该节点再将数据同步给集群内的其它节点。
但这就产生了一个问题，如果某个节点的数据同步还没有完成，就收到了客户端的读请求，那么显然会返回旧数据。如果想让客户端看到的一定是新数据，那么就必须等到数据在所有节点之间都同步完成之后，才能让客户端访问，而这又会造成集群服务出现短暂的不可用。
因此面对这种情况，我们必须要做出取舍，至于如何取舍，CAP 理论会告诉我们答案。它对分布式系统的特性进行了抽象，掌握了 CAP 理论，我们在面对分布式系统的时候就可以做到心中有数。
CAP 理论
CAP 理论对分布式系统的特性做了高度抽象，形成了三个指标：
- 一致性（Consistency）；
- 可用性（Availability）；
- 分区容错性（Partition Tolerance）；
以上这三个指标就称之为 CAP，我们来分别介绍。
一致性，即 CAP 中的 C
一致性说的是客户端的每次读操作，不管访问哪个节点，读到的都是同一份最新的数据（或者读取失败，说明节点之间还在同步数据）。不会出现读不同节点，得到的数据不同这种情况。
所以一致性强调的不是数据完整，而是各节点间的数据一致。
为了更好地理解一致性这个指标，我们举一个键值对存储（比如 Redis）的例子。假设当前有两个节点，里面存储了一个键值对 X = 1。
紧接着，客户端向节点 1 发送写请求 SET X = 2。
如果节点 1 收到写请求后，只将自身的 X 更新为 2，然后返回成功给客户端，那么这个时候节点 2 的 X 还是 1，此时两个节点的数据就是非一致的。
如果节点 1 收到写请求后，不仅自身更新数据，还通过节点间的通讯，将更新操作发送给节点 2，等到自身和节点 2 的 X 都更新为 2 之后，再返回成功给客户端。那么当客户端完成写请求后，两个节点的数据就是一致的了。之后不管客户端访问哪个节点，读取到的都是同一份最新数据。
一致性这个指标，描述的是分布式系统非常重要的一个特性，强调的是数据的一致。也就是说，在客户端看来，访问集群和访问单机是等价的，因为两者在数据一致性上是一样的。
但集群毕竟不是单机，总会有网络故障的时候，那么当节点之间无法通信的时候该怎么办呢？比如节点1在将写请求同步给节点2的时候，发生了网络故障，这时候如果要保证一致性，也就是让客户端访问任何一个节点都能看到相同的数据，那么就应该拒绝服务（客户端读取失败），等到数据同步完成之后再提供服务。否则客户端就可能读到旧数据，比如访问节点 2 的时候，因为网络原因数据还没有同步过来。
因此可以把一致性看成是分布式系统对客户端的一种承诺：不管访问哪个节点，返回的都是绝对一致的数据，因为数据不一致的时候会读取失败（拒绝提供服务）。所以再次强调，一致性强调的不是数据完整，而是各节点之间的数据绝对一致。
但有些服务并不追求数据的一致性，返回旧数据也是可以的。当面对这种场景时，再因为节点间出现了通讯问题（会导致节点间的数据不一致）而拒绝提供服务，就有些不合适了。
这个时候我们就需要牺牲数据的一致性，每个节点使用本地数据来响应客户端请求，保证服务可用。这就是我们要说的另外一个指标，可用性。
可用性，即 CAP 中的 A
可用性说的是任何来自客户端的请求，不管访问哪个节点，都能得到响应数据，但不保证是同一份最新数据。
因此可以把可用性看作是分布式系统对客户端的另一种承诺：尽量返回数据，不会不响应，但不保证每个节点返回的数据都是最新的。因此可用性这个指标强调的是服务可用，但不保证数据的绝对一致。
分区容错性，即 CAP 中的 P
最后的分区容错性说的是，当节点间出现任意数量的消息丢失或高延迟的时候，系统仍然可以继续提供服务。也就是说，分布式系统会告诉客户端：不管我的内部出现什么样的数据同步问题，我会一直运行，提供服务。这个指标，强调的是集群对分区故障的容错能力。
比如当节点 1 和节点 2 通信出问题（发生网络分区）的时候，如果系统仍能提供服务，那么两个节点是满足分区容错性的。而分布式系统与单机系统不同，它涉及到多节点之间的通讯和交互，节点间的分区故障不可能完全避免，所以在分布式系统中分区容错性是必须要考虑的。
CAP 不可能三角
对于一个分布式系统而言，一致性、可用性、分区容错性 3 个指标不可兼得，只能在 3 个指标中选择两个。
我们知道只要有网络交互就一定会有延迟和数据丢失，而这种状况我们必须接受，还必须保证系统不能挂掉。所以就像上面提到的，节点间的分区故障是必然发生的。也就是说，分区容错性（P）是前提，是必须要保证的，不能说某些节点之间无法正常通信（发生网络分区）就导致整个集群不可用。
现在就只剩下一致性（C）和可用性（A）可以选择了：要么选择一致性，保证数据绝对一致；要么选择可用性，保证服务可用。如果选择 C，那么就是 CP 模型；如果选择 A，那么就是 AP 模型。
- 当选择一致性（C）的时候，如果因为消息丢失、延迟过高发生了网络分区，部分节点无法保证特定信息是最新的。那么这个时候，当集群节点接收到来自客户端的请求时，因为无法保证所有节点都是最新信息，所以系统将返回错误，也就是说拒绝请求。
- 当选择可用性（A）的时候，如果发生了网络分区，一些节点将无法返回最新的特定信息，那么它们将返回自己当前相对新的信息。
这里需要再强调一点，有很多人对 CAP 理论有个误解，认为无论在什么情况下，分布式系统都只能在 C 和 A 中选择 1 个。其实在不发生网络分区的情况下，也就是分布式系统正常运行时（这也是系统在绝大部分时候所处的状态），C 和 A 是能够同时保证的（如果节点之间的数据同步很快的话）。只有当发生分区故障的时候，也就是说需要 P 时，才会在 C 和 A 之间做出选择。
CAP 总结
以上就是 CAP 理论的具体内容，以及 CAP 理论的应用，总结如下：
1）CA 模型：
不支持分区容错，只支持一致性和可用性，但这在分布式系统中不存在。因为不支持分区容错性，也就意味着不允许分区异常，设备、网络永远处于理想的可用状态，从而让整个分布式系统满足一致性和可用性。
但分布式系统是由众多节点通过网络通信连接构建的，设备故障、网络异常是客观存在的，而且分布的节点越多，范围越广，出现故障和异常的概率也越大。因此对于分布式系统而言，分区容错性（P）是无法避免的，如果避免了 P，那么只能把分布式系统回退到单机单实例系统。就比如单机版关系型数据库 MySQL，如果 MySQL 要考虑主备或集群部署时，那么它也必须考虑 P。
2）CP 模型：
因为分区容错客观存在，所以放弃系统的可用性，换取一致性。采用 CP 模型的分布式系统，一旦因为消息丢失、延迟过高而发生了网络分区，就会持续阻塞整个服务，直到分区问题解决，才恢复对外服务，这样就可以保证数据的一致性。
选择 CP 一般都是对数据一致性特别敏感，尤其是在支付交易领域，Hbase 等分布式数据库领域，都要优先保证数据的一致性，在出现网络异常时，系统就会暂停服务处理。还有用来分发及订阅元数据的 Zookeeper、Etcd 等等，也是优先保证 CP 的。
3）AP 模型：
由于分区容错 P 客观存在，所以放弃系统的数据一致性，换取可用性。在系统遇到分区异常时，某些节点之间无法通信，数据处于不一致的状态。但为了保证可用性，服务节点在收到用户请求后会立即响应，因此只能返回各自新老不同的数据。
这种舍弃一致性，而保证系统在分区异常下的可用性，在互联网系统中非常常见。比如微博多地部署，如果不同区域出现网络中断，区域内的用户仍然能发微博、相互评论和点赞，但暂时无法看到其它区域用户发布的新微博和互动状态。
还有类似 12306 这种火车购票系统，在节假日高峰期抢票时也会遇到这种情况，明明某车次有余票，但真正点击购买时，却提示说没有余票。就是因为票已经被抢光了，票的可选数量应该更新为 0，但因并发过高导致当前访问的节点还没有来得及更新就提供服务了（和发生网络分区是类似的，都是最新数据还没有同步，就对外提供服务）。因此它返回的是更新之前的旧数据，但其实已经没有票了。
所以相比 CP，采用 AP 模型的分布式系统，更注重服务的高可用。用户访问系统的时候，都能得到响应数据，不会出现响应错误。但当出现分区故障、或者并发量过高导致数据来不及同步时，相同的读操作，访问不同的节点，得到的响应数据可能不一样。典型应用有 Cassandra, DynamoDB, Redis 等 NoSQL。
因此 CAP 理论可以帮助我们思考如何在一致性和可用性之间进行妥协折中，设计出满足场景特点的分布式系统。
最后再提一点，在分布式系统开发中，延迟是非常重要的一个指标。比如名字路由系统，通过延迟评估服务可用性，进行负载均衡和容灾；再比如在 Raft 实现中，通过延迟评估领导者节点的服务可用性，以及决定是否发起领导者选举；再比如类似 Redis 这种查询量非常大的分布式缓存，它的目的是能够快速地返回结果，所以它是 AP 模型。
所以在分布式系统的开发中，要能意识到延迟的重要性，能通过延迟来衡量服务的可用性。总之能否容忍短暂的延迟是关键。
BASE 理论
BASE 理论是 CAP 理论中的 AP 的延伸，所以它强调的是可用性，这个理论广泛应用在大型互联网的后台当中。它的核心思想就是基本可用（Basically Available）和最终一致性（Eventually consistent）。
首先「基本可用」指的是，当分布式系统在出现不可预知的故障时，允许损失部分功能的可用性，来保障核心功能的可用性。说白了就是服务降级，在服务器资源不够、或者说压力过大时，将一些非核心服务暂停，优先保证核心服务的运行。比如：
- 当业务应用访问的是非核心数据（例如电商商品属性）时，拒绝服务，或者直接返回预定义信息、空值或错误信息；当业务应用访问的是核心数据（例如电商商品库存）时，正常查询结果并返回；
- 还可以对用户体验进行降级，比如用小图片来替代原始图片，通过降低图片的清晰度和大小，提升系统的处理能力；
所以基本可用本质上是一种妥协，也就是在出现节点故障或系统过载的时候，通过牺牲非核心功能的可用性，保障核心功能的稳定运行。而手段也有很多，比如服务降级、体验降级、流量削峰、延迟响应、接口限流、服务熔断等等。
然后是最终一致性，它指的是系统中所有的数据副本在经过一段时间的同步后，最终能够达到一致的状态。也就是说在数据一致性上，存在一个短暂的延迟，几乎所有的互联网系统采用的都是最终一致性。比如 12306 买票，票明明卖光了，但还是显示有余票，说明此时数据不一致。但当你在真正购买的时候，又会提示你票卖光了，说明数据最终是一致的。
因此最终一致性应该不难理解，就是节点间的数据存在短暂的不一致，但经过一段时间后，最终会达到一致的状态。所以 BASE 理论除了引入一个基本可用之外，它和 AP 模型本质上没太大区别。
只有对数据有强一致性要求，才考虑 CP 模型或分布式事务，比如：决定系统运行的敏感元数据，需要考虑采用强一致性；与钱有关的支付系统或金融系统的数据，需要考虑采用事务保证一致性。因此，尽管事务型的分布式系统和强一致性的分布式系统，使用起来很方便，不需要考虑太多，就像使用单机系统一样。但是我们要知道，想在分布式系统中实现强一致性，必然会影响可用性。
如果换个角度思考，我们可以将强一致性理解为最终一致性的特例，也就是说可以把强一致性看作是不存在延迟的一致性。因此在实践中我们也可以这样思考：如果业务的某功能无法容忍一致性的延迟（比如分布式锁对应的数据），就需要强一致性；如果能容忍短暂的一致性的延迟（比如APP用户的状态数据），就可以考虑最终一致性。
所以我们之前介绍基于 Redis 实现分布式锁的时候，说过 Redis 在主从切换的时候会出问题，就是因为分布式锁需要的是 CP 模型，而 Redis 是 AP 模型。
小结
BASE 理论是对 CAP 中一致性和可用性权衡的结果，它来源于对大规模互联网分布式系统实践的总结，是基于 CAP 定理逐步演化而来的。它的核心思想是，如果不是必须的话，不推荐使用事务或强一致性，鼓励可用性和性能优先，根据业务的场景特点，来实现非常弹性的基本可用，以及实现数据的最终一致性。
BASE 理论主张通过牺牲部分功能的可用性，实现整体的基本可用，也就是说通过服务降级的方式，努力保障极端情况下的系统可用性。
说到 BASE 理论，应该会有人想到 ACID 理论。ACID 是传统数据库常用的设计理念，追求强一致性模型；而 BASE 理论支持的是大型分布式系统，通过牺牲强一致性获得高可用性。BASE 理论在很大程度上，解决了事务型系统在性能、容错、可用性等方面的痛点。此外 BASE 理论在 NoSQL 中也应用广泛，是 NoSQL 系统设计的理论支撑。
对于任何集群而言，不可预知的故障的最终后果，都是系统过载。如何设计过载保护，实现系统在过载时的基本可用，是开发和运营互联网后台的分布式系统的重点。因此在开发实现分布式系统，要充分考虑如何实现基本可用。
本文参考自：
- 极客时间韩建《分布式协议与算法实战》
