eureka快取細節以及生產環境的最佳配置
eureka作為spring cloud微服務架構里的注冊中心，是非常核心的一個組件，它避免了復雜的選主演算法，架構比較簡單，搭個demo也確實很快，但是如果要用于生產環境，還是得注意很多東西，尤其是下線延遲…
服務獲取中的快取問題
本節的內容都是從這個issue翻譯的：Documentation: changing Eureka renewal frequency WILL break the self-preservation feature of the server
為什么修改client的默認心跳時間，會導致自我保護模式失效？
Eureka Service會認為客戶端是以30s的頻率來發送心跳的，服務端期望收到的最大心跳時間是：
n instances x 2(60s/30s) x threshold
如果是2個實體，Eureka會期望每分鐘有：2 instances x 2 x 85% =3.4個心跳,也就是說需要3個心跳，
如果client的心跳改成15s，掛掉一個，另一個在1min內會發出4個心跳，而這時候的閾值還是3.4個，自我保護模式就失效了，
核心原因就是在Eureka Server計算期望心跳數的時候寫死了每分鐘的心跳間隔，即30秒，所以他永遠會是*2(感覺像是新手寫的代碼啊啊啊 -_-)
還有一個引數可以調整，eureka.server.renewalThresholdUpdateIntervalMs，心跳閾值重新計算的周期，默認15分鐘，可以改短一點，2min
客戶端首次注冊時間為什么要30s？如何改進？
首次注冊行為是和首次心跳系結在一起的，首次心跳發送以后會收到not found的回應,client就知道還沒注冊過，client就會馬上注冊，首次心跳由引數
eureka.instance.leaseRenewalIntervalInSeconds控制的，默認30
可以通過eureka.client.initialInstanceInfoReplicationIntervalSeconds引數來加快首次注冊的速度，他是控制首次改變實體狀態（UP/DOWN ）的時間，啟動的時候狀態肯定是需要改變的，所以他可以用來加快首次注冊速度，并且改變這個值不會影響到保護模式
另外如果你使用的是spring cloud eureka的話沒首次注冊延遲的問題，他會馬上注冊
其他影響快速獲取服務資訊的因素
【服務端快取】
因為服務端默認會有個read only response cache（下面會細說），每30秒更新一次(eureka.server.response-cache-update-interval-ms),所以可能注冊了不是馬上能看到（雖然通過rest api不能看到，但是你可以在web ui上看到，因為ui沒有快取）
【客戶端快取】
Eureka Client快取的定期更新周期，他由eureka.client.registryFetchIntervalSeconds控制，默認30秒， 改成5秒
【Ribbon快取】
如果你采用Ribbon來訪問服務，那么這里會有個快取（他的資料來源是本地Eureka Client快取），他由ribbon. ServerListRefreshInterval控制，默認30秒， 改成2秒
怎么更快的踢掉沒有心跳的機器
eureka.instance.leaseExpirationDurationInSeconds，這個值用來控制多久踢掉機器，默認是3個心跳周期，有點久，可以考慮改成2個，他不會影響到保護模式（如果開啟自我保護模式，心跳間隔因為上面的bug不能改，只能改這個了 -_-）
服務端快取細節
Eureka內部的快取分很多級，主要有registry、readWriterCacheMap、readOnlyCacheMap；另外還有一個維護最近180s增量的佇列recentlyChangedQueue
寫操作
包括注冊、取消注冊等，都直接操作在registry上，同時也會更新recentlyChangedQueue和readWriterCacheMap
讀操作
讀默認是從readOnlyCacheMap讀取，讀不到的話再從readWriterCacheMap，還沒有再從registry
濫用快取的讀操作
這個讀操作的三級快取結構，非常讓人困惑，registry已經是ConcurrentHashMap，純記憶體操作，性能非常高了，為什么前面還要加兩級快取；readWriterCacheMap的資料是在寫入以后responseCacheAutoExpirationInSeconds(默認180)秒內失效，readOnlyCacheMap則是一個定時任務，每responseCacheUpdateIntervalMs(默認30)秒從readWriterCacheMap獲取最新資料
去掉readOnlyCacheMap
從CAP理論上看，Eureka是一個AP系統，但是在C層面這么弱，就是因為各種無謂的快取造成的，看了下readWriterCacheMap去掉比較難，但是readOnlyCacheMap有一個開關useReadOnlyResponseCache，果斷關掉！！
Time Lag
最后再來看下Eureka wiki中提到的2min time lag問題，其實分多個角度看，不一定是2min
服務正常上線/修改，最大可能會有120s滯后
- 30(首次注冊 init registe) + 30(readOnlyCacheMap)+30(client fetch interval)+30(ribbon)=120
- 如果是在Spring Cloud環境下使用這些組件(Eureka, Ribbon)，不會有首次注冊30秒延遲的問題，服務啟動后會馬上注冊,所以從注冊到發現，最多可能是90s，
服務例外下線：最大可能會有270s滯后
- 定時清理任務每eureka.server. evictionIntervalTimerInMs(默認60)執行一次清理任務
- 每次清理任務會把90秒(3個心跳周期，eureka.instance.leaseExpirationDurationInSeconds)沒收到心跳的踢除，但是根據官方的說法 ，因為代碼實作的bug，這個時間其實是兩倍，即180秒，也就是說如果一個客戶端因為網路問題或者主機問題例外下線，可能會在180秒河駁除
- 讀取端，因為readOnlyCacheMap以及客戶端快取的存在，可能會在30(readOnlyCacheMap)+30(client fetch interval)+30(ribbon)=90
- 所以極端情況最終可能會是180+90=270
生產環境最佳配置
總結前面3點，經過梳理后，推薦的生產環境最佳配置如下：（可用于中小規模環境）：
Eureka Server端配置
1
|
## 中小規模下，自我保護模式坑比好處多，所以關閉它
|
服務提供者和clinet配置
## 心跳間隔，5秒
eureka.instance.leaseRenewalIntervalInSeconds=5
## 沒有心跳的淘汰時間，10秒
eureka.instance.leaseExpirationDurationInSeconds=10
# 定時重繪本地快取時間
eureka.client.registryFetchIntervalSeconds=5
# ribbon快取時間
ribbon.ServerListRefreshInterval=2000
改成上面配置后:
-
正常上線下線客戶端最大感知時間：eureka.client.registryFetchIntervalSeconds+ribbon. ServerListRefreshInterval = 7秒
-
例外下線客戶端最大感知時間：
2*eureka.instance.leaseExpirationDurationInSeconds+
eureka.server.evictionIntervalTimerInMs+
eureka.client.registryFetchIntervalSeconds+
ribbon. ServerListRefreshInterval = 3
一些參考：
- Spring Cloud Eureka源代碼決議（2） EurekaServer 重要快取決議
- Eureka 原始碼決議 —— 應用實體注冊發現（五）之過期
- Spring Cloud Eureka決議（3） EurekaClient 重要快取決議
- Spring Cloud Netflix Eureka - 揭秘手冊
- Spring Boot環境下Eureka的暴力Shutdown本地服務
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/174984.html
標籤：Java
下一篇：用戶密碼到底要怎么加密存盤？