Eureka和Zookeeper有哪些区别

Zookeeper 和 Eureka 都是服务发现框架，它们在分布式系统中扮演着重要的角色，但它们之间存在一些关键的区别：

1. 设计原则：

• Zookeeper 遵循 CP 原则，即在网络分区发生时，它保证一致性（Consistency）和分区容忍性（Partition tolerance），但不保证可用性（Availability）。Zookeeper 通常用作分布式同步服务，它通过复杂的一致性协议（如 ZAB 协议）来保证数据的一致性。

• Eureka 遵循 AP 原则，即在网络分区发生时，它保证可用性（Availability）和分区容忍性（Partition tolerance），但不保证一致性（Consistency）。Eureka 通过快速响应客户端的请求，即使在网络分区的情况下也能提供服务，但可能返回的是过时的信息。

2. 使用场景：

• Zookeeper 常用于分布式协调、分布式锁、配置管理等场景，它为 Hadoop、Hbase、Kafka 等知名分布式系统提供支持。

• Eureka 主要用于服务发现，它是 Spring Cloud 体系中的核心组件之一，与 Spring Boot 微服务应用框架紧密集成，提供服务注册与发现的功能。

3. 架构特点：

• Zookeeper 是一个树形结构的命名空间，具有持久节点和临时节点，支持观察者模式，可以监听节点变化。

• Eureka 采用客户端-服务器模型，客户端作为服务实例向 Eureka 服务器注册自己的信息，并且定期发送心跳以续约，Eureka 服务器提供服务注册信息的查询和同步。

4. 一致性与可用性：

• Zookeeper 强调数据的强一致性，适合需要严格一致性要求的场景。

• Eureka 更注重服务的可用性，适合对数据一致性要求不是极高的场景，允许一定程度的数据过时。

5. 容错能力：

• Zookeeper 通过集群模式提高容错能力，但单个节点故障会影响整个集群的服务。

• Eureka 通过区域感知和自我保护机制提高容错能力，即使部分节点故障，也能保持服务的可用性。

6. 易用性：

• Zookeeper 提供了丰富的 API，但学习曲线相对较陡。

• Eureka 提供了简单的 API 和 UI 界面，易于使用和集成到 Spring Boot 应用中。

7. 维护成本：

• Zookeeper 作为一个通用的分布式协调服务，可能需要更多的维护工作。

• Eureka 作为 Spring Cloud 生态系统的一部分，维护相对简单，但可能需要解决依赖性问题。

Eureka的实现

Eureka的架构图如下所示，Eureka Server可以部署在不同的区域，比如北京、上海、深圳，Server之间进行副本数据的同步。只要有一台服务可用，就能对外提供服务。

Eureka保证的是AP。

服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步。

当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。

服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。

Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。

说到这里，那么就不得不说一下Eureka的自我保护机制。那么什么是Eureka的自我保护机制呢？

在默认配置中，Eureka Server在默认90s没有得到客户端的心跳，则注销该实例，但是往往因为微服务跨进程调用，网络通信往往会面临着各种问题。

比如微服务状态正常，但是因为网络分区故障时，Eureka Server将会注销大量的网络不可达的服务，这很危险，因为注册的服务本身没有问题。

Eureka 的自我保护机制，可以通过在Eureka Server配置如下参数，可启动保护机制。

eureka.server.enable-self-preservation=true

 它的原理是，当Eureka Server节点在短时间内丢失过多的客户端时（可能发送了网络故障），那么这个节点将进入自我保护模式，不再注销任何微服务，当网络故障回复后，该节点会自动退出自我保护模式。

Zookeeper的实现

Zookeeper 为主从结构，有leader节点和follow节点。当leader节点down掉之后，剩余节点会重新进行选举。

选举过程中，服务是不可用的，zk选择的是CP。

选举过程中会导致服务不可用，选举完成后会进行数据同步，半数以上服务可用后才会对外提供服务。

说到这里，我们也不得不说一下Zookeeper的选举机制。 

ZK 集群的选举机制

我们就拿 3 个节点的 zk 作一个简单选举的说明。

zk 会进行多轮的投票，直到某一个节点的票数大于或等于半数以上，在 3 个节点中，总共会进行 2 轮的投票：

• 第一轮，每个节点启动时投票给自己，那这样 zk1，zk2，zk3 各有一票。

• 第二轮，每个节点投票给大于自己 myid，那这样 zk2 启动时又获得一票。加上自己给自己投的那一票。总共有 2 票。2 票大于了当前节点总数的半数，所以投票终止。zk2 当选 leader。

有的童鞋会问，zk3 呢，因为 zk2 已经当选了，投票终止了，以上就是zk的选举机制。

 Eureka和Zookeeper的区别

好了，到这里我们来做个总结：

• Eureka是基于AP，而Zookeeper是居于CP

• Eureka网络不可达时进行自我保护

• Eureka只要有一个节点可用都可以正常使用

• Zookeeper的leader挂了进行选主，服务不可用

• Eureka可以很好的应对因网络故障导致部分节点失去联系的情况