Spring Cloud Eureka原理分析（三）：注册信息读取（服务端）
服务端的注册信息读取使用缓存，而非直接读取registry那个 ConcurrentHashMap 。缓存的主要逻辑都在 ResponseCacheImpl 这个类中。
缓存有两层，第一层是Guava的带生存时间的 LoadingCache ，称为 readWriteCacheMap ；第二层是一个 ConcurrentHashMap ，称为 readOnlyCacheMap 。
参见下面的示意图：
下面看一下图中两个重要的方法。
generatePayload(Key key)
此方法接受一个 Key 类型的参数，返回一个 Value 类型。 其中 Key 中重要的字段有：
-
KeyType，表示payload文本格式，有JSON和XML两种值。 -
EntityType，表示缓存的类型，有Application,VIP,SVIP三种值。 -
entityName，表示缓存的名称，可能是单个应用名，也可能是ALL_APPS或ALL_APPS_DELTA。
Value 则有一个 String 类型的payload和一个 byte 数组，表示gzip压缩后的字节。
generatePayload() 中根据 EntityType 和 EntityName ，会调用不同的方法获取regitry中的信息。
-
registry.getApplications(): 得到所有的应用注册信息，结果为Applications对象。 -
registry.getApplicationsDeltas()：得到增量更新信息。 -
registry.getApplication()：得到单个应用信息。 -
getApplicationsForVip：就是先得到所有的应用注册信息，然后提取出vipAddress符合请求的应用信息。
vip和svip是什么
在Spring Cloud Eureka中，这两个设置变成了VirtualHostName和SecureVirtualHostName，应该是类似DNS名称。
invalidate(String appName, ...)
传入的为某个应用名，而实际上要让以下缓存失效：
- 应用的缓存
- ALL_APPS缓存
- ALL_APPS_DELTA缓存
定时刷新readOnlyCache任务
行为很简单，就是把readWriteMap拷贝到readOnlyMap（但只拷贝readOnlyCache中已有的key）。 任务执行频率由 eureka.server.responseCacheUpdateIntervalMs 控制，默认为30秒。
另外， eureka.server.useReadOnlyResponseCache 可以设置是否启用readOnlyCache，默认启用。
全量信息与增量信息
前文已述， generatePayload() 方法根据 entityName 是 ALL_APPS 或 ALL_APPS_DELTA 决定生成已注册的全量信息，还是增量信息。
全量信息
调用 registry.getApplications() ，最终就是从本地（也可能包含远程）的registry中读取所有注册信息，构造成 Applications 对象。
增量信息
在前两篇文章中，提到了registry的实现类有一个 AbstractInstanceRegistry.recentlyChangedQueue 队列，保存最近的租约变更记录。在注册、下线等操作时，会修改此队列。
另外，还有一个定时任务专门对超过一定时长的记录进行移除。定时任务的执行间隔由 eureka.server.deltaRetentionTimerIntervalInMs 控制；时长阈值由 eureka.server.retentionTimeInMSInDeltaQueue 控制。
客户端获取增量信息，与本地缓存合并后通服务端的全量信息比较哈希值（哈希算法有特别实现，主要根据注册应用内容）。如果哈希值不同，则增量获取失败，需要一次全量获取。
正文到此结束
热门推荐
相关文章
近期评论
-
收到
-
https://www.liuhaihua.cn/archives/40657.html 这篇博客中的图片打不开了
-
不会英语啊。
-
-
-
https://pplx.ai/floraliu4199466 这个链接打不开是什么原因？
-
-
-
-
来看看，最近更新了一波，顺着友联过来的，几年过去了，网站越搞越好，厉害
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
