一、前言

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

一級緩存：只讀緩存 readOnlyCacheMap，數(shù)據(jù)結(jié)構(gòu) ConcurrentHashMap。相當于數(shù)據(jù)庫。

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

三級緩存：本地注冊表 registry，數(shù)據(jù)結(jié)構(gòu) ConcurentHashMap。相當于 Redis 主從架構(gòu)的從節(jié)點，只負責讀。

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

三種緩存

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

Map 結(jié)構(gòu)

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

二、引發(fā)的幾個思考

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

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

帶來了三個問題：

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

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

(3)緩存如何過期?

三、本地緩存

我們先來看下本地緩存 registry，它是一種定義為 ConcurrentHashMap 的數(shù)據(jù)結(jié)構(gòu)，之前也詳細講解過。

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

registry.putIfAbsent(app) 

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

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

我們再來看下其中的一種緩存結(jié)構(gòu)：讀寫緩存。

四、讀寫緩存

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

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

4.1 寫緩存的原理和源碼

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

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

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

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

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

4.2 定時過期

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

expireAfterWrite(180s) 

4.3 實時過期

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

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

4.4 實時過期源碼

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

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

五、只讀緩存

5.1 定時更新

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

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

源碼如下，有一個定時調(diào)度任務(wù)，每隔 30 秒調(diào)度一次。

5.2 更新

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

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

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

六、緩存相關(guān)配置

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

6.1 是否開啟只讀緩存

eureka.server.useReadOnlyResponseCache

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

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

eureka.server.responseCacheUpdateIntervalMs

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

七、緩存帶來的問題

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

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

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

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

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

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

八、總結(jié)

Eureka Server 注冊表三級緩存架構(gòu)

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

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

參考資料：

www.passjava.cn

《微服務(wù)架構(gòu)深度解析》

 

Eureka 源碼