欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

zookeeper与eureka对比

程序员文章站 2022-07-12 22:19:37
...

对比学习,记忆才会更深刻,理解才会更深入,下面从CAP、时效性、容量,三个方面zookeeper与eureka进行对比

CAP

C( Consistency):一致性
A(Availability):可用性
P(Partition tolerance):分区容错性


zookeeper保证了CP

zookeeper与eureka对比
服务B注册到ZKLeader上,必须强制同步到ZKFollower才算注册成功过

服务B注册到了Leader上,在同步期间ZKLeader挂掉了,在选举期间,不允许任何服务访问,因为还没有完全保证数据一致性,这样保证了数据的强一致


Eureka保证的AP
![在这里插入图片描述](https://img-blog.csdnimg.cn/20191123154152646.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l5eDMyMTQ=,size_16,color_FFFFFF,t_70) 服务B往Eureka上注册还没来得及同步,Eureka直接死掉了,但是Eureka保证了可用性,所以没关系,服务A还可以去另一个Eureka进行服务发现,这样读到是不一致的数据,因为根本就没有最新的B服务,但是可以保证最终一致性,因为B服务注册到Eureka然后给Eureka发心跳,发现Eureka死掉了,可以给另外一个Eureka发心跳重新注册,这个Eureka就能感知的B服务的存在,然后服务A去Eureka中去拉,就能感知到服务B
服务注册发现的时效性
服务B注册到ZKLeader上,然后同步到ZKFollower,再通知服务列表更新,整个过程是秒级的 服务B挂掉了,ZKLeader会感知到服务断开了,然后立即同步到ZKFollower,然后更新也是秒级

ZK时效性更好,注册或者是挂了,一般秒级就能感知到
eureka,默认配置非常糟糕,服务发现感知要到几十秒,甚至分钟级别

zookeeper与eureka对比
readWriteCacheMap : 此处存放的是最终的缓存, 当服务下线,过期,注册,状态变更,都会来清除这个缓存里面的数据。 然后通过CacheLoader进行缓存加载,在进行readWriteCacheMap.get(key)的时候,首先看这个缓存里面有没有该数据,如果没有则通过CacheLoader的load方法去加载,加载成功之后将数据放入缓存,同时返回数据

readOnlyCacheMap : 这是一个JVM的CurrentHashMap只读缓存,这个主要是为了供客户端获取注册信息时使用,其缓存更新,依赖于定时器的更新,通过和readWriteCacheMap 的值做对比,如果数据不一致,则以readWriteCacheMap 的数据为准。

responseCacheUpdateIntervalMs : readOnlyCacheMap 缓存更新的定时器时间间隔,默认为30秒

responseCacheAutoExpirationInSeconds : readWriteCacheMap 缓存过期时间,默认为 180 秒 。

eureka,默认配置非常糟糕,服务发现感知要到几十秒,甚至分钟级别,上线一个新的服务实例,到其他人可以发现他,极端情况下,可能需要1分钟的时间,ribbon去获取每个服务上缓存的eureka的注册表进行负载均衡。

服务故障,隔60秒才会去检测心跳,发现这个服务上一次心跳是在60秒之前,隔60秒去检查心跳,超过90秒没有心跳,才会认为他死了,2分钟都过去

30秒,才会更新缓存,30秒,其他服务才会拉去最新的注册表


容量
zk,不太适合大规模的服务实例,因为服务上下线的时候,需要瞬间推送数据通知到所有的其他服务实例,所以一旦服务规模太大,到了几千服务实例的时候,会导致网络带宽被大量占用

eureka,也很难支撑大规模的服务实例,因为每个eureka实例都要接受所有的请求,实例多了压力太大,扛不住,也很难到几千服务实例


系统遇到服务过慢的问题,怎么优化和解决的
Eureka.server.responseCacheUpdateIntervalMs = 30000(服务端-定时同步)
Eureka.client.registryFetchIntervalSeconds = 30000( 客户端-从eureka服务器注册表中获取注册信息的时间间隔(s),默认为30)
	
Eureka.client.leaseRenewalIntervalInSeconds = 30(客户端-eureka客户需要多长时间发送心跳给eureka服务器,表明它仍然活着,默认为30)
Eureka.server.evictionIntervalTimerInMs = 60000(服务端-检查心跳)
Eureka.instance.leaseExpirationDurationInSeconds = 90(服务端-Eureka服务器在接收到实例的最后一次发出的心跳后,需要等待多久才可以将此实例删除,默认为90) 

小结:
本篇文章只是小编的个人总结,有什么不对的地方,还希望大神指出。