在一个分布式系统中,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就挂了