今天就跟大家聊聊有关如何解析Eureka 缓存机制，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
引言
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。
缓存机制
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系统作为服务注册中心。分布式系统中一般配置多节点，单个节点服务上线的状态更新滞后并没有什么影响，这里主要考虑服务下线后状态更新滞后的应对措施。
Eureka Server
缩短readOnlyCacheMap更新周期。缩短该定时任务周期可减少滞后时间。
eureka.server.responsecCacheUpdateIntervalMs: 10000 # Eureka Server readOnlyCacheMap更新周期关闭readOnlyCacheMap。中小型系统可以考虑该方案，Eureka Client直接从readWriteCacheMap更新服务注册信息。
eureka.server.useReadOnlyResponseCache: false # 是否使用readOnlyCacheMap
Eureka Client
服务消费者使用容错机制。如Spring Cloud Retry和Hystrix，Ribbon、Feign、Zuul都可以配置Retry，服务消费者访问某个已下线节点时一般报ConnectTimeout，这时可以通过Retry机制重试下一个节点。
服务消费者缩短更新周期。Eureka Client和Ribbon二级缓存影响状态更新，缩短这两个定时任务周期可减少滞后时间，例如配置：
eureka.client.registryFetchIntervalSeconds: 5 # Eureka Client更新周期ribbon.ServerListRefreshInterval: 2000 # Ribbon更新周期服务提供者保证服务正常下线。服务下线时使用kill或kill -15命令，避免使用kill -9命令，kill或kill -15命令杀死进程时将触发Eureka Client的shutdown()方法，主动删除Server的registry和readWriteCacheMap中的注册信息，不必依赖Server的evict清除。
服务提供者延迟下线。服务下线之前先调用接口使Eureka Server中保存的服务状态为DOWN或OUT_OF_SERVICE后再下线，二者时间差根据缓存机制和配置决定，比如默认情况下调用接口后延迟90s再下线服务即可保证服务消费者不会调用已下线服务实例。
网关实现服务下线实时感知
在软件工程中，没有一个问题是中间层解决不了的，而网关是服务提供者和服务消费者的中间层。以Spring Cloud Zuul网关为例，网关作为Eureka Client保存了服务注册信息，服务消费者通过网关将请求转发给服务提供者，只需要做到服务提供者下线时通知网关在自己保存的服务列表中使该服务失效。为了保持网关的独立性，可实现一个独立服务接收下线通知并协调网关集群。
看完上述内容，你们对如何解析Eureka 缓存机制有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注编程网行业资讯频道，感谢大家的支持。
