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控制。

客戶端獲取增量信息，與本地緩存合併後通服務端的全量信息比較哈希值（哈希算法有特別實現，主要根據註冊應用內容）。若是哈希值不一樣，則增量獲取失敗，須要一次全量獲取。