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。

---

想获取最新内容，请关注微信公众号