你知道的越多，不知道的就越多，业余的像一棵小草！
你来，我们一起精进！你不来，我和你的竞争对手一起精进！
编辑：业余草
来源：http://tinyurl.com/y8btadm3
推荐：https://www.xttblog.com/?p=5035
前言
在详解 CAP 定理 Consistency（一致性）、 Availability（可用性）、Partition toleranc中，提到了CAP中只能三者择其二，有CP（一致性+分区容错性）和AP（可用性+分区容错性）两种选择。
一般来说，放弃强一致性，追求分区容错性和可用性，是很多分布式系统设计的选择。在工程实践中，基于CAP定义逐步演化出了Base理论。本文主要对以下两个问题进行介绍：
Base理论有哪些内容？
Base理论下的一致性模型又有哪些？（若文章有不正之处，或难以理解的地方，请多多谅解，欢迎指正）
Base理论
Base理论是三要素的缩写：基本可用（Basically Available）、软状态（Soft-state）、最终一致性（Eventually Consistency）。
可能这三个要素比较抽象，举个栗子吧。
基本可用
相对于CAP理论中可用性的要求：【任何时候，读写都是成功的】，“基本可用”要求系统能够基本运行，一直提供服务，强调的是分布式系统在出现不可预知故障的时候，允许损失部分可用性。
相比于正常的系统，可能是响应时间延长，或者是服务被降级。
举个栗子，在秒杀活动中，如果抢购人数太多，超过了系统的QPS峰值，可能会排队或者提示限流。
软状态
相对于ACID事务中原子性要求【要么做，要么不做】，强调的是强制一致性，要求多个节点的数据副本是一致的，强调数据的一致性。这种原子性可以理解为”硬状态“。
而软状态则允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在不同节点的数据副本上存在数据延时。
举个栗子，CSDN个人主页的粉丝数，如果有用户关注了某个博主，该博主的粉丝数需要过一段时间才会显示正确的数据。
最终一致性，数据不可能一直处于软状态，必须在一个时间期限后达到各个节点的一致性。在期限过后，应当保证所有副本中的数据保持一致性，也就是达到了数据的最终一致性。
在系统设计中，最终一致性实现的时间取决于网络延时、系统负载、不同的存储选型，不同数据复制方案设计等因素。也就是说，谁都不保证用户什么时候能看到更新好的数据，但是总会看到的。
最终一致性要求的多个节点数据副本保持一致性，也是说，在不同机器上是物理时钟保持一致，这就是全局时钟。没有全局时钟，绝对的内部一致性是没有意义的。不同机器上的物理时钟难以同步，导致无法区分在分布式系统中多个节点的事件时序。
既然如此，那么我们只需要所有机器有相同的时间就行了，如果两个节点之间不需要交互，它们的时间甚至都不需要同步。所以我们只要抓住一个重点：达成一致的是节点之间交互的事件发生顺序，而非时间。
所以有很多数据一致性的不同模型。
数据一致性模型
强一致性：当更新操作完成后，任何多个后续进行访问时都会返回最新的值，就是用户刚提交就能看到更新了的数据，这对用户是最友好的。但根据CAP理论，这势必也要牺牲可用性。
弱一致性：系统在写入数据成功后，不承诺立即能读到最新的值，也不承诺什么时候能读到，但是过一段时间之后用户可以看到更新后的值。那么用户读不到最新数据的这段时间被称为“不一致窗口时间”。
根据《分布式CAP理论：为什么CAP理论中的三个指标不能同时满足呢？》并结合 ZooKeeper 框架得知，它采用的是 CAP 理论中的 CP 架构，即追求强一致性和分区容错性。
但其实这并不严谨，因为 ZooKeeper 在写入值之后，会交给 Leader 处理，Zab 协议只需保证半数从节点成功即可，那么这就会有节点数据是老的数据，如此，有可能客户端读出的数据不是最新的数据。而且，因为节点通过 zxid 顺序地接受 Leader 的广播，所以 ZooKeeper 不能保证所有的信息能被马上看到，不过最终都会看到哒。
读到这里，有的读者们可能会想：小编，你是不是在玩我？
且慢！凡事都有但是。想实现 ZooKeeper 读写的强一致性也是可以的。在 ZooKeeper 中有一个 sync() 命令，只要我们每次读的时候调用 sync() 强制同步数据，就可以保证读出的数据都是最新的。
呼，所以 ZooKeeper 虽然默认实现数据的弱一致性，但是也可以通过调整代码，实现数据的强一致性。所以将 ZooKeeper 作为 CP 架构的例子也是可以滴~
最终一致性作为弱一致性中的特例，强调的是所有数据副本，在经过一段时间的同步后，最终能够到达一致的状态，不需要实时保证系统数据的强一致性。而到达最终一致性的时间，其实就是上文提到的不一致窗口时间。
根据业务需求的不同，最终一致性中又有很多种情况：
因果一致性：要求有因果关系的操作顺序得到保证，非因果关系的操作顺序则无所谓。例如微信朋友圈的评论以及对评论的答复所构成的因果关系，有兴趣可以了解一下。
会话一致性：在操作顺序得到保证的前提下，保证用户在同一个会话里读取数据时保证数据是最新的，如分布式系统Session一致性解决方案。
单调读一致性：用户读取某个数据值后，其后续操作不会读取到该数据更早版本的值。
单调写一致性：要求数据的所有副本，以相同的顺序执行所有的更新操作，也称为时间轴一致性。
当然，这里只是简单列出来了一些比较常见的一致性模型，按不完全统计，应该是有15种一致性模型的，有兴趣的朋友可以了解一下。
结语
本文主要是对基于CAP理论的BASE理论进行了介绍，从BASE理论中的最终一致性展开了对不同数据一致性模型的介绍。以下参考资料对于理解这块有较大的帮助，有些可能看不懂，那就收藏起来，等什么时候翻一翻说不一定就看懂了呢~
如果本文对你的学习有帮助，请给一个赞吧，这会是我最大的动力~
