Eureka与Zookeeper

CAP理论

C(Consistency)：一致性

A(Avaliability)：高可用

P(Partition tolerance)：分区容错性

Eureka & Zookeeper

• Eureka强调的是AP，即高可用，分区容错性
• Zookeeper强调的是CP，即一致性，分区容错性

Eureka优势

• Eureka如果某天服务器宕机，eureka不存在类似zookeeper的选举leader解决的过程，eureka知识自动切换到新的eureka节点上，当宕机服务器重新恢复之后，eureka会再次将其纳入集群管理中
• Eureka通过心跳服务淘汰一些异常的服务，如果心跳信息接收异常，会将节点剔除，这样可能存在网络异常时候剔除正常节点情况。
  • 解决办法，如果eureka在短时间丢失大量心跳，你们这个eureka节点会进入自我保护状态，同时保留正常节点和异常节点，等到网络好了之后才推出自我保护状态。以保证高可用
• Eureka还有客户端缓存功能，也就是即使所有eureka节点都失效了，或者网络分割故障导致客户端无法访问到任何一台eureka，客户端也可以通过其缓存的服务列表来获取服务信息。
• Eureka是客户端和服务端配合使用，同时提供心跳服务，监控检测服务，自动刷新缓存功能，如果用zookeeper的话需要自己去实现这些功能，还提供了web-based图形化运维界面，提供第三方介入的rest-ful接口

Zookeeper 劣势

• Zk是基于CP，强调一致性，而不是高可用，所以不保证每次请求的可用性，但是对于server来说，就算返回的是过时的信息也比不返回直接失败要好。
• ZK下的server不会缓存所有服务注册信息，如果节点都断开，或者说zk网络故障，他会把所有节点都剔除，外界就不能访问这些节点信息，即使那些节点可用。
• ZK集群在leader选举的时候如果所有节点没有超过半数择不能选出leader节点，导致集群无法提供服务，
  • 一个3台的集群，挂了一台：收不到一台的投票，但是另外两台可以收到，按照节点选举规则，一个节点得2 票，这个时候 2>(3/2) ,得票数超过半数，可以选出leader节点
  • 挂了两台：只有一个选票，1不大于(3/2)，不能选出leader节点，导致ZK无法提供服务