|
Spring Cloud Eureka与Zookeeper对比，明显的区别可能就是Zookeeper为CP设计，而Eureka为AP设计，但是对CAP/AP/CP很不理解，于是查阅资料，做一个简单的了解
1、Zookeeper当master挂了，会在30-120s进行leader选举，这点类似于redis的哨兵机制，在选举期间Zookeeper是不可用的，这么长时间不能进行服务注册，是无法忍受的，别说30s，5s都不能忍受。这时Zookeeper集群会瘫痪，这也是Zookeeper的CP，保持节点的一致性，牺牲了A/高可用。而Eureka不会，即使Eureka有部分挂掉，还有其他节点可以使用的，他们保持平级的关系，只不过信息有可能不一致，这就是AP，牺牲了C/一致性。
2、Eureka（尤里卡）有自我保护机制（15分钟内超过85%的服务节点没有心跳/down），这点我觉得确实要比Zookeeper好，即使服务不可用，也会保留当前失效的微服务，默认90秒，在这90秒Eureka不会注销微服务，在这90秒内仍然可以接受新的服务注册，只是不会同步到其他节点上。当坏掉的服务恢复的时候，会自动加入到节点上，也是高可用的一种。然后退出自我保护机制，这也是应对网络异常的一种机制
总结：Zookeeper出现网络等故障的时候导致整个服务注册瘫痪太要命了。Eureka能很好的应对网络故障导致失去节点的情况。
Eureka：AP架构设计(高可用、分区容错性)，Zookeeper：CP架构设计（一致性、分区容错性）
? ? ? 那什么是AP、什么是CP，这个就是关于分布式的CAP理论（面试题）:
? ? ? C - Consistent-一致性 ? ? ? ? ? A - Availability-可用性 ? ? ?P - Partition tolerance -分区容错性
? ? ? 分布式系统之所以叫分布式，是因为提供服务的各个节点分布在不同机器上，相互之间通过网络交互。那么必然存在网络故障断开的风险，这个网络断开的专业场景成为网络分区。网络分区多个分布式节点无法进行通信，我们对于一个节点无法操作到另外一个节点，数据的一致性没办法满足，因为多节点的数据不再保持一致。如果要保持一致，我们必然要牺牲高可用，也就是需要暂停一部分的服务，不提供对数据的操作(修改、更新等)功能，等到网络恢复的时候再对外服务。当然也可以保证高可用，牺牲数据一致性
? ? ?关于CAP理论大概的结论:在网络分区时，不能同时保证高可用和一致性
? ? ?目前任何分布式系统都没办法同时满足3个，只能3选其2，分布式系统之所以叫分布式，都是分散在不同的服务器，P是必须要满足的，所以只能选择A或者C了
? ? ?在很多的公司以及业务场景，很多会选择保持数据的一致性，在京东/双十一这样的情况，只能保证AP，不能保证CP。但也有高可用的.比如某米公司，一次在进行手机抢购的时候，牺牲了数据的一致性，当添加到购物车，然后付款，却发现没有库存了，他保证了服务高可用，但牺牲了数据的一致性
?
|