001分布式的基础理论CAP

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

选项	描述
Consistency（一致性）	数据在多个副本之间能够保持一致的特性（严格的一致性）
Availability（可用性）	系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应（不保证获取的数据为最新数据）
Partition tolerance（分区容错性）	分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障

分区容错性（必须满足）

网络分区故障

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

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

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

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

        可用性：时刻都能用

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就挂了