Spring Cloud Eureka 自我保護機制實戰分析

前些天棧長在Java技術棧微信公衆號分享過 Spring Cloud Eureka 的系列文章：

• Spring Cloud Eureka 自我保護機制
• Spring Cloud Eureka 經常使用配置詳解

其中，可能你們關於自我機制的具體保護邏輯還不是特別清楚，今天棧長就具體分析和實戰一下，自我保護機制究竟是怎麼工做的。

如今咱們把保護機制開啓：

關注右上角的兩個重要參數：

參數	說明
Renews threshold	Eureka Server 指望每分鐘收到客戶端實例的總心跳數
Renews (last min)	Eureka Server 最後一分鐘收到的總心跳數

我這裏顯示的數值以下：

Renews threshold	6
Renews (last min)	8

這個 6 和 8 分別是怎麼算出來的？

先來看這兩個參數的默認設置，摘自《Spring Cloud Eureka 經常使用配置詳解》一文：

eureka.server.renewal-percent-threshold： 表示 Eureka Server 開啓自我保護的係數，默認：0.85。

eureka.instance.lease-renewal-interval-in-seconds： 表示 Eureka Client 向 Eureka Server 發送心跳的頻率（默認 30 秒），若是在 lease-expiration-duration-in-seconds 指定的時間內未收到心跳，則移除該實例。

這裏有 4 個註冊實例，保護係數：0.85，心跳頻率：30秒（每分鐘兩次），計算公式以下：

Renews threshold = 4 * 2 * 0.85 = 6.8（取整爲：6）
Renews (last min) = 4 * 2 = 8

如今刪除一個配置中心實例測試一下：

出現警告：

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.

說明如今 Eureka Server 已經進行保護模式了，而且我刪除的那個實例並不會從註冊列表中移除，保護機制生效成功。

由此可知：Eureka Server 在一分鐘內若是沒有收到 6 個以上的心跳，即：Renews threshold >= Renews (last min)，若是保護機制已開啓的狀況下，則會開啓保護機制。

爲何移除一個實例後，Renews threshold 仍是 6 呢，算出來應該是 5，這是由於 Eureka Server 還沒刷新這個值，默認 15 分鐘刷新一次，能夠經過設計如下值進行調整：

eureka.server.renewal-threshold-update-interval-ms=900000

瞭解了心跳策略和保護機制後，對註冊中心的平常維護就會有不少幫助。

好了，今天的分享就到這裏了，建議轉發收藏，再也不迷路。

後續會分享更多 Eureka 高級玩法，棧長正在拼命撰寫中……關注Java技術棧微信公衆號可獲取及時推送。在公衆號後臺回覆：cloud，獲取棧長整理的更多的 Spring Cloud 教程，都是實戰乾貨，如下僅爲部分預覽。

• Spring Cloud 配置中心高可用搭建
• Spring Cloud 多版本如何選擇
• Spring Cloud 是什麼，和 Dubbo 對比
• Spring Cloud 註冊中心高可用搭建
• Spring Cloud Eureka 自我保護機制
• ……

本文原創首發於微信公衆號：Java技術棧（id:javastack），關注公衆號在後臺回覆 "cloud" 可獲取更多 Spring Cloud 教程，轉載請原樣保留本信息。