你知道Eureka的缓存机制是怎么样的么？

引言

目前市场实现微服务中服务注册与发现的组建有很多，比如 eureka、consul nacos等，在微服务大行其道的今天我们都需要进行了解。本文主要讲解基于

Eureka的缓存机制。由于Eureka本身存在较多缓存，服务状态更新滞后，会导致很多服务请求失败的情况，我们一起了解下怎么降低及避免失败的情况产生。

一、AP特性

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

二、服务状态

三、Eureka Server

在Eureka高可用架构中，Eureka Server也可以作为Client向其他server注册，多节点相互注册组成Eureka集群，集群间相互视为peer。Eureka Client向Server注册、续约、更新状态时，接受节点更新自己的服务注册信息后，逐个同步至其他peer节点。

3.1 缓存机制

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的服务。

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

服务正常上线/修改/下线，最大可能会有120s滞后

30(首次注册 init registe) + 30(readOnlyCacheMap)+30(client fetch interval)+30(ribbon)=120s

如果是在Spring Cloud环境下使用这些组件(Eureka, Ribbon)，不会有首次注册30秒延迟的问题，服务启动后会马上注册,所以从注册到发现，最多可能是90s

服务异常下线：最大可能会有270s滞后

定时清理任务每eureka.server. evictionIntervalTimerInMs(默认60)执行一次清理任务- 每次清理任务会把90秒(3个心跳周期，eureka.instance.leaseExpirationDurationInSeconds)没收到心跳的踢除，但是根据官方的说法 ，因为代码实现的bug，这个时间其实是两倍，即180秒，也就是说如果一个客户端因为网络问题或者主机问题异常下线，可能会在180秒后才剔除- 读取端，因为readOnlyCacheMap以及客户端缓存的存在，可能会在30(readOnlyCacheMap)+30(client fetch interval)+30(ribbon)=90- 所以极端情况最终可能会是180+90=270s

六、应对措施

服务注册中心在选择使用Eureka时说明已经接受了其优先保证可用性(A)和分区容错性(P)、不保证强一致性(C)的特点。如果需要优先保证强一致性(C)，则应该考虑使用ZooKeeper等CP系统作为服务注册中心。分布式系统中一般配置多节点，单个节点服务上线的状态更新滞后并没有什么影响，这里主要考虑服务下线后状态更新滞后的应对措施。

6.1 Eureka Server

1.缩短readOnlyCacheMap更新周期。

2.关闭readOnlyCacheMap。

6.2 Eureka Client

1.服务消费者使用容错机制。

2.服务消费者缩短更新周期。

3.服务提供者保证服务正常下线。

4.服务提供者延迟下线。

七、总结

本文总结了Eureka缓存处理机制，对服务的注册、同步的时间做了分析。

同时指出服务异常下线的问题，以及减少异常下线的影响。异常下线问题还有很多优化处理方式，需要进一步了解。

ps:看更多干货，加入技术交流微信群可以关注我的公众号360linker