可以先看这篇：https://www.cnblogs.com/szlbm/p/5588543.html

说 CAP、BASE 理论之前，先要了解下分布式一致性的这个问题
实际上，对于不同业务的产品，我们对数据一致性的要求是不一样的，比如 12306，他要求的是数据的严格一致性，不能说把票卖给用户以后发现没有座位了；比如银行转账，你们通过银行转账的时候，一般会收到一个提示：转账申请将会在 24 小时内到账；实际上这个场景满足的是最终钱只要汇出去了即可，同时以及如果钱没汇出去要保证资金不丢失就行；所以说，用户在使用不同的产品的时候对数据一致性的要求是不一样的

1.关于分布式一致性问题

在分布式系统中要解决的一个重要问题就是数据的复制。在我们的日常开发经验中，相信很多开发人员都遇到过这样的问题：在做数据库读写分离的场景中，假设客户端 C1将系统中的一个值 K 由 V1 更新为 V2，但客户端 C2 无法立即读取到 K 的最新值，需要在一段时间之后才能 读取到。这很正常，因为数据库复制之间存在延时。

所谓的分布式一致性问题，是指在分布式环境中引入数据复制机制之后，不同数据节点之间可能出现的，并无法依靠计算机应用程序自身解决的数据不一致的情况。简单讲，数据一致性就是指在对一个副本数据进行更新的时候，必须确保也能够更新其他的副本，否则不同副本之间的数据将不一致。

那么如何去解决这个问题？按照正常的思路，我们可能会想，既然是因为网络延迟导致的问题，那么我们可以把同步动作进行阻塞，用户 2 在查询的时候必须要等到数据同步完成以后再来做。但是这个方案带来的问题是性能会收到非常大的影响。如果同步的数据比较多或者比较频繁，

那么因为阻塞操作可能将导致整个新系统不可用的情况；总结： 所以我们没有办法找到一种能够满足数据一致性、又不影响系统运行的性能的方案，所以这个地方就诞生了一个一致性的级别：

• 强一致性：这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大

• 弱一致性：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不具体承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态

• 最终一致性：最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较用的多的模型

2.CAP 理论

一个经典的分布式系统理论。CAP 理论告诉我们：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中两项。CAP 理论在互联网界有着广泛的知名度，也被称为“帽子理论”，它是由 Eric Brewer 教授在 2000 年举行的 ACM 研讨会提出的一个著名猜想：
一致性（Consistency）、可用性（Availability）、分区容错（Partition-tolerance）三者无法在分布式系统中同时被满足，并且最多只能满足两个！

• 一致性：所有节点上的数据时刻保持同步

• 可用性：每个请求都能接收一个响应，无论响应成功或失败

• 分区容错：系统应该持续提供服务，即时系统内部（某个节点分区）有消息丢失。比如交换机失败、网址网络被分成几个子网，形成脑裂；服务器发生网络延迟或死机，导致某些 server 与集群中的其他机器失去联系分区是导致分布式系统可靠性问题的固有特性，从本质上来看，CAP 理论的准确描述不应该是从 3 个特性中选取两个，所以我们只能被迫适应，根本没有选择权；

总结一下：CAP 并不是一个普适性原理和指导思想，它仅适用于原子读写的 NoSql 场景中，并不适用于数据库系统。

3.BASE 理论

从前面的分析中知道：在分布式（数据库分片或分库存在的多个实例上）系统下，CAP 理论并不适合数据库事务（因为更新一些错误的数据而导致的失败，无论使用什么样的高可用方案都是徒劳，因为数据发生了无法修正的错误）。此外分布式事务XA 虽然保证了数据库在分布式系统下的ACID（原子性、一致性、隔离性、持久性）特性，但也带来了一些性能方面的代价，对于并发和响应时间要求比较高的电商平台来说，是很难接受的。
eBay 尝试了另外一条完全不同的路，放宽了数据库事务的ACID 要求，提出了一套名为 BASE 的新准则。BASE 全称是 Basically available,soft-state,Eventually Consistent. 系统基本可用、软状态、数据最终一致性。相对于 CAP 来说，它大大降低了我们对系统的要求。

• Basically available（基本可用），在分布式系统出现不可预知的故障时，允许瞬时部分可用性
  　1. 相应时间上的损失：比如我们在淘宝上搜索商品，正常情况下是在 0.5s 内返回查询结果，但是由于后端的系统故障导致查询响应时间变成了 2s
  　2.功能上的损失： 电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现

• soft-state（软状态） 表示系统中的数据存在中间状态，并且这个中间状态的存在不会影响系统的整体可用性，也就是表示系统允许在不同节点的数据副本之间进行数据同步过程中存在延时；比如订单状态，有一个待支付、支付中、支付成功、支付失败， 那么支付中就是一个中间状态，这个中间状态在支付成功以后，在支付表中的状态同步给订单状态之前，中间会存在一个时间内的不一致。

• Eventually consistent（数据的最终一致性），表示的是所有数据副本在一段时间的同步后最终都能达到一个一直的状态，因此最终一致性的本质是要保证数据最终达到一直，而不需要实时保证系统数据的强一致

BASE 理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性