Eureka系列 - 缓存机制解析

引言

Eureka是Netflix开源的、用于实现服务注册和发现的服务。Spring Cloud Eureka基于Eureka进行二次封装，添加了更人性化的UI,使用更加方便。但由于Eureka本身存在缓存比较多，服务状态更新滞后，最常见的状况是：服务下线后状态没有及时更新，服务消费者调用到已下线的服务导致请求失败。

1. AP特性

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

 2. 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更新服务注册信息，而Dashborad则从registry查询服务注册信息。

 三级缓存

缓存	类型	说明
registry	ConcurrentHashMap	实时更新，类AbstractInstanceRegistry成员变量，Dashboard查询的就是这里的服务注册信息
readWriteCacheMap	LoadingCache	实时更新，类ResponseCacheImpl成员变量，缓存时间180s
readOnlyCacheMap	ConcurrentHashMap	周期更新，类ResponseCacheImpl成员变量，默认每30s从readWriteCacheMap更新，Eureka client默认从这里更新服务注册信息，可配置直接从readWriteCacheMap更新