资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/程序员笔记|详解Eureka 缓存机制

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

mgckid / 836人阅读

摘要：和二级缓存影响状态更新，缩短这两个定时任务周期可减少滞后时间，例如配置更新周期更新周期服务提供者保证服务正常下线。服务提供者延迟下线。

引言

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服务状态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更新服务注册信息。

三级缓存

缓存 类型 说明
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时说明已经接受了其优先保证可用性(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保存了服务注册信息，服务消费者通过网关将请求转发给服务提供者，只需要做到服务提供者下线时通知网关在自己保存的服务列表中使该服务失效。为了保持网关的独立性，可实现一个独立服务接收下线通知并协调网关集群。下篇文章将详细介绍网关如何实现服务下线实时感知，敬请期待！

作者：冯永彪
内容来源：宜信技术学院

云服务器 GPU云服务器 机制详解 三级缓存机制 cdn缓存机制 php缓存机制

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/62108.html

相关文章

  • SpringCloud微服务实战笔记

    摘要：服务提供者的运行机制用了双层结构来维护注册的服务信息，第一层为服务的名称，第二层为服务的实例名称。服务注册中心的运行机制为了防止服务的异常下线，会周期性的清理列表中未续约的服务。负载均衡器的基本功能维护该服务下的所有节点列表。 Spring Boot Spring Boot有什么作用 Spring Boot通过自动化的配置简化Spring原有的样板化的配置。 Spring Boo...

    chunquedong 评论0 收藏0

  • 2021 年最新基于 Spring Cloud 的微服务架构分析

    摘要：是一个相对比较新的微服务框架，年才推出的版本虽然时间最短但是相比等框架提供的全套的分布式系统解决方案。提供线程池不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务器雪崩的问题。通过互相注册的方式来进行消息同步和保证高可用。 Spring Cloud 是一个相对比较新的微服务框架，...

    cikenerd 评论0 收藏0

  • 墙裂推荐：搜云库技术团队，面试必备的技术干货

    摘要：今天整理了一下近大半年以来的一些文章，和我的预期一样，很多文章我都忘记自己曾经写过了，这个记录的过程让我也有了新的理解。希望大家，收藏，点赞，加转发。 今天整理了一下近大半年以来的一些文章，和我的预期一样，很多文章我都忘记自己曾经写过了，这个记录的过程让我也有了新的理解。希望大家，收藏，点赞，加转发。 面试必备 面试必备：深入Spring MVC DispatchServlet 源码...

    SegmentFault 评论0 收藏0

  • 墙裂推荐：搜云库技术团队，面试必备的技术干货

    摘要：今天整理了一下近大半年以来的一些文章，和我的预期一样，很多文章我都忘记自己曾经写过了，这个记录的过程让我也有了新的理解。希望大家，收藏，点赞，加转发。 今天整理了一下近大半年以来的一些文章，和我的预期一样，很多文章我都忘记自己曾经写过了，这个记录的过程让我也有了新的理解。希望大家，收藏，点赞，加转发。 面试必备 面试必备：深入Spring MVC DispatchServlet 源码...

    Neilyo 评论0 收藏0

  • 图解 Eureka 的缓存架构 #yyds干货盘点#

    摘要：图解的缓存架构干货盘点悟空聊架构默认会先从只读缓存里面找。图解的缓存架构干货盘点缓存读写缓存过期的时候其实分两种定时过期和实时过期。 大家好，我是悟空。先说下哈，这篇文章画原理图用了很多时间，求个三连！Eureka 注册中心系列文章已经写到第七篇了，这里汇总下：​​领导让我研究 Eureka 源码 | 启动过程​​​​领导...

    番茄西红柿 评论0 收藏2637

发表评论

登陆后可评论

0条评论

mgckid

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<