CAP与BASE 脑裂

CAP

 在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这3个基本需求，最多只能同时满足其中的2个。

分区容错性（必须满足）

网络分区故障

在分布式集群中，节点之间由于网络不通，导致集群中节点形成不同的子集，子集中节点间的网络相通，而子集和子集间网络不通。网络分区是子集与子集之间在网络上相互隔离了

分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障 。

 分区容错的前提下，一致性和可用性是矛盾的

        多个分区同步完成后：才能一致性

        可用性：时刻都能用

Cp

 选举过程短暂对外不可用

AP

Zookeeper保证CP

        假如1号机注册给server1,server1同步给server2,server2同步给各个follower,为了保证一致性，只有整个过程都成功了，1号机才收到注册成功。

        当leader重启或者网络故障下，整个ZK集群会重新选举新老大，选举期间client不可注册，即k不可用，所以牺牲了可用性A。只有选举出新老大后，系统才恢注册。故z水为了保证数据一致性牺牲了可靠性。由于在大型分布式系统中故障难以避免，leader!出故障可能性很高，所以很多大型系统都不会选择k的原因。

Eureka保证AP

        优先保证可用性。Euraka各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka客户端在向某个Eureaka注册时如果发现来连接失败，则会自动切换其它节点，只要有一台Eureka还在，就能保证注册服务可用，只不过查询到的信息不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟之内超过85%的节点都没有正常心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1：Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务

2：Eureka仍然能够接受新服务的注册和查询请求，但是不会同步到其他的节点上（保证当前节点可用）

3：当网络稳定时，当前实例新的注册信息会被同步到其他节点中

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

Redis单机是CP  

Redis集群 AP

redis异步复制造成的锁丢失

主节点没来的及把刚刚set进来这条数据给从节点，master就挂了

BASE

        BASE（Basically Available、Soft state、Eventual consistency）是基于CAP理论逐步演化而来的，核心思想是即便不能达到强一致性（Strong consistency），也可以根据应用特点采用适当的方式来达到最终一致性（Eventual consistency）的效果。

Basically Available（基本可用）

假设系统出现了不可预知的故障，但还是能用，只是相比较正常的系统而言，可能会有响应时间上的损失，或者功能上的降级。

Soft State（软状态）

什么是硬状态呢？要求多个节点的数据副本都是一致的，这是一种“硬状态”。

软状态也称为弱状态，相比较硬状态而言，允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

Eventually Consistent（最终一致性）

上面说了软状态，但是不应该一直都是软状态。在一定时间后，应该到达一个最终的状态，保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间取决于网络延时、系统负载、数据复制方案设计等等因素。

脑裂

在一个高可用系统中，当联系着的节点因为网络连接断开联系时，本来为一个整体的系统，分裂成两个独立节点，两个节点开始争抢共享资源造成系统混乱、数据损坏的现象，成为“脑裂”。

列如：FollowerA由于网络问题感知不到Leader存在，FollowerA与FollowerB之间是相连的，此时FollowerA会发起选举，虽然 FollowerB能够感知到 Leader，但由于其接收到了更大 term 的投票请求，所以 FollowerB也就放弃了Leader，参与了新 Leader 的选举。新Leader的写请求并不会同步到原Leader节点上。而之前的Leader由于无法获取过半响应而无法处理写操作请求，不过并没有被Down，其仍为 Leader。所以之前Leader的数据是不会发生变更的。此时就形成了数据的不一致。

解决方案：通过时间续约和term比较最终旧leader被同步为follower。

解决方案（投票）

解决方案(Lease机制)