在使用Eureka做注册中心时，我平时遇到的最不爽问题，就是无法做到实时上下线。比如，我服务已经正常下线了，为什么上游还能调通？我服务已经上线了，为什么还有等"很久"才能真正被其他服务所"发现"？其实这些都是从Eureka到Client再到Ribbion这条链路中的逐级缓存造成的。

Eureka为什么要使用缓存

比如，对于Eureka来说，Eureka Client获取注册更新信息时，Eureka Server返回的数据其实是从一个默认每30s才更新的缓存获取的。也就是说，如果你服务下了一个，即使client是在服务下线之后发请求查询的注册列表，那这次请求也不会包括服务下线的信息。那么Eureka为什么要搞cache而不是实时的返回注册信息呢？我个人推测了一下，应该是为了在访问注册数据结构时尽量少加锁，从而提升单次请求时的性能。如果没有这层cache, 那么对于服务注册表这个数据结构来说，就会存在并发读写的情况，那就避免不了加锁保护。如果有cache, 是可以做到完全不加锁的。想一下，对于微服务架构来说，特点就是每个服务较轻，但服务数量较多。如果每个服务都定时请求eureka更新注册信息的话，对于Eureka Server来说，确实是可能会造成严重的锁竞争的。除了这个responseCache外，Eureka对于无心跳服务的清理也是默认每60s执行一次的，也就是说对于异常下线的服务(没有主动取消注册，而是中断了心跳)，在Eureka Server端最大会有长达 60s + 30s * 3 = 150s的延迟。这里的30s * 3 是3个心跳的周期。

Eureka Client的缓存

Eureka Client默认会对注册信息做30s缓存 ，这个很好理解 ，因为我们当然不希望每次RPC都要重新查一次注册表，这是很浪费的。 这是常规操作，无可厚非。

Ribbon的缓存

这就有点诡异了。Ribbon向上对接Eureka Client, 向下对接实现发起HTTP请求的客户端。ribbon自身也是有30s缓存的，即ribbon会每30s向Eureka Client那里索要注册信息，注意是Eureka Client而不是Eureka Server，这样就更加剧了整个系统对服务上下线感知的延迟。我认为Ribbon这样设计，原因是考虑到了其上游不仅仅是Eureka Client, 还可能是配置文件，或者以编程的方式输入的注册列表，而这些查询是有可能比较耗时的。Ribbon为了兼容这些情况，不得不添加了缓存。

实时上下线思路

只能用消息中间件了。新做一个上下线管理服务，提供HTTP接口来上下线指定服务，当指定要下线A服务时，先向Eureka发请求，将此服务下所有的实例都删掉，然后再向kafka类似这样的消息系统中发一条消息，所有的微服务都要监听此消息队列。

服务收到下线消息时，将指定服务从本地Ribbon服务列表中删除。这里Ribbon的 Loadbalancer提供了markServerDown()方法可以使用，还是容易实现的。

服务收到上线消息时，需要将服务信息添加到Ribbon中，Ribbon虽然也提供了对应的方法，但是参数较为复杂，还需要研究一下。

这些功能可以直接打包成starter, 写好以后各服务直接引用即可。

2、Eureka Server端优秀的多级缓存机制

   eureka为了避免同时读写内存数据结构造成的并发冲突问题采用了多级缓存的机制：

在拉取注册表时会首从readonlyCacheMap缓存里查找，如果没有再从readWriteCacheMap查找，要是还没有找到就直接从内存找。 当注册表发生改变时，直接修改内存中的注册表同时会过滤掉readWriteCacheMap，但readonlyCacheMap不会进行过滤还可以访问，当到达30秒过后后台线程发现readWriteCacheMap被清空了，同时也会清空readonlyCacheMap。当下个请求进行访问readonlyCacheMap和readWriteCacheMap会重新从最新的内存注册表过更新数据，又达到了一致性。

总结：Eureka同时通过纯内存的注册表，保证了所有的请求都可以在内存处理，确保了极高的性能，另外多级缓存机制，确保了不会针对内存数据结构发生频繁的读写并发冲突操作，进一步提升性能。

原文链接：https://blog.csdn.net/neosmith/article/details/90213156