springcloud之eureka底层原理

服务的注册:

Eureka源码如下:

image

• 如上图所示，图中的这个名字叫做registry的CocurrentHashMap，就是注册表的核心结构。看完之后忍不住先赞叹一下，精妙的设计！

• 从代码中可以看到，Eureka Server的注册表直接基于纯内存，即在内存里维护了一个数据结构。

• 各个服务的注册、服务下线、服务故障，全部会在内存里维护和更新这个注册表。

• 各个服务每隔30秒拉取注册表的时候，Eureka Server就是直接提供内存里存储的有变化的注册表数据给他们就可以了。

• 同样，每隔30秒发起心跳时，也是在这个纯内存的Map数据结构里更新心跳时间。
  一句话概括：维护注册表、拉取注册表、更新心跳时间，全部发生在内存里！这是Eureka Server非常核心的一个点。

Eureka Server端多级缓存机制

而且Eureka Server为了避免同时读写内存数据结构造成的并发冲突问题，还采用了多级缓存机制来进一步提升服务请求的响应速度。

在拉取注册表的时候：
首先从ReadOnlyCacheMap里查缓存的注册表。
若没有，就找ReadWriteCacheMap里缓存的注册表。
如果还没有，就从内存中获取实际的注册表数据。

在注册表发生变更的时候：

会在内存中更新变更的注册表数据，同时过期掉ReadWriteCacheMap。
此过程不会影响ReadOnlyCacheMap提供人家查询注册表。
一段时间内（默认30秒），各服务拉取注册表会直接读ReadOnlyCacheMap
30秒过后，Eureka Server的后台线程发现ReadWriteCacheMap已经清空了，也会清空ReadOnlyCacheMap中的缓存
下次有服务拉取注册表，又会从内存中获取最新的数据了，同时填充各个缓存。

多级缓存机制的优点是什么？
尽可能保证了内存注册表数据不会出现频繁的读写冲突问题。
并且进一步保证对Eureka Server的大量请求，都是快速从纯内存走，性能极高。
为方便大家更好的理解，同样来一张图，大家跟着图再来回顾一下这整个过程：

image

客户端的拉取

通过定时任务30秒拉取一次注册表,30秒发起一次心跳