系统的数据一致性到底是在说什么？我到今天才算真明白了( 四 ) _数据一致性

CAP理论的缺点是什么？
CAP理论其实是有缺点的，前文也提到一些，具体的缺点如下：

理论忽略网络延迟、节点处理数据的速度

CAP的理论的作者布鲁尔在定义一致性时，并没有将上述的问题考虑进去。即当事务提交之后，数据能够瞬间复制到所有节点。但实际情况下，数据从产生到复制到各个服务、各个节点，总是需要花费一定时间的。如果在相同机房可能是几毫秒，如果跨地域、跨机房，可能是几十毫秒甚至是一百多毫秒。这也就是说， CAP理论中的C在实践中是不可能完美实现的，在数据副本的同步的过程中，节点之间的数据在一个短时间内并不一致。

理论中的一致性是强一致性

CAP理论中的一致性的概念是，在分布式系统中的所有数据备份，在同一时刻是否同样的值，也就是等同于所有节点访问同一份最新的数据副本。在某些场景下这种强一致性要求并不是那么高。在一个日志搜集系统，在高并发、大数据的情况下，一条日志写入需要稍后一会才能在ELK中展示出来，这样是没有问题的。通过牺牲强一致性获得可用性，在一定时间之后最终数据达成一致性即可。

理论中的指标的选择和放弃并不是三选二的关系

CAP理论告诉我们三者只能取两个，需要放弃另外一个，这里的放弃是有一定误导作用的，因为“放弃”让很多人理解成什么也不做。实际上， CAP理论的“放弃”只是说在系统分区错误过程中，我们无法同时保证C和A ，但并不意味着什么都不做。分区期间放弃C或者A ，并不意味着永远放弃C和A ，我们可以在分区期间进行一些操作，从而让分区故障解决后，系统能够重新达到CA的状态。最典型的就是主从数据库中主数据挂了，后面进行修复，使得重新达到CA状态。
CAP理论的改进版BASE理论
由于CAP理论在定义时过于的乐观，导致他有些缺陷，于是又有大神改进了CAP理论，从而引申出理论改进版本：BASE理论。eBay的架构师Dan Pritchett根据他自身在大规模分布式系统的实践经验，提出了BASE理论。BASE理论是对CAP理论的延伸和补充，它满足CAP理论，通过牺牲强一致性获得可用性，在一定的时间窗口内，达到数据的最终一致性。
BASE理论模型包含如下三个元素：

BA：Basically Available ，基本可用。
S：Soft State,软状态，状态可以在一定时间内不同步。
E：Eventually Consistent ，最终一致性，在一定的时间窗口内，最终数据达成一致即可。

Basically Available 基本可用
BASE理论中的Basically Available 基本可用，就是系统在出现问题的时候，牺牲一部分的功能，来保障核心功能正常。这其实就是一种妥协，相当于壁虎断臂求生。就像前几年的双十一淘宝，订单支付、退款直接崩掉了，后面就进行改进限流需要你多试几次才能付款、退款，再后来双十一那几天是不能申请退款的，直接就把你这个功能给关闭了，相当于服务熔断了。这就是牺牲非核心的功能，将所有的资源都用来保障核心的支付功能。
Soft State,软状态
允许系统在一定时间内的状态不同步，允许系统处于软状态，这个软状态其实就是中间状态。比如采用分布式架构的电商系统，用户下单完成并付款，是否支付成功，是支付系统完成的，订单系统不会等支付系统返回是否支付成功再把结果返回给客户的，而是先把订单状态设置为付款中，返回给客户，然后支付系统收到异步通知确定支付成功成功，再把状态设置为付款完成，再把付款完成信息推送给订单系统。这样，就可以提高系统的响应速度。即使这支付系统出现故障宕机了，系统重启之后可以通过定时任务补偿处理未完成的数据，然后根据数据所处的状态进行补偿处理，最终完成数据处理。付款中这个状态，就是软状态即中间状态。