eureka的驚羣效應

 

序

最近一口氣發佈好幾個服務，涉及大約9個實例同時更新，而總共有16個服務實例註冊，出現了eureka開啓自我保護模式，過了好幾分鐘尚未恢復。

分析

設定的eureka.instance.leaseRenewalIntervalInSeconds爲10秒。eureka爲2個實例，eureka.server.renewalPercentThreshold爲0.85，而eureka.server.renewalThresholdUpdateIntervalMs爲900000。

按這麼算，正常的閾值爲27，而當9個服務重啓，則瞬間註冊的實例爲16+9=25，那麼此時閾值就更新爲42，而啓動的時候，舊的9個實例相續關閉，而新的9個實例相續尚未啓動起來，那麼實際每分鐘能發送心跳的數爲7*6=42.

是否開啓自我保護

eureka-core-1.4.12-sources.jar!/com/netflix/eureka/registry/PeerAwareInstanceRegistryImpl.java

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

最近1分鐘收到的心跳數沒有大於閾值，那麼這個時候，就開啓自我保護了。

小結

這個有點相似驚羣問題(thundering herd):

故障後的服務恢復上線後，若是有大量其餘服務正在同一個重試窗口內重試，此時很容易給系統形成巨大壓力。這種狀況也叫驚羣效應（Thundering herd），使用隨機化的重試窗口可輕鬆避免這種問題。若是基礎架構沒有實施斷路開關，建議將隨機化重試窗口與指數退避（Exponential backoff）配合使用以便讓請求進一步分散。

同理，對於使用eureka做爲服務發現的應用來講，在部署生產的要十分當心，要麼每次部署的實例不要太多，要麼修改eureka的相關參數，好比renewalPercentThreshold或者renewalThresholdUpdateIntervalMs。