详解 Eureka 缓存机制

详解 Eureka 缓存机制

引言

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

AP 特性

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

（Eureka 高可用架构）

服务状态

Eureka 服务状态 enum 类：com.netflix.appinfo.InstanceInfo.InstanceStatus

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

三级缓存

缓存相关配置

关键类

Eureka Client

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

二级缓存

缓存相关配置

关键类

默认配置下服务消费者最长感知时间

考虑如下情况

• 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)和分区容错性§、不保证强一致性©的特点。如果需要优先保证强一致性©，则应该考虑使用 ZooKeeper 等 CP 系统作为服务注册中心。分布式系统中一般配置多节点，单个节点服务上线的状态更新滞后并没有什么影响，这里主要考虑服务下线后状态更新滞后的应对措施。

Eureka Server

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

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

Eureka Client

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

2. 服务消费者缩短更新周期。Eureka Client 和 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 保存了服务注册信息，服务消费者通过网关将请求转发给服务提供者，只需要做到服务提供者下线时通知网关在自己保存的服务列表中使该服务失效。为了保持网关的独立性，可实现一个独立服务接收下线通知并协调网关集群。

原文链接：

http://college.creditease.cn/detail/243