背景：
SpringCloud Eureka 投入使用很久了，server介面一直有紅色提示：

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保護機制，甚至可以延伸到分散式基礎CAP理論，我們來研究下吧~

一、Eureka 保護機制

Eureka Server 在執行期間會去統計心跳失敗比例在 15 分鐘

Web介面可以看到2個引數：

Renews threshold ：Eureka Server 期望每分鐘收到客戶端例項續約的總數。
Renews (last min)

Renews threshold的計算公式：

    protected void updateRenewsPerMinThreshold() {
            this.numberOfRenewsPerMinThreshold = (int) (this.expectedNumberOfClientsSendingRenews
                    * (60.0 / serverConfig.getExpectedClientRenewalIntervalSeconds())
                    *
 
 serverConfig.getRenewalPercentThreshold());
        }

自我保護閥值 = 服務總數（包括自注冊） * 每分鐘續約數 * 自我保護續約百分比閥值因子（eureka.server.renewal-percent-threshold：預設0.85）。

其中 每分鐘續約數 =（60S/客戶端續約間隔 lease-renewal-interval-in-seconds：預設30s）

自我保護模式啟用邏輯：

Eureka Server提供了一個EvictionTask定時（eviction-interval-timer-in-ms: 預設60s）清理續約超時的服務。清理之前首先判斷是否需要清理（isLeaseExpirationEnabled()）。

public boolean isLeaseExpirationEnabled() {
        if (!isSelfPreservationModeEnabled()) {
            // The self preservation mode is disabled, hence allowing the instances to expire.
            return true;
        }
        return numberOfRenewsPerMinThreshold > 0 && getNumOfRenewsInLastMin() > numberOfRenewsPerMinThreshold;

這個判斷方法首先會判斷是否開啟了自我保護開關（enable-self-preservation），如果開啟了，則會繼續判斷上一分鐘的續約數是否小於自我保護閥值，如果上一分鐘的續約數（numOfRenewsInLastMin）小於自我保護閥值(numberOfRenewsPerMinThreshold),則開啟自我保護機制，不再進行服務的剔除。

二、解決方法

解決方式一般有三種：

1.關閉自我保護模式

在server端配置：

# 關閉保護機制，預設為true
eureka.server.enable-self-preservation: false          			

# 清理無效節點的時間間隔，預設60s（注：如果不新增這個配置，即使eureka.instance.lease-expiration-duration-in-seconds配置時間很短，也不會馬上剔除節點）
eureka.server.eviction-interval-timer-in-ms: 4000				

在client端配置：

# 定義服務失效時間，Eureka服務端收到最後一次心跳之後等待的時間上限，超過該時間之後服務端會將該服務例項從服務清單中剔除，從而禁止服務呼叫請求被髮送到該例項上，單位：秒（預設90s）
lease-expiration-duration-in-seconds: 10

# 定義心跳間隔時間，Eureka客戶端向服務端傳送心跳的時間間隔，單位：秒（預設30s）
# 注意：這種調高頻率的操作只適用於例項較少的Eureka叢集，因為會增加叢集通訊壓力
lease-renewal-interval-in-seconds: 5

2.降低renewalPercentThreshold的比例
將eureka.server.renewal-percent-threshold比例降低到預設值0.85以下，比如0.4

3.部署多個 Eureka Server 並開啟其客戶端註冊
將eureka.client.register-with-eureka不要設為false，預設為true（待測試）

個人建議：測試環境可以關閉保護模式，生產環境最好開啟保護模式，部署多個 Eureka Server並開啟client註冊！

Eureka 的自我保護模式是有意義的，該模式被啟用後，它不會從註冊列表中剔除因長時間沒收到心跳導致租期過期的服務，而是等待修復，直到心跳恢復正常之後，它自動退出自我保護模式。這種模式旨在避免因網路分割槽故障導致服務不可用的問題。

例如，兩個客戶端例項 C1 和 C2 的連通性是良好的，但是由於網路故障，C2 未能及時向 Eureka 傳送心跳續約，這時候 Eureka 不能簡單的將 C2 從登錄檔中剔除。因為如果剔除了，C1 就無法從 Eureka 伺服器中獲取 C2 註冊的服務，但是這時候 C2 服務是可用的。

三、擴充套件：CAP理論

CAP理論，指的是在一個分散式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分割槽容錯性），三者不可得兼。

一致性（C）：在分散式系統中的所有資料備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的資料副本）

可用性（A）：在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求。（對資料更新具備高可用性）

分割槽容忍性（P）：大多數分散式系統都分佈在多個子網路。每個子網路就叫做一個區（partition）。分割槽容錯的意思是，區間通訊可能失敗。比如，一臺伺服器放在中國，另一臺伺服器放在美國，這就是兩個區，它們之間可能無法通訊；

一般來說，分割槽容錯無法避免，因此可以認為 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A 無法同時做到

在分散式系統的設計中，沒有一種設計可以同時滿足一致性，可用性，分割槽容錯性 3個特性；
注意：不要將 弱一致性、最終一致性 放到CAP理論裡混為一談

那麼我們對這三者如何權衡？

犧牲分割槽容錯性 (CA)

作為分散式系統，分割槽必然總會發生(2年1次50分鐘還是1年3次共10分鐘?)，因此認為CAP的討論是大部分建立在P確立前提下。假設我們犧牲了P這個時候因為網路故障發生了分割槽導致節點不可用，這個時候請求響應了error、timeout，與可用性的定義相沖突了。

但是，我們又假如分割槽大部分時間是不存在的，這時對單節點的讀\寫，那麼就無需作出C、A的取捨。但是上面說分割槽總會發生這不互相矛盾麼，還是取捨。假如1年時間內99.99%時間是正常的，不可用時間為0.01%(52.56分鐘)不可用，若這個時間屬於業務接受範圍，或者只在某個地區(華南、華北、華中?)有影響，那麼CA也是可以選擇的。

犧牲可用性 (PC)

最典型的案例是RDBMS叢集與Redis叢集，這兩種都是利用主從複製實現讀寫分離的方案。假如兩者都是建立一主多從的叢集，在主節點寫入資料，為了保證隨後的讀操作獲取最新資料(一致性)，這個讀操作仍會請求主節點(讀寫分離的複雜點在從庫同步不及時導致業務的異常，為了保證業務的正常性寫後的讀會請求主庫)，某個從節點掛了但是隻要主節點和其他從節點仍然正常運作，就滿足分割槽容錯性。但是哪天主節點因為網路故障導致寫操作的error或者timeout，那麼這個系統就不可用了(犧牲可用性)。

這個時候可以引入其他功能和機制完成，例如Redis哨兵模式、故障轉移功能。

犧牲一致性 (PA)

最典型的案例是Cassanda叢集和Riak叢集，這種型別的分散式資料庫，可以任意節點寫入，任意節點讀取，當作為叢集出現，無論寫入哪個節點，都將會把該節點的資料同步到其他節點上，因為這種同步方式，讀取資料時只要訪問一個節點就足夠了(喜歡任意訪問也不攔著你)，但是因為其他節點資料同步原因，資料可能並不是最新的(犧牲一致性)。如果當前節點因為網路異常導致分割槽變得不可用(無論讀\寫)，可以轉移訪問節點(可用性)。

另外這裡說的犧牲一致性，並不代表放棄一致性，而PA選擇的是最終一致性(系統中所有的資料副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態)

Eureka在CAP理論當中是屬於PA ， 根據前面研究的保護機制，當產生網路分割槽時，Eureka保證系統的可用性，但不保證系統裡面資料的一致性， 舉個例子。當發生網路分割槽的時候，Eureka-Server和client端的通訊被終止，server端收不到大部分的client的續約，這個時候，如果直接將沒有收到心跳的client端自動剔除，那麼會將可用的client端剔除，這不符合AP理論，所以Eureka寧可保留也許已經宕機了的client端 ， 也不願意將可以用的client端一起剔除。 從這一點上，也就保證了Eureka程式的健壯性，符合AP理論