一、前言

上一講我們講到了 Eureka 注冊中心的 Server 端有三級緩存來保存注冊信息，可以利用緩存的快速讀取來提高系統性能。我們再來細看下：

一級緩存：只讀緩存 readOnlyCacheMap，數據結構 ConcurrentHashMap。相當于數據庫。

二級緩存：讀寫緩存 readOnlyCacheMap，Guava Cache。相當于 Redis 主從架構中主節點，既可以進行讀也可以進行寫。

三級緩存：本地注冊表 registry，數據結構 ConcurentHashMap。相當于 Redis 主從架構的從節點，只負責讀。

看圖更清晰，如下圖所示：

三種緩存

另外 ConcurrenthashMap 也是一種 map 結構，也就是以鍵值對的方式進行存儲，如下圖所示：

Map 結構

本篇悟空哥會帶著大家來看下 Eureka 的緩存架構是怎么樣，通過學習這篇，我們也可以借鑒 Eureka 的緩存設計思想，將其運用到項目當中。

二、引發的幾個思考

我們再來看下 Eureka 源碼，其實不難看懂，下面會做解釋。

• 默認會先從只讀緩存里面找。
• 沒有的話，再從讀寫緩存里面找。
• 找到了的話就更新只讀緩存，并返回找到的緩存。
• 還找不到的話，就從本地緩存 registry 中加載進來。

帶來了三個問題：

(1)三級緩存數據怎么來的?

(2)緩存數據如何更新的?

(3)緩存如何過期?

三、本地緩存

我們先來看下本地緩存 registry，它是一種定義為 ConcurrentHashMap 的數據結構，之前也詳細講解過。

當客戶端發起注冊請求的時候，就會把注冊信息放到 registry 中。如下代碼所示：

registry.putIfAbsent(app) 

putIfAbsent 表示如果存在重復的 key，就不會放入值，如果傳入的 key 對應的 value 已經存在，就返回存在的 value，不進行替換。

經過 putIfAbsent 操作就把客戶端的注冊信息放到 registry 中了。

我們再來看下其中的一種緩存結構：讀寫緩存。

四、讀寫緩存

讀寫緩存，顧名思義，就是既可以進行讀，也可以進行寫的緩存。讀主要是給只讀緩存來讀取的。寫主要是將緩存更新到自己的 Map 中。

下面分別從寫緩存的原理、寫緩存的源碼、過期時機的原理、過期時機的源碼幾個方面來分別解答。

4.1 寫緩存的原理和源碼

我開始以為當我們讀緩存讀不到的時候，就會去數據庫查了。找了半天，沒找到讀數據庫的地方。

然后我就用 IDEA 工具查找 readOnlyCacheMap 被使用的地方，終于讓我找到了。

讀寫緩存用的是 Guava Cache工具類，這篇不會深究。簡單來說就是當訪問讀寫緩存時，如果這個 key 在緩存中不存在，則從本地去查，查到后再放回緩存。

然后又實現抽象方法 load(key)，這個方法的作用就是當讀寫緩存中沒有，則從本地 registry 緩存中拿。

讀寫緩存過期的時候其實分兩種：定時過期和實時過期。由于上面的源碼已經定義了定時過期的時間間隔，所以我們先來看定時過期。

4.2 定時過期

當構建這個讀寫緩存時，就會定義間隔多久過期整個讀寫緩存。如下代碼所示，180 s 會定時過期讀寫緩存。

expireAfterWrite(180s) 

4.3 實時過期

當有新的服務實例進行注冊或者下線、發生故障時，就會把這個對應的服務實例的緩存給過期掉。

如下圖所示，最上面的是注冊中心，下面三個是服務實例。服務實例發生注冊、下線、發生故障，注冊中心都是可以感知到的，然后就會主動過期讀寫緩存對應的服務實例。

4.4 實時過期源碼

從源碼層面我們再來看下讀寫緩存過期的源碼。調用了 invalidateCache 方法，進行過期。

文件路徑：com/netflix/eureka/registry/AbstractInstanceRegistry.java

五、只讀緩存

5.1 定時更新

只讀緩存 readOnlyCacheMap，有一個定時更新的機制，每隔 30 秒就會更新一次只讀緩存中的某些 key。

它其實是遍歷自己的所有注冊信息，然后和讀寫緩存進行比對，如果注冊信息不一致，則替換為讀寫緩存的數據。

源碼如下，有一個定時調度任務，每隔 30 秒調度一次。

5.2 更新

另外當客戶端獲取注冊信息時，也會先讀只讀緩存，如果只讀緩存中沒有，則會從讀寫緩存中找，找到后就放到只讀緩存中。如果讀寫緩存中沒有，則從本地注冊表 registry 中加載到讀寫緩存中，然后將注冊表信息返回。

這里大家是否有個疑問：既然這個緩存叫做只讀緩存，怎么還能被更新，不應該是不變的嗎?

其實這里的不變是相對于客戶端來說的，客戶端獲取注冊表信息時，最開始訪問的就是只讀緩存，類似數據庫或 Redis 的主從架構，主負責讀寫，從負責讀。然后系統內部會把主節點的信息同步給從節點。大家明白了嗎?

六、緩存相關配置

下面我們來看下 Eureka Server 對于緩存有哪些配置呢?

6.1 是否開啟只讀緩存

eureka.server.useReadOnlyResponseCache

當客戶端獲取注冊信息時，是否先從只讀緩存獲取。如果為 false，則直接從讀寫緩存獲取。默認為 true。

6.2 定時更新只讀緩存的間隔時間

eureka.server.responseCacheUpdateIntervalMs

默認每隔 30 秒將讀寫緩存更新的緩存同步到只讀緩存。

七、緩存帶來的問題

三級緩存看似可以帶來性能的提升。但是也會引入其他問題，比如緩存不一致問題。

只讀緩存每隔 30s 才會刷新一次，和讀寫緩存會造成數據的不一致，客戶端在 30s 內獲取的注冊表信息是滯后的。

當使用 Eureka 集群時，這種緩存不一致的問題會更明顯，不同的節點之間也會出現只讀緩存的數據不一致，所以 Eureka 只能保證高可用，并不能保證強一致性，也就是保證了 AP，不保證 CP，另外我們可以選用強一致性的注冊中心，比如 Zookeeper、Nacos，這是后續要講的內容了。

如何緩解不一致的問題呢?

(1)在服務端，我們可以設置更新只讀緩存的時間間隔，默認是 30 秒，縮短一點，比如 15 秒，頻率太高，可能對 Eureka 造成性能問題。

(2)服務端，我們也可以考慮關閉從只讀緩存讀注冊表信息，Eureka Client 直接從讀寫緩存讀取。

八、總結

Eureka Server 注冊表三級緩存架構

本篇學習了 Eureka 注冊中心 Server 端的三層緩存架構，分為 registry、readOnlyCacheMap、readWriteCacheMap，用來保存服務注冊信息。

• 默認情況下，每隔 30 秒從讀寫緩存將注冊信息更新到只讀緩存。
• 默認情況下，客戶端讀取注冊表時，先從只讀緩存讀，如果沒有，則從讀寫緩存中讀取，如果還是沒有，則從本地注冊表 registry 讀取。
• 默認情況下，每隔 180 秒定時過期讀寫緩存。
• 服務實例注冊、下線、故障時，會實時過期讀寫緩存。
• 引入了多級緩存，也會帶來緩存不一致的問題。

參考資料：

www.passjava.cn

《微服務架構深度解析》

 

Eureka 源碼