了解Zookeeper、和eureka的区别

最新推荐文章于 2024-08-23 14:53:54 发布

陈皮话梅糖。

最新推荐文章于 2024-08-23 14:53:54 发布

阅读量298

点赞数 1

文章标签： zookeeper eureka

本文链接：https://blog.youkuaiyun.com/weixin_55758948/article/details/120672370

版权

Zookeeper和Eureka都是服务治理中的注册中心，但各有侧重。Zookeeper强调CP特性，适合分布式锁等场景，服务注册为临时节点，断连后自动删除。Eureka则基于AP，重视可用性，服务注册为持久，有心跳检测和自我保护机制。两者在服务发现、容错性和一致性上有不同策略，适用于不同的系统需求。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

zookeeper作为注册中心，也可以作为分布式锁的一种实现。

ZooKeeper主要服务于分布式系统，可以用ZooKeeper来做：统一配置管理、统一命名服务、分布式锁、集群管理。
使用分布式系统就无法避免对节点管理的问题(需要实时感知节点的状态、对节点进行统一管理等等)，而由于这些问题处理起来可能相对麻烦和提高了系统的复杂性，ZooKeeper作为一个能够通用解决这些问题的中间件就应运而生了。

Zookeeper的数据结构可以看做一棵树，每个节点叫做ZNode,每个节点可以通过路径标识。

Znode分为两种类型：

短暂/临时：当客户端和服务端断开连接后，所创建的Znode(节点)会自动删除
持久：当客户端和服务端断开连接后，所创建的Znode(节点)不会删除

Zookeeper配合监听器才能做好多事情：

常见的监听场景有以下两项：

监听Znode节点的数据变化
监听子节点的增减变化

Zookeeper有哪些特点：

顺序一致性：从同一客户端发起的事务请求，最终将会严格按照顺序被应用到Zookeeper中
原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，意思就是，要么整个集群中所有的机器都成功应用了某个事务，要么都没有应用。
单一系统映像：无论客户端连到哪个zookeeper服务器上，他看到的服务端数据模型都是一致的。
可靠性：一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖

区别

eureka作为分布式系统的注册中心，主要作用是用于服务治理

每一个微服务中都有eureka client，用于服务的注册于发现，每一个微服务启动的时候，都需要去eureka server注册

当A服务需要调用B服务时，需要从eureka服务端获取B服务的服务列表，然后把列表缓存到本地，然后根据ribbon的客户端负载均衡规则，从服务列表中取到一个B服务，然后去调用此B服务

当A服务下次再此调用B服务时，如果发现本地已经存储了B的服务列表，就不需要再从eureka服务端获取B服务列表，直接根据ribbon的客户端负载均衡规则，从服务列表中取到一个B服务，然后去调用B服务

微服务，默认每30秒，就会从eureka服务端获取一次最新的服务列表

如果某台微服务down机，或者添加了几台机器，此时eureka server会通知订阅他的客户端，并让客户端更新服务列表，而且还会通知其他eureka server更新此信息

心跳检测，微服务每30秒向eureka server发送心跳， eureka server若90s之内都没有收到某个客户端的心跳，则认为此服务出了问题，会从注册的服务列表中将其删除，并通知订阅它的客户端更新服务列表，而且还会通知其他eureka server更新此信息

eureka server保护机制，通过打卡开关，可以让eureka server处于保护状态，主要是用于某eureka server由于网络或其他原因，导致接收不到其他微服务的心跳，此时不能盲目的将其他微服务从服务列表中删除。

具体规则：如果一段时间内，85%的服务都没有发送心跳，则此server进入保护状态，此状态下，可以正常接受注册，可以正常提供查询服务，但是不与其他server同步信息，也不会通知订阅它的客户端，这样就不会误杀其他微服务