程序员笔记|详解Eureka 缓存机制

栏目: Java · 发布时间: 5年前

内容简介:Eureka是Netflix开源的、用于实现服务注册和发现的服务。Spring Cloud Eureka基于Eureka进行二次封装,增加了更人性化的UI,使用更为方便。但是由于Eureka本身存在较多缓存,服务状态更新滞后,最常见的状况是:服务下线后状态没有及时更新,服务消费者调用到已下线的服务导致请求失败。从CAP理论看,Eureka是一个AP系统,优先保证可用性(A)和分区容错性(P),不保证强一致性(C),只保证最终一致性,因此在架构中设计了较多缓存。

引言

Eureka是Netflix开源的、用于实现服务注册和发现的服务。Spring Cloud Eureka基于Eureka进行二次封装,增加了更人性化的UI,使用更为方便。但是由于Eureka本身存在较多缓存,服务状态更新滞后,最常见的状况是:服务下线后状态没有及时更新,服务消费者调用到已下线的服务导致请求失败。 本文基于Spring Cloud Eureka 1.4.4.RELEASE,在默认region和zone的前提下,介绍Eureka的缓存机制。

一、AP特性

从CAP理论看,Eureka是一个AP系统,优先保证可用性(A)和分区容错性(P),不保证强一致性(C),只保证最终一致性,因此在架构中设计了较多缓存。

程序员笔记|详解Eureka 缓存机制

二、服务状态

Eureka服务状态enum类: com.netflix.appinfo.InstanceInfo.InstanceStatus

状态 说明 状态 说明
UP 在线 OUT_OF_SERVICE 失效
DOWN 下线 UNKNOWN 未知
STARTING 正在启动

三、Eureka Server

在Eureka高可用架构中,Eureka Server也可以作为Client向其他server注册,多节点相互注册组成Eureka集群,集群间相互视为peer。Eureka Client向Server注册、续约、更新状态时,接受节点更新自己的服务注册信息后,逐个同步至其他peer节点。

【注意】如果server-A向server-B节点单向注册,则server-A视server-B为peer节点,server-A接受的数据会同步给server-B,但server-B接受的数据不会同步给server-A。

3.1 缓存机制

Eureka Server存在三个变量:( registry、readWriteCacheMap、readOnlyCacheMap )保存服务注册信息,默认情况下定时任务每30s将readWriteCacheMap同步至readOnlyCacheMap,每60s清理超过90s未续约的节点,Eureka Client每30s从readOnlyCacheMap更新服务注册信息,而UI则从registry更新服务注册信息。

程序员笔记|详解Eureka 缓存机制

三级缓存

缓存 类型 说明
registry ConcurrentHashMap 实时更新 ,类AbstractInstanceRegistry成员变量,UI端请求的是这里的服务注册信息
readWriteCacheMap Guava Cache/LoadingCache 实时更新 ,类ResponseCacheImpl成员变量,缓存时间180秒
readOnlyCacheMap ConcurrentHashMap 周期更新 ,类ResponseCacheImpl成员变量,默认每 30s 从readWriteCacheMap更新,Eureka client默认从这里更新服务注册信息,可配置直接从readWriteCacheMap更新

缓存相关配置

配置 默认 说明
eureka.server.useReadOnlyResponseCache true Client从 readOnlyCacheMap 更新数据,false则跳过readOnlyCacheMap直接从readWriteCacheMap更新
eureka.server.responsecCacheUpdateIntervalMs 30000 readWriteCacheMap更新至readOnlyCacheMap周期,默认 30s
eureka.server.evictionIntervalTimerInMs 60000 清理未续约节点(evict)周期,默认 60s
eureka.instance.leaseExpirationDurationInSeconds 90 清理未续约节点超时时间,默认 90s

关键类

类名 说明
com.netflix.eureka.registry.AbstractInstanceRegistry 保存服务注册信息,持有registry和responseCache成员变量
com.netflix.eureka.registry.ResponseCacheImpl 持有readWriteCacheMap和readOnlyCacheMap成员变量

四、Eureka Client

Eureka Client存在两种角色: 服务提供者服务消费者 ,作为服务消费者一般配合Ribbon或Feign(Feign内部使用Ribbon)使用。Eureka Client启动后,作为服务提供者立即向Server注册,默认情况下每30s续约(renew);作为服务消费者立即向Server全量更新服务注册信息,默认情况下每30s增量更新服务注册信息;Ribbon延时1s向Client获取使用的服务注册信息,默认每30s更新使用的服务注册信息,只保存状态为UP的服务。

二级缓存

缓存 类型 说明
localRegionApps AtomicReference 周期更新 ,类DiscoveryClient成员变量,Eureka Client保存服务注册信息,启动后立即向Server全量更新,默认每 30s 增量更新
upServerListZoneMap ConcurrentHashMap 周期更新 ,类LoadBalancerStats成员变量,Ribbon保存使用且状态为 UP 的服务注册信息,启动后延时1s向Client更新,默认每 30s 更新

缓存相关配置

配置 默认 说明
eureka.instance.leaseRenewalIntervalInSeconds 30 Eureka Client 续约周期,默认 30s
eureka.client.registryFetchIntervalSeconds 30 Eureka Client 增量更新周期,默认 30s (正常情况下增量更新,超时或与Server端不一致等情况则全量更新)
ribbon.ServerListRefreshInterval 30000 Ribbon 更新周期,默认 30s

关键类

类名 说明
com.netflix.discovery.DiscoveryClient Eureka Client 负责注册、续约和更新,方法initScheduledTasks()分别初始化续约和更新定时任务
com.netflix.loadbalancer.PollingServerListUpdater Ribbon 更新使用的服务注册信息,start初始化更新定时任务
com.netflix.loadbalancer.LoadBalancerStats Ribbon,保存使用且状态为 UP 的服务注册信息

五、默认配置下服务消费者最长感知时间

Eureka Client 时间 说明
上线 30(readOnly)+30(Client)+30(Ribbon)= 90s readWrite -> readOnly -> Client -> Ribbon 各30s
正常下线 30(readonly)+30(Client)+30(Ribbon)= 90s 服务正常下线(kill或kill -15杀死进程)会给进程善后机会,DiscoveryClient.shutdown()将向Server更新自身状态为DOWN,然后发送DELETE请求注销自己,registry和readWriteCacheMap实时更新,故UI将不再显示该服务实例
非正常下线 30+60(evict)*2+30+30+30= 240s 服务非正常下线(kill -9杀死进程或进程崩溃)不会触发DiscoveryClient.shutdown()方法,Eureka Server将依赖每60s清理超过90s未续约服务从registry和readWriteCacheMap中删除该服务实例

考虑如下情况

  • 0s时服务未通知Eureka Client直接下线;
  • 29s时第一次过期检查evict未超过90s;
  • 89s时第二次过期检查evict未超过90s;
  • 149s时第三次过期检查evict未续约时间超过了90s,故将该服务实例从registry和readWriteCacheMap中删除;
  • 179s时定时任务从readWriteCacheMap更新至readOnlyCacheMap;
  • 209s时Eureka Client从Eureka Server的readOnlyCacheMap更新;
  • 239s时Ribbon从Eureka Client更新。

因此,极限情况下服务消费者最长感知时间将无限趋近240s。

程序员笔记|详解Eureka 缓存机制

六、应对措施

服务注册中心在选择使用Eureka时说明已经接受了其优先保证可用性(A)和分区容错性(P)、不保证强一致性(C)的特点。如果需要优先保证强一致性(C),则应该考虑使用ZooKeeper等CP系统作为服务注册中心。分布式系统中一般配置多节点,单个节点服务上线的状态更新滞后并没有什么影响,这里主要考虑服务下线后状态更新滞后的应对措施。

6.1 Eureka Server

  • 1. 缩短readOnlyCacheMap更新周期 。缩短该定时任务周期可减少滞后时间。

    eureka.server.responsecCacheUpdateIntervalMs: 10000  # Eureka Server readOnlyCacheMap更新周期
  • 2. 关闭readOnlyCacheMap 。中小型系统可以考虑该方案,Eureka Client直接从readWriteCacheMap更新服务注册信息。

    eureka.server.useReadOnlyResponseCache: false        # 是否使用readOnlyCacheMap

6.2 Eureka Client

  • 1. 服务消费者使用容错机制 。如Spring Cloud Retry和Hystrix,Ribbon、Feign、Zuul都可以配置Retry,服务消费者访问某个已下线节点时一般报ConnectTimeout,这时可以通过Retry机制重试下一个节点。
  • 2. 服务消费者缩短更新周期 。Eureka Client和Ribbon二级缓存影响状态更新,缩短这两个定时任务周期可减少滞后时间,例如配置:

    eureka.client.registryFetchIntervalSeconds: 5        # Eureka Client更新周期
    ribbon.ServerListRefreshInterval: 2000               # Ribbon更新周期
  • 3. 服务提供者保证服务正常下线 。服务下线时使用kill或kill -15命令,避免使用kill -9命令,kill或kill -15命令杀死进程时将触发Eureka Client的shutdown()方法,主动删除Server的registry和readWriteCacheMap中的注册信息,不必依赖Server的evict清除。
  • 4. 服务提供者延迟下线 。服务下线之前先调用接口使Eureka Server中保存的服务状态为DOWN或OUT_OF_SERVICE后再下线,二者时间差根据缓存机制和配置决定,比如默认情况下调用接口后延迟90s再下线服务即可保证服务消费者不会调用已下线服务实例。

七、网关实现服务下线实时感知

在软件工程中,没有一个问题是中间层解决不了的,而网关是服务提供者和服务消费者的中间层。以Spring Cloud Zuul网关为例,网关作为Eureka Client保存了服务注册信息,服务消费者通过网关将请求转发给服务提供者,只需要做到服务提供者下线时通知网关在自己保存的服务列表中使该服务失效。为了保持网关的独立性,可实现一个独立服务接收下线通知并协调网关集群。 下篇文章将详细介绍网关如何实现服务下线实时感知 ,敬请期待!

作者:冯永彪

内容来源: 宜信技术学院


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

风口上的汽车新商业

风口上的汽车新商业

郭桂山 / 人民邮电出版社 / 59

本书从互联网+汽车趋势解析、汽车电商困局突围策略、汽车后市场溃败求解等三个篇章详细阐述了作者的观察与思考,当然更多的还是作者在汽车电商行业的实践中得出的解决诸多问题的战略策略,作者站在行业之巅既有战略策略的解决方案,同时也有战术上的实施细则,更有实操案例解析与行业大咖访谈等不可多得的干货。当然,作者一向追崇的宗旨是,书中观点的对错不是最重要的,重在与行业同仁探讨,以书会友,希望作者的这块破砖头,能......一起来看看 《风口上的汽车新商业》 这本书的介绍吧!

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具