服务端缓存
服务端的注册信息读取使用缓存，而非直接读取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控制。
客户端获取增量信息，与本地缓存合并后通服务端的全量信息比较哈希值（哈希算法有特别实现，主要根据注册应用内容）。如果哈希值不同，则增量获取失败，需要一次全量获取。
