eureka的惊群效应

codecraft

最近一口气发布好几个服务,涉及大约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。


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

图片描述

阅读 2.6k

code-craft
spring boot , docker and so on 欢迎关注微信公众号: geek_luandun

当一个代码的工匠回首往事时,不因虚度年华而悔恨,也不因碌碌无为而羞愧,这样,当他老的时候,可以很...

11.5k 声望
1.9k 粉丝
0 条评论
你知道吗?

当一个代码的工匠回首往事时,不因虚度年华而悔恨,也不因碌碌无为而羞愧,这样,当他老的时候,可以很...

11.5k 声望
1.9k 粉丝
宣传栏