没有十全十美的分布式系统，分布式的痛点就在于各个节点状态的统一，CAP和BASE便是描述它的状态。
本文中分布式系统的阐释
本文中的分布式系统不仅指一套全是无状态的应用的服务系统，单纯依靠共享资源（如多个无状态的服务共用数据库或NoSQL而不在内存或是本身的服务容器中存储任何数据）运转的服务不是纯粹的分布式系统，分布式系统中一般需要包含有状态的服务（如主从同步的Mysql、多机哨兵模式的Redis、设置会话共享的分布式Tomcat服务）。
图A 分布式架构雏形
（ 试想在上图中，若是网关通过A分区对数据做出了修改，此时还没有写入数据库但是A分区的缓存做出了调整，在分区容错的情况下A不能直接与B通信，那A与B分区就会失去一致性。）
数据一致性的级别
一致性也是有高下之分的：
强一致性：表示数据一经修改，所有新度的数据都是被修改过的，最新的
弱一致性：弱一致性不是一致性的保障，而是有一致性的相关操作，但是不对一致结果和达成时间做出任何承诺
最终一致性：介于强一致性和弱一致性之间，是弱一致性的范畴，承诺最终能保障一致性但不承诺会在非常短暂的时间内达成一致性
CAP
CAP，分别表示分布式系统的三个指标：C为Consistency，即一致性；A为Availability，即可用性；P为Partition tolerance，即分区容错性，就分布式系统的特点来说，不可能兼顾所有的特性，三者最多只能保障其二，接下来逐一介绍三个特性。
C
C为一致性，与数据库层面的一致性含义类似。当对一台服务器改变状态时，分布式系统中的其他服务器能第一时间作出改变，从而在所有服务器中此状态是一致的。为满足一致性，数据的实时同步是不可少的。
A
A为可用性，当一个系统或一个节点在某个时间点不可用（访问无响应、超时等），便不具备可用性。
P
P为分区容错性，P相比之下较难理解，P表示分区（例如一套服务部署在两片节点或是局域网下，就是两个区）之间会有通信失败的情况（例如比较常见的网络延迟、网络故障）。当系统满足分区容错性时表示系统可以接受这种情况的发生，且不会有逻辑问题。然而对于分布式系统，这种情况是难以避免的不可抗力，因此一个标准的分布式系统，必须满足分区容错性。
CAP的抉择
了解CAP后，我们知道P是必须满足的，因此我们的选择就剩下了AP和CP，一切讨论也都是基于发生了分区异常、分区间通信失败的情况，放服务间通信有问题时。选择CP就是为了保证一致性，在故障期间服务不可用，直到网络恢复才能让服务可用并且恢复在故障期间的状态修改；选择AP就是为了保证可用性，在网络故障期间不更新状态，但是服务可用。
AP的简单实现（假定内存总有数据缓存），在1-2阶段间分区B读到的是旧数据，不具有强一致性
CP的简单实现，若是分区B被阻塞，在1-4阶段分区B的接口会等待或超时，直到数据更新结束
实际情况下没有孰好孰坏，需要根据具体业务选择符合相应特性的技术栈，譬如在数据实时性要求不高的系统中可以选择AP。
BASE
后续发展中，特性逐渐由CAP演进为BASE，BASE指：BA为Basically Available，即基本可用；S为Soft State，即软状态；E为Eventually consistent，即最终一致性。不同于CAP强一致性的要求，BASE强调的是最终一致。BASE原则可以使用与大多数的分布式系统，也是当下分布式系统追求的状态。
BA
BA为基本可用，指允许有网络延迟或是访问降级的情况，但是在正常提供的过程中不可以出现访问超时或请求失败。
S
S为软状态，是介于状态改变的中间态，BASE系统允许软状态的存在，但是他不应对系统基本可用性造成影响，可以说基本可用是软状态的一种表现形式。
E
E为最终一致性，不像C那样实时一致，而是在不影响可用的前提下达成最终一致。
总结：事务一致性和用户体验的权衡
不难发现，无论一个分布式系统选取怎样的设计，最终都是在用户体验和事务性间寻求一个平衡。在有限的资源下，越是追求一致性，就越要牺牲瞬时的可用性，例如对事务强一致性要求极高的支付系统绝不可能将软状态展现给用户或是采用AP原则，相应的就要牺牲用户支付等待的时间；而微博的热搜榜单涉及计算量很大，并且可能要有人工干涉，对时间精确要求却不是很高，可能此时刻更新的只是20秒之前的热搜统计，但是并不有碍任何用户体验。需要注意的是，有少数系统的设计是弱一致性而优先性能的，即认同一定程度的数据不稳定，这种毕竟是少数，此文不予讨论。所以在实际开发中，应仔细权衡我们开发真正的诉求。
参考链接：CAP定理的含义-阮一峰的网络日志
2019-09-29鱼鱼