文章目录

[一、 Eureka-server 服务端缓存问题](#一、 Eureka-server 服务端缓存问题)
- - [1.1 服务端缓存](#1.1 服务端缓存)
  - [1.2 客户端从服务端获取实例数据的过程](#1.2 客户端从服务端获取实例数据的过程)
  - [1.3 优化](#1.3 优化)
[二、客户端 Eureka-client 缓存导致](#二、客户端 Eureka-client 缓存导致)
- - [2.1 Eureka客户端和服务端交互缓存](#2.1 Eureka客户端和服务端交互缓存)
  - [2.2 Ribbon 缓存了EurekaClient的缓存](#2.2 Ribbon 缓存了EurekaClient的缓存)
  - [2.3 优化](#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 优化

缩短只读缓存的更新时间，或者直接关闭一级缓存，因为注册表本身就存在内存中。
1. 一级缓存更新时间配置 eureka.server.response-cache-update-interval-ms
2. 关闭一级缓存 eureka.server.use-read-only-response-cache=false
多级缓存的存在，也进一步降低了 Eureka的数据一致性
缩短Eureka失效监测的间隔默认60seureka.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

Spring Cloud Eureka 服务发现速度慢配置优化总结