CAP
CAP其实就是Consistency（一致性）Availability（可用性）Partition Tolerence（分区容忍性）的简称
C-Consistency（一致性）
分布式系统中是有很多节点的。而CPA中的 C（Consistency） 就是保证了这些节点的数据的一致性。
如下图所示比如说客户对A节点服务器发情了一个插入一条数据的请求，当插入成功后A服务器告知客户插入成功，同时同步到其他服务器节点。然后客户在B服务器上去进行查询如果查询到了那么就证明是一致性的。如果查询不到那么就是非一致性的。
当然一致性还分为几种，分别是 强一致性、弱一致性、最终一致性
- 强一致性 如上图所示这就是一个强一致性，当数据更新后，后续任何对该数据的读取操作都将得到更新后的值这种情况就被称之为强一致性。
- 弱一致性 当你从一个节点更新数据后谁也不知道他什么时候会同步到其他节点服务器上，你从其他节点服务器上查询到的可能是空值，也可能是以前的值这种情况就被称之为弱一致性。
- 最终一致性 当你在一个节点修改或者写入数据后不会立即的同步到其他节点的服务器上，可能会晚个几十秒或者几分钟。但是最终他会保证其他节点的服务器更新到最新的数据情况，这种就被称之为最终一致性。
A-Availability（可用性）
CPA的A就是指的A-Availability（可用性）。这个可用性很好理解。就是你分布式系统的可用程度，就好比于客户访问你的服务一下子成功了那么他就是可用的，要是一下子访问失败了他就是不可用的，这种不可用的情况的出现就会造成一个系统的可用性程度的降低。
一般而言可用性可以分为 99%、99.9%、99.99%、99.999%
- 99%，一年中只能有80小时左右是可以允许访问失败的
- 99.9%，一年中大概有8小时左右是可以访问失败
- 99.99%，一年中有大概不到1小时是可以访问失败的
- 99.999%，一年中有大概不到5分钟是可以访问失败的 就目前市面上大多数做出来的项目而言其实很多连99%的可用性都没达到。或者大概就是在99%就是一个正常的水平了。而做到99.9%的系统那就是比较厉害的系统了。而做到99.99%甚至99.999%基本上就是业界顶尖水平的系统了。
P-Partition Tolerence（分区容忍性）
CPA中的P就是指P-Partition Tolerence（分区容忍性）the system continues to operate despite arbitrary message loss or failure of part of the system 指分布式系统中可以容忍网络故障造成的异常问题。比如各个节点之间无法互相通讯，不会有非常严重但问题至少不会出现 整套系统崩溃，你哪怕给各个节点发送消息，全部失败，清一色失败，整套系统甚至会宕机的问题。 整套分布式系统各个节点各自为战，该干嘛干嘛，只不过互相之间无法通讯。分布式系统实则还是在运行，只不过你给其他节点发送请求，人家还是会给你一些默认的响应请求。
CAP中的CP和AP
一般来说CAP要么满足CP要么满足AP三者不可同时兼得，因为当系统实现了C-Consistency一致性的时候就不可能获得A-Availability可用性了。而P-Partition Tolerence分区容忍性在分布式系统中是非常重要的。当出现如网络原因造成的分区故障，网络波动、丢包、节点宕机等，保证整套系统的正常运行是非常重要的一点，所以很多分布式系统es，都设计了防止脑裂的机制
CP 一致性 + 分区容忍性
假设出现了网络故障但是因为有P所以保证了系统的运转，但是此时服务器节点之间已经无法互相通信，也就无法同步数据了。
此时客户端要来查询数据，也就是那个id=1name=张三的数据了，此时系统实际上是处于一个不一致的状态，因为各个节点之间的数据是不一样的，如果客户端来查询id=1name=张三这条数据，你要是要保证CP的话，就得返回一个特殊的结果（异常）给客户端任何一个节点此时不接收任何查询的请求，返回一个异常（系统当前处于不一致的状态，无法查询），这样的话呢，客户端是看不到不一致的数据的，但是此时的话，就牺牲掉了A-Availability可用性了，因为此时不让你看到不一致的数据，所以你发送请求过来是返回异常的，请求失败了，此时分布式系统就暂时处于不可用的状态下，也就是保证了CP，就没有了A-Availability可用性了
经典的就是一些分布式存储，比如说zookeeper、mongodb、hbase等等，跟他们都是CP的，也就是说数据100%一致，但是有可能有些时候你请求是失败的，不让你请求到不一致的数据，这就是CP
如果要保证CP的话，C-Consistency一致性，保证说你在任何情况下写入一条数据，接着从任何一个节点去查都可以看到一致的数据，不可能让你一会儿看到旧数据，一会儿看到的是新数据，这样就保证了一致性
AP 可用性 + 分区容忍性
假设出现了网络故障，数据没同步，数据处于不一致的状态下，要保证A-Availability可用性了，你两个节点都要允许任何客户端来查询，都可以查到，这样的话呢，整个系统就处于可用的状态下，但是此时就牺牲掉了C-Consistency一致性。一会儿可以查到id=1name=张三的数据，一会儿从另外一个节点去查又查不到了，这就是对客户端而言，看到了不一致的数据。
在各种分布式系统里面，CAP不可能同时兼得，指的主要是什么呢，就是发生网络故障的时候，可能一些数据没有同步一致性，此时要么就是CP 一致性 + 分区容忍性，要么就是AP 可用性 + 分区容忍性。对于12306，或者电商平台这种项目一般就是AP 可用性 + 分区容忍性，也就是你看到的商品库存或者火车票的库存是错误的。是老数据，看到的数据就可能是不一致的。比如说你去购买商品，你还是能将某一个商品加入购物车，但是在结算下单的时候他一定是会去进行库存查询的。比如秒杀时你看到的数量还有1000个但是你下单购买的时候他去检查库存的时候发现库存已经为0了你也就无法购买了。
BASE
所谓的BASE，Basicly Available、Soft State、Eventual Consistency，也就是基本可用、软状态、最终一致性。BASE希望的是，CAP里面基本都可以同时实现，但是不要求同时全部100%完美的实现，CAP三者同时基本实现，BASE，基本可用、最终一致性
Basicly Availabl 基本可用
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，正常情况下，是查询可以负载均衡到各个节点去查的，也就是可以多节点抗高并发查询，但是此时如果你要降级的话，可以降级为，所有客户端强制查询主节点，这样看到的数据暂时而言都是一样的，都是从主节点去查。但是因为客户端访问量太大了，同时用一个主节点来支撑很坑，扛不住，此时就需要对主节点做限流降级，也就是说如果流量太大了，直接返回一个空，让你稍后再来查询。这样也就保证的就是所谓的基本可用，降级的措施在里面了，跟正常的可用是不一样的，比正常的可用要差一些，但是还是基本可以用的。例如：电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
Soft State 软状态
软状态是指允许多个节点在同步数据，在一段时间内，可能每个节点数据不一致，正在同步过程中，这个就是软状态。例如你查询几个节点，有的可以查询出id=1name=张三的这个数据，但是有的又查询不到。也就造成了会看到不一致状态，这个不一致的状态，就是指的是BASE中的soft state 软状态
Eventual Consistency 最终一致性
最终一致性指的是一旦故障或者延迟解决了，数据过了一段时间最终一定是可以同步到其他节点的，数据最终一定是可以处于一致性的，虽然存在软状态，但是最终还是会变成一致的。
