程序員筆記|詳解Eureka緩存機制-創(chuàng)新互聯(lián)

引言

Eureka是Netflix開源的、用于實現(xiàn)服務注冊和發(fā)現(xiàn)的服務。Spring Cloud Eureka基于Eureka進行二次封裝，增加了更人性化的UI，使用更為方便。但是由于Eureka本身存在較多緩存，服務狀態(tài)更新滯后，最常見的狀況是：服務下線后狀態(tài)沒有及時更新，服務消費者調用到已下線的服務導致請求失敗。本文基于Spring Cloud Eureka 1.4.4.RELEASE，在默認region和zone的前提下，介紹Eureka的緩存機制。

成都創(chuàng)新互聯(lián)公司長期為上1000+客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為金城江企業(yè)提供專業(yè)的網(wǎng)站設計制作、成都網(wǎng)站設計，金城江網(wǎng)站改版等技術服務。擁有10年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。一、AP特性

從CAP理論看，Eureka是一個AP系統(tǒng)，優(yōu)先保證可用性(A)和分區(qū)容錯性(P)，不保證強一致性(C)，只保證最終一致性，因此在架構中設計了較多緩存。

二、服務狀態(tài)

Eureka服務狀態(tài)enum類：com.netflix.appinfo.InstanceInfo.InstanceStatus

狀態(tài)	說明	狀態(tài)	說明
UP	在線	OUT_OF_SERVICE	失效
DOWN	下線	UNKNOWN	未知
STARTING	正在啟動

三、Eureka Server

在Eureka高可用架構中，Eureka Server也可以作為Client向其他server注冊，多節(jié)點相互注冊組成Eureka集群，集群間相互視為peer。Eureka Client向Server注冊、續(xù)約、更新狀態(tài)時，接受節(jié)點更新自己的服務注冊信息后，逐個同步至其他peer節(jié)點。

【注意】如果server-A向server-B節(jié)點單向注冊，則server-A視server-B為peer節(jié)點，server-A接受的數(shù)據(jù)會同步給server-B，但server-B接受的數(shù)據(jù)不會同步給server-A。

3.1 緩存機制

Eureka Server存在三個變量：(registry、readWriteCacheMap、readOnlyCacheMap)保存服務注冊信息，默認情況下定時任務每30s將readWriteCacheMap同步至readOnlyCacheMap，每60s清理超過90s未續(xù)約的節(jié)點，Eureka Client每30s從readOnlyCacheMap更新服務注冊信息，而UI則從registry更新服務注冊信息。

三級緩存

緩存	類型	說明
registry	ConcurrentHashMap	實時更新，類AbstractInstanceRegistry成員變量，UI端請求的是這里的服務注冊信息
readWriteCacheMap	Guava Cache/LoadingCache	實時更新，類ResponseCacheImpl成員變量，緩存時間180秒
readOnlyCacheMap	ConcurrentHashMap	周期更新，類ResponseCacheImpl成員變量，默認每30s從readWriteCacheMap更新，Eureka client默認從這里更新服務注冊信息，可配置直接從readWriteCacheMap更新

緩存相關配置

###

配置	默認	說明
eureka.server.useReadOnlyResponseCache	true	Client從readOnlyCacheMap更新數(shù)據(jù)，false則跳過readOnlyCacheMap直接從readWriteCacheMap更新
eureka.server.responsecCacheUpdateIntervalMs	30000	readWriteCacheMap更新至readOnlyCacheMap周期，默認30s
eureka.server.evictionIntervalTimerInMs	60000	清理未續(xù)約節(jié)點(evict)周期，默認60s
eureka.instance.leaseExpirationDurationInSeconds	90	清理未續(xù)約節(jié)點超時時間，默認90s

關鍵類

類名	說明
com.netflix.eureka.registry.AbstractInstanceRegistry	保存服務注冊信息，持有registry和responseCache成員變量
com.netflix.eureka.registry.ResponseCacheImpl	持有readWriteCacheMap和readOnlyCacheMap成員變量

四、Eureka Client

Eureka Client存在兩種角色：服務提供者和服務消費者，作為服務消費者一般配合Ribbon或Feign（Feign內(nèi)部使用Ribbon）使用。Eureka Client啟動后，作為服務提供者立即向Server注冊，默認情況下每30s續(xù)約(renew)；作為服務消費者立即向Server全量更新服務注冊信息，默認情況下每30s增量更新服務注冊信息；Ribbon延時1s向Client獲取使用的服務注冊信息，默認每30s更新使用的服務注冊信息，只保存狀態(tài)為UP的服務。

二級緩存

緩存	類型	說明
localRegionApps	AtomicReference	周期更新，類DiscoveryClient成員變量，Eureka Client保存服務注冊信息，啟動后立即向Server全量更新，默認每30s增量更新
upServerListZoneMap	ConcurrentHashMap	周期更新，類LoadBalancerStats成員變量，Ribbon保存使用且狀態(tài)為UP的服務注冊信息，啟動后延時1s向Client更新，默認每30s更新

緩存相關配置

配置	默認	說明
eureka.instance.leaseRenewalIntervalInSeconds	30	Eureka Client 續(xù)約周期，默認30s
eureka.client.registryFetchIntervalSeconds	30	Eureka Client 增量更新周期，默認30s（正常情況下增量更新，超時或與Server端不一致等情況則全量更新）
ribbon.ServerListRefreshInterval	30000	Ribbon 更新周期，默認30s

關鍵類

類名	說明
com.netflix.discovery.DiscoveryClient	Eureka Client 負責注冊、續(xù)約和更新，方法initScheduledTasks()分別初始化續(xù)約和更新定時任務
com.netflix.loadbalancer.PollingServerListUpdater	Ribbon 更新使用的服務注冊信息，start初始化更新定時任務
com.netflix.loadbalancer.LoadBalancerStats	Ribbon，保存使用且狀態(tài)為UP的服務注冊信息

五、默認配置下服務消費者最長感知時間

Eureka Client	時間	說明
上線	30(readOnly)+30(Client)+30(Ribbon)=90s	readWrite -> readOnly -> Client -> Ribbon 各30s
正常下線	30(readonly)+30(Client)+30(Ribbon)=90s	服務正常下線（kill或kill -15殺死進程）會給進程善后機會，DiscoveryClient.shutdown()將向Server更新自身狀態(tài)為DOWN，然后發(fā)送DELETE請求注銷自己，registry和readWriteCacheMap實時更新，故UI將不再顯示該服務實例
非正常下線	30+60(evict)*2+30+30+30=240s	服務非正常下線（kill -9殺死進程或進程崩潰）不會觸發(fā)DiscoveryClient.shutdown()方法，Eureka Server將依賴每60s清理超過90s未續(xù)約服務從registry和readWriteCacheMap中刪除該服務實例

考慮如下情況

• 0s時服務未通知Eureka Client直接下線；
• 29s時第一次過期檢查evict未超過90s；
• 89s時第二次過期檢查evict未超過90s；
• 149s時第三次過期檢查evict未續(xù)約時間超過了90s，故將該服務實例從registry和readWriteCacheMap中刪除；
• 179s時定時任務從readWriteCacheMap更新至readOnlyCacheMap;
• 209s時Eureka Client從Eureka Server的readOnlyCacheMap更新；
• 239s時Ribbon從Eureka Client更新。

因此，極限情況下服務消費者最長感知時間將無限趨近240s。

六、應對措施

服務注冊中心在選擇使用Eureka時說明已經(jīng)接受了其優(yōu)先保證可用性(A)和分區(qū)容錯性(P)、不保證強一致性(C)的特點。如果需要優(yōu)先保證強一致性(C)，則應該考慮使用ZooKeeper等CP系統(tǒng)作為服務注冊中心。分布式系統(tǒng)中一般配置多節(jié)點，單個節(jié)點服務上線的狀態(tài)更新滯后并沒有什么影響，這里主要考慮服務下線后狀態(tài)更新滯后的應對措施。

6.1 Eureka Server

• 1.縮短readOnlyCacheMap更新周期?？s短該定時任務周期可減少滯后時間。

  eureka.server.responsecCacheUpdateIntervalMs: 10000  # Eureka Server readOnlyCacheMap更新周期

• 2.關閉readOnlyCacheMap。中小型系統(tǒng)可以考慮該方案，Eureka Client直接從readWriteCacheMap更新服務注冊信息。

  eureka.server.useReadOnlyResponseCache: false        # 是否使用readOnlyCacheMap

6.2 Eureka Client

• 1.服務消費者使用容錯機制。如Spring Cloud Retry和Hystrix，Ribbon、Feign、Zuul都可以配置Retry，服務消費者訪問某個已下線節(jié)點時一般報ConnectTimeout，這時可以通過Retry機制重試下一個節(jié)點。

• 2.服務消費者縮短更新周期。Eureka Client和Ribbon二級緩存影響狀態(tài)更新，縮短這兩個定時任務周期可減少滯后時間，例如配置：

  eureka.client.registryFetchIntervalSeconds: 5        # Eureka Client更新周期
  ribbon.ServerListRefreshInterval: 2000               # Ribbon更新周期

• 3.服務提供者保證服務正常下線。服務下線時使用kill或kill -15命令，避免使用kill -9命令，kill或kill -15命令殺死進程時將觸發(fā)Eureka Client的shutdown()方法，主動刪除Server的registry和readWriteCacheMap中的注冊信息，不必依賴Server的evict清除。

• 4.服務提供者延遲下線。服務下線之前先調用接口使Eureka Server中保存的服務狀態(tài)為DOWN或OUT_OF_SERVICE后再下線，二者時間差根據(jù)緩存機制和配置決定，比如默認情況下調用接口后延遲90s再下線服務即可保證服務消費者不會調用已下線服務實例。

七、網(wǎng)關實現(xiàn)服務下線實時感知

在軟件工程中，沒有一個問題是中間層解決不了的，而網(wǎng)關是服務提供者和服務消費者的中間層。以Spring Cloud Zuul網(wǎng)關為例，網(wǎng)關作為Eureka Client保存了服務注冊信息，服務消費者通過網(wǎng)關將請求轉發(fā)給服務提供者，只需要做到服務提供者下線時通知網(wǎng)關在自己保存的服務列表中使該服務失效。為了保持網(wǎng)關的獨立性，可實現(xiàn)一個獨立服務接收下線通知并協(xié)調網(wǎng)關集群。下篇文章將詳細介紹網(wǎng)關如何實現(xiàn)服務下線實時感知，敬請期待！

作者：馮永彪

內(nèi)容來源：宜信技術學院

名稱欄目：程序員筆記|詳解Eureka緩存機制-創(chuàng)新互聯(lián)
地址分享：http://www.jbt999.com/article32/ceogpc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供服務器托管、小程序開發(fā)、做網(wǎng)站、Google、定制開發(fā)、網(wǎng)站設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：[email protected]。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)