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 控制。
客户端获取增量信息，与本地缓存合并后通服务端的全量信息比较哈希值（哈希算法有特别实现，主要根据注册应用内容）。如果哈希值不同，则增量获取失败，需要一次全量获取。
正文到此结束
热门推荐
相关文章
近期评论
-
你这基本没有更新呀，最近文章显示还是2019年的文章。不符合要求哈
-
关键词：慕云博客 链接：https://www.lilun.me 描述：分享原创文字的个人博客
-
-
-
可以提供一下源码吗
-
不是商业站，鸡娃学习笔记
-
-
-
-
听他们说很厉害的样子
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
