Eureka常見問題解答
什麼情況下會開啟自我保護機制？
前提說明
Eureka Server 內部維護了兩個變數 ：
每次客戶端來續約時，都會更新一個變數，即每分鐘的續約次數 renewsLastMin ， 該變數維護著所有客戶端每分鐘的續約次數。
何時開啟
Eureka Server 每60秒會自動清理一下過期的客戶端，在清理之前會判斷一下 是否需要自我保護，每次都會判斷。
何時解除
1.客戶端的心跳恢復正常
2.重啟服務
網路波動，集群同步的問題
Eureka Server 允許同一時刻被任意Eureka Client做寫入操作， 當發生客戶端向Eureka Server 1發起註冊時，明明
在Eureka Server註冊成功了，但是返回結果的時候，發生網路錯誤，誤讓Eureka Client 認為server 1不可用,正好這個時候Eureka Client的狀態發生變更（會去修改laseDirtyTimestamp），進而像server 2發起註冊， 這個時候問題就來了。
server1 和 server2 上面的實例狀態不一致。
但是由於Eureka Server服務有如下機制，可以確保集群狀態下數據的最終一致性；
1.當向server 2 註冊之後， server 2 會同時向server 1 同步client端的註冊信息，server 1由於之前被client註冊過，同時也向server 2同步註冊信息 ， 這就造成了，兩個Eureka Server互相同步請求的問題， 這個時候就是 通過 lastDirtyTimestamp這個變數來判定以誰的為準， 誰的lastDirtyTimestamp 大，則以誰的為準。
2.單單通過lastDirtyTimestamp 這個機制，並沒有辦法保證集群之間的數據一致性，當網路出現異常的之後，集群同步
請求一直不成功，同時任務的過期時間已經到了（集群同步是通過發布任務，讓多線程批量去處理的，同時任務有過期
時間），這個時候會造成集群之間的數據不一致的情況，這個時候，就是通過heatbeat機制， 當心跳發生如下三種情
況的是，客戶端會重新發起註冊：
當客戶端的lastDirtyTimestamp> 大於服務端的instance的lastDirtyTimestamp時候，會認為服務端的信息是無效的，因此無法續約，需要重新發起註冊請求。
服務端的註冊信息不存在
服務端的instance的status = UNKONW， 為什麼會出現UNKONW這個狀態呢，因為在deleteStatusOverride
的時候存在傳入UNKONW的可能性。
通過以上機制，保證了在網路異常的情況下，Eureka Server能夠在網路恢復後，達到最終一致性。
Eureka Server端實例過期，會同步到其他server伺服器嗎？
實例過期不會同步到集群中其他伺服器，每個Eureka Server 內部都有自己的過期定時任務，每個server
自己負責清理自己的，互不相干，會觸發同步操作的是如下幾個操作，
register 註冊
renew 心跳續約
cancle 客戶端主動下線
stateUpdate 添加覆蓋狀態
deleteStateovrride 刪除覆蓋狀態
Eureka Client剛啟動是否會立即註冊？
網上有些誤導人的博客，說Eureka Client啟動之後會等待40秒之後才會向Eureka Server端註冊。
Eureka Server集群宕機後，客戶端是否可用？
情景一
Eureka Client 啟動的時候，會主動去全量獲取一次註冊信息，如果這個時候Eureka Server集群
已經宕機，那麼Eureka Client端是不可用的。
情景二
如果Eureka Client 啟動時全量獲取註冊信息成功，在之後的運行過程當中，Eureka Server集群宕機了
那麼這個時候，Eureka Client是不受影響的，Eureka Client會緩存註冊信息在本地，如果後續增量獲取
註冊信息失敗，也不會影響本地現有的註冊信息。 唯一影響的是，由於Eureka Client所擁有的數據
得不到更新，這個時候，新增客戶端，或者有客戶端的信息發生變化，那麼Eureka Client是感知不到的。
關鍵的時間間隔說明
Eureka Client：
更新本地註冊信息 默認：30秒
發送心跳 默認：30秒
檢查應用信息，如果發生變化，則重新發起註冊 默認：30秒
Eureka Server：
只讀緩存過期時間 默認：30秒
讀寫緩存過期時間 默認：180秒
清理過期的任務 默認：60秒
租約過期時間 默認：90秒
啟動時同步節點數據，為空等待時間 默認：30秒
清空每分鐘續約次數 默認：60秒
Eureka Client 90秒沒有心跳一定會過期嗎？
答案是，不一定會過期
情景一
自我保護模式的開啟
情景二
Eureka Server中租約過期時間默認是90秒，服務端維護了一個lastUpdaeTimestap這個變數，
用來表示最後修改時間，至於為什麼90秒不一定會過期，看下代碼即可：
但是由於在續約的時候，更新lastUpdateTimestap是這樣的：
由上可以看出，這個地方，更新最後修改時間，是用當前時間加了90秒上去的，那麼接下來看下
Eureka Server是如何判斷過期的呢。
evictionTimestamp ： 為下線時間，在下線操作的時候會更新這個值
其實，主要是看後面一段，撇開additionalLeaseMs這個時間偏差不談，
當前時間，一定要大於最後修改時間+90秒， 由於最後修改時間，在續約的時候已經加了90秒了
這裡再加個90秒，就是180秒，要大於最後修改時間180秒才會被判定為過期。
TAG:sharedCode |