文章目录
- 一、 Eureka-server 服务端缓存问题
- 1.1 服务端缓存
- 1.2 客户端从服务端获取实例数据的过程
- 1.3 优化
- 二、客户端 Eureka-client 缓存导致
- 2.1 Eureka客户端和服务端交互缓存
- 2.2 Ribbon 缓存了EurekaClient的缓存
- 2.3 优化
使用Eureka时,常常会发现服务发现慢,上线半天后都不可用。并且服务下线后又长时间未被剔除的问题。这个问题跟Eureka-server 端和client端都有关系,这次从两头来设置优化
一、 Eureka-server 服务端缓存问题
1.1 服务端缓存
- 服务注册到注册中心后,服务实例信息是存储在内存的注册表中。但是Eureka为了提高响应速度,在内部又加了两层缓存结构,将 Eureka-client需要的实例信息直接缓存了起来。获取的时候从缓存中获取数据进行响应。
- 第一层缓存 readOnlyCacheMap readOnlyCache 采用ConcurrentHashMap来存储数据,主要负责定时于readWriteCache进行数据同步,默认30s同步一次
- 第二层缓存 readWriteCacheMap 采用Guavva 实现缓存操作。缓存过期时间为 180s,服务下线、过期、注册、状态变更等操作都会清除此缓存中的数据。
1.2 客户端从服务端获取实例数据的过程
Client获取服务实例数据时,会先从⼀级缓存中获取,如果⼀级缓存中不存在,再从⼆级缓存中获取,如果⼆级缓存也不存在,会触发缓存的加载,从存储层拉取数据到缓存中,然后再返回给 Client。
1.3 优化
- 缩短只读缓存的更新时间,或者直接关闭一级缓存,因为注册表本身就存在内存中。
- 一级缓存更新时间配置
eureka.server.response-cache-update-interval-ms
- 关闭一级缓存
eureka.server.use-read-only-response-cache=false
- 一级缓存更新时间配置
- 多级缓存的存在,也进一步降低了 Eureka的数据一致性
- 缩短Eureka失效监测的间隔 默认60s
eureka.server.eviction-interval-timer-in-ms
注意 这个和客户端设置的下线失效不同。这个配置是 60s 检查一下,有没有客户端超过客户端自己配置的eureka.instance.lease-expiration-duration-in-seconds
时间没有响应。
二、客户端 Eureka-client 缓存导致
2.1 Eureka客户端和服务端交互缓存
EurekaClient中的com.netflix.discovery.DiscoveryClient.initScheduledTasks() ⽅法中,初始化了⼀个 CacheRefreshThread 定时任务专⻔⽤来拉取 Eureka Server 的实例信息到本地。如果这个时间太长,也会导致服务发现和剔除变慢。所以可以通过优化这个配置 eureka.client.registryFetchIntervalSeconds
来提高服务发现的速度
2.2 Ribbon 缓存了EurekaClient的缓存
- Ribbon会从EurekaClient中获取服务信息,ServerListUpdater是Ribbon中负责服务实例更新的组件,默认的实现是PollingServerListUpdater,通过线程定时去更新实例信息。
- 定时刷新的时间间隔默认是30秒,当服务停⽌或者上线后,这边最快也需要30秒才能将实例信息更新成最新的。我们可以将这个时间调短⼀点,⽐如 3 秒。
2.3 优化
- 优化 Eureka 客户端缓存有效期
eureka.client.registryFetchIntervalSeconds=5
- 优化 Ribbon 从Eureka客户端获取缓存的间隔
ribbon.ServerListRefreshInterval=5