上一篇：SpringCloud—(3)实现Eureka的高可用
Eureka和Zookeeper最主要的区别来看就是他们关注的点不一样，所以满足的原则不一样。
著名的CAP原则提出：一个分布式系统中一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）很难三者兼顾，三个要素最多只能满足其中两个。
Zookeeper（CP原则）
Zookeeper使用的是CP原则，保证了一致性和容错性。
我们都知道，zookeeper有主从节点，当主节点master挂掉了之后，剩下的节点就会开会推举一个新的leader出来继位为主节点。但是选举是需要一定的时间的（30s~120s），选举期间zookeeper集群无法使用，这样就直接牺牲掉了可用性，
Eureka（AP原则）
Eureka使用的是AP原则，保证了可用性和容错性。
Eureka和Zookeeper有所不同，Eureka中的各个节点都是同级平等的，就算是其中的几个节点无法使用，也不会影响到其他的的节点正常工作。Eureka的客户端在向服务端进行注册的时候，如果服务端无法使用，则可以自动的切换到其他的服务上去，不会产生影响。只要还有一台Eureka能工作，就可以保证服务的可用性。
Eureka还具备自我保护机制，如果在15分钟以内，超过85%的节点返回没有正常的心跳，那么Eureka就会认为是客户端和注册中心出现了网络故障。此时：
1）Eureka不会再从服务注册表中删除掉没有正常心跳的服务。
2）Eureka仍然可以接收新服务的注册和查询，但是不会被同步到其他的节点上，保证当前的节点可以使用。
3）当网络恢复的时候，当前实例新的注册信息会被同步到其他节点。之前没有收到正常心跳的服务重新连接之后恢复正常使用。
Eureka在网络故障的时候做出以上应对之后，能够极大保证服务的可用性。
