1、CAP是什么
- C：Consistency（强一致性），在分布式系统中的所有数据备份，在同一时刻是否同样的值（等同于所有节点访问同一份最新的数据副本）。
- A：Avaliability（可用性），在集群中一部分节点故障后，集群整体是否还能相应客户端的读写请求（对数据更新具备高可用性）。
- P：Partition tolerance（分区容错性），以实际效果而言，分区相当于对通信的时限要求，系统如果不能在时限内达成数据一致，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
2、什么是CAP的3进2
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个
因此，根据CAP原理将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则的三大类：
-
CA-单点集群，满足一致性，可用性的系统，通常在可扩展上不太强大（如传统MySQL、Oracle）
如果不要求P（允许分区），则C和A都是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。
-
CP-满足一致性，分区容错性的系统，通常性能不是特别高（如Redis、mongoDB）
如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致性，而P会导致同步时间无线延长（也就是等待数据同步完才能正常访问服务），一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis，HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好了，没必要再浪费资源来部署分布式数据库。
-
AP-满足可用性，分区容错性的系统，通常对一致性要求低一些（大多数网站架构的选择）
要求高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是现在A方面保证系统可以提供正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。
- 数据库事务一致性需求：
很多Web实时系统并不要求严格的数据库事务，对读写一致性的要求很低，有些场合对写一致性要求并不高，允许实现最终一致性
-
数据库的写实时性和读实时性需求：
对关系型数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多Web的应用说，并不要求这个高的实时性，比方说发一条消息之后，或几秒乃至几十秒之后，我的订阅者才看到这条动态是完全可以接受的
-
对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
3、BASE是什么
BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案，即对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP理论逐步演化而来的。
BASE其实是有下面三个术语的缩写：
- 基本可用（Basic Avaliable）
- 软状态（Soft state）
- 最终一致（Eventually consistent）
它的思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性（Eventually consistent）。
通过让系统放松对某一时间数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢？缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，想要获得这些指标，我们必须采用另外一种方式完成，这里BASE就是解决这个问题的办法。
3.1 基本可用
基本可用是指分布式系统在出现了不可预知故障的时候，允许损失部分可用性--但请注意，这就不等价于系统不可用，一下两个就是“基本可用”的典型例子：
- 响应时间上的损失：正常情况下，一个在线收缩引擎需要0.5秒内返回给用户相应的查询结果，但由于出现不可预知的异常（比如系统部分机房发生断电或者断网故障），查询结果的响应时间增加到了1~2秒。
- 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
弱状态也称为软状态，和硬状态相对，是指允许系统中数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
3.2 最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
马亚逊首席技术官Werner Vogels在于2008年发表的一篇文章中对最终一致性进行了非常详细的介绍。他认为最终一致性是一种特殊的弱一致性：系统能够保证在没有其他新的更新操作下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够获取到最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟，系统负载和数据复制方案设计的因素。
在实际工程实践中，最终一致性存在以下五类主要变种：
-
因果一致性：
因果一致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最新值，即不能发生丢失更新情况，与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。
-
读己之所写：
读己之所写是指，进程A更新一个数据项之后，他自己总是能后访问到更新过的最新值，而不会看到旧值。也就是说对于单个数据获取者而言，其读取到的数据一定不会比自己上次写入的值旧。因此，读己之所写也可以看做是一种特殊的因果一致性。
-
会话一致性：
会话一致性将对系统数据的访问过程框定在一个会话中：系统能保证在同一个有效的会话中实现”读己之所写“的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中适中读取到该项数据项的最新值。
-
单调读一致性：
单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任务数据访问都不应该返回更旧的值。
-
单调写一致性：
单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序的执行
以上就是最终一致性的五类常见的变种，在时间系统实践中，可以将其的若干个变种互相结合起来，以构建一个具有最终一致性的分布式系统。事实上，最终一致性并不是只有那些大型分布式系统才设计的特性，许多现代的关系型数据库都采用了最终一致性模型。如Redis等，大多都会采用同步和异步的方式来实现主备数据复制技术。在同步方式中，数据的复制通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新往往存在延迟，这取决于事务日志在主备数据库之间的传输时间的长短，如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上，那么很显然，从备库中读取的数据将是旧的，因此就会导致不一致的情况。当然，不论是采用多次重试还是认为数据订正，关系型数据库还是能够保证数据最终一致性--这就是系统提供最终一致性保证的经典案例。
总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性是相反的，他完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获取高可用的指标，并允许数据在一段时间内是不一致的，但最终达到一致性的状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构的设计过程中，ACID特性与BASE理论往往又会结合在一起使用。