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。

---

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