分布式CAP、一致性模型、BASE

CAP：
一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
一致性：从不同数据副本，读到的数据一致。
    强一致性：读到的数据一致。
    弱一致性：读到的数据可能一致。
    最终一致性：一段时间后，读到的数据一致。
可用性：操作是否能完成。如：发出请求后，是否能得到正常的响应。
分区容错性：

一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。

当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。

提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。

然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。

总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。

分布式中，想满足一致性，那么必须等待数据同步，在数据同步期间不满足可用；想满足可用性，就不能等待数据同步完成，不能满足一致性。
分布式中，一致性和可用性无法同时满足，所以最多只能满足CP或者AP。如果满足了CA，不满足P，就不是分布式了。

强一致性模型：
Strict Consistency（严格一致）：关系数据库
Linearizable Consistency（线性一致）
Sequential Consistency（连续一致）
弱一致性模型：
Causal Consistency（因果一致）：如：微信朋友圈回复。
Eventual Consistency（最终一致）：如：Mysql异步复制。

https://www.cnblogs.com/hzmark/p/consistency_model.html
http://loopjump.com/distributed_consistency_model/

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）。
基本可用：损失部分可用性。
如：
    响应延迟：在线搜索的结果返回从0.5秒延迟到1到2秒。
    服务降级：购物高峰，点击购买，部分消费者被引导到一个降级页面：服务器繁忙，请稍后重试。
软状态：允许数据同步延迟。    

ACID是传统数据库常用的设计理念，追求强一致性模型。BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

ACID和BASE代表了两种截然相反的设计哲学。

在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此ACID和BASE又会结合使用。

以订单场景中订单系统和积分系统为例，订单表更新后，可以MQ方式更新积分，MQ消费前短暂不一致，也就是软状态；不影响下单展示，基本可用；MQ消费成功后， 最终一致。

又比如：安全系统更新后，MQ方式同步客服系统。 

MySQL主从复制，全同步是强一致，异步是高可用，半同步是一个平衡。