二级缓存
缓存 类型 说明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系统作为服务注册中心。分布式系统中一般配置多节点，单个节点服务上线的状态更新滞后并没有什么影响，这里主要考虑服务下线后状态更新滞后的应对措施。
6.1 Eureka Server
1.缩短readOnlyCacheMap更新周期。缩短该定时任务周期可减少滞后时间。
eureka.server.responsecCacheUpdateIntervalMs: 10000 # Eureka Server readOnlyCacheMap更新周期