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

 

引言

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

一、AP特性

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

Eureka高可用架构

 

二、TT快三服务 状态

EurekaTT快三服务 状态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注册、续约、更新状态时,接受节点更新自己的TT快三服务 注册信息后,逐个同步至其他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)保存TT快三服务 注册信息,默认情况下定时任务每30s将readWriteCacheMap同步至readOnlyCacheMap,每60s清理超过90s未续约的节点,Eureka Client每30s从readOnlyCacheMap更新TT快三服务 注册信息,而UI则从registry更新TT快三服务 注册信息。

  

三级缓存

缓存类型说明
registry ConcurrentHashMap 实时更新,类AbstractInstanceRegistryTT快三成员 变量,UI端请求的是这里的TT快三服务 注册信息
readWriteCacheMap Guava Cache/LoadingCache 实时更新,类ResponseCacheImplTT快三成员 变量,缓存时间180秒
readOnlyCacheMap ConcurrentHashMap 周期更新,类ResponseCacheImplTT快三成员 变量,默认每30s从readWriteCacheMap更新,Eureka client默认从这里更新TT快三服务 注册信息,可配置直接从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 保存TT快三服务 注册信息,持有registry和responseCacheTT快三成员 变量
com.netflix.eureka.registry.ResponseCacheImpl 持有readWriteCacheMap和readOnlyCacheMapTT快三成员 变量

四、Eureka Client

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

二级缓存

缓存类型说明
localRegionApps AtomicReference 周期更新,类DiscoveryClientTT快三成员 变量,Eureka Client保存TT快三服务 注册信息,启动后立即向Server全量更新,默认每30s增量更新
upServerListZoneMap ConcurrentHashMap 周期更新,类LoadBalancerStatsTT快三成员 变量,Ribbon保存使用且状态为UP的TT快三服务 注册信息,启动后延时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 负责注册、续约和更新,TT快三方法 initScheduledTasks()分别初始化续约和更新定时任务
com.netflix.loadbalancer.PollingServerListUpdater Ribbon 更新使用的TT快三服务 注册信息,start初始化更新定时任务
com.netflix.loadbalancer.LoadBalancerStats Ribbon,保存使用且状态为UP的TT快三服务 注册信息

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

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

考虑如下情况

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

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

 

 

六、应对措施

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

6.1 Eureka Server

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

    eureka.server.responsecCacheUpdateIntervalMs: 10000  # Eureka Server readOnlyCacheMap更新周期

     

  • 2.关闭readOnlyCacheMap。中小型系统可以考虑该方案,Eureka Client直接从readWriteCacheMap更新TT快三服务 注册信息。

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

     

6.2 Eureka Client

  • 1.TT快三服务 消费者使用容错机制。如Spring Cloud Retry和Hystrix,Ribbon、Feign、Zuul都可以配置Retry,TT快三服务 消费者访问某个已下线节点时一般报ConnectTimeout,这时可以通过Retry机制重试下一个节点。

  • 2.TT快三服务 消费者缩短更新周期。Eureka Client和Ribbon二级缓存影响状态更新,缩短这两个定时任务周期可减少滞后时间,例如配置:

    eureka.client.registryFetchIntervalSeconds: 5        # Eureka Client更新周期
    ribbon.ServerListRefreshInterval: 2000               # Ribbon更新周期

     

  • 3.TT快三服务 提供者保证TT快三服务 正常下线。TT快三服务 下线时使用kill或kill -15命令,避免使用kill -9命令,kill或kill -15命令杀死进程时将触发Eureka Client的shutdown()TT快三方法 ,主动TT快三删除 Server的registry和readWriteCacheMap中的注册信息,不必依赖Server的evict清除。

  • 4.TT快三服务 提供者延迟下线。TT快三服务 下线之前先调用接口使Eureka Server中保存的TT快三服务 状态为DOWN或OUT_OF_SERVICE后再下线,二者时间差根据缓存机制和配置决定,比如默认情况下调用接口后延迟90s再下线TT快三服务 即可保证TT快三服务 消费者不会调用已下线TT快三服务 实例。

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

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

作者:冯永彪

内容来源:宜信TT快三技术 学院

posted @ 2019-05-15 18:19 宜信TT快三技术 阅读(...) 评论(...) 编辑 收藏