Eureka服务下线太慢,电话被告警打爆了

某年某月的某一天,就像一张破碎的脸。。。

错了,重来。

某天,忽然发现大量的告警,经过多番调查研究考察(此处省略3000字),发现是由于 Eureka 服务下线太慢,而仍然有大量的请求打进来导致的报错。

于是,又经过了大量详细周密的考察和研究,终于找到了问题并且解决了(此处省略5000字)。

全文完。

... ...

好了,那是不可能的啦,怎么说也要意思一下写个300字凑个原创啊。

为啥服务都下线了还会有那么多的请求一直进来呢?

呐,我们都知道 Eureka 是 AP 模型,其实根本原因在于 Eureka 使用了三级缓存来保存服务的实例信息,如下图所示。

我们的服务注册的时候会和 server 保持一个心跳,这个心跳的时间是 30 秒,服务注册之后,客户端的实例信息保存到 Registry 服务注册表当中,注册表中的信息会立刻同步到 readWriteCacheMap 之中。

而客户端如果感知到这个服务,要从 readOnlyCacheMap 去读取,这个只读缓存需要 30 秒的时间去从 readWriteCacheMap 中同步。

客户端和 Ribbon 负载均衡 都保持一个本地缓存,都是 30 秒定时同步。

按照上面所说,我们来计算一下客户端感知到一个服务下线极端的情况需要多久。

  1. 客户端每隔 30 秒会发送心跳到服务端
  2. registry 保存了所有服务注册的实例信息,他会和 readWriteCacheMap 保持一个实时的同步,而 readWriteCacheMap 和 readOnlyCacheMap 会每隔 30 秒同步一次。
  3. 客户端每隔 30 秒去同步一次 readOnlyCacheMap 的注册实例信息
  4. 考虑到如果使用 ribbon 做负载均衡的话,他还有一层缓存每隔 30 秒同步一次

如果说一个服务的正常下线,极端的情况这个时间应该就是 30+30+30+30 差不多 120 秒的时间了。

如果服务非正常下线,还需要靠每 60 秒执行一次的清理线程去剔除超过 90 秒没有心跳的服务,那么这里的极端情况可能需要 3 次 60秒才能检测出来,就是 180 秒的时间。

累计可能最长的感知时间就是:180 + 120 = 300 秒,5分钟的时间,这个时间属实有点夸张了,如果考虑到可能有些中间件画蛇添足加了点啥清理的工作,这个时间简直就是灾难性的。

那有人就问了,我在 Eureka 控制台看见服务上下线非常快啊,你这不跟我扯犊子吗?

大哥啊,控制台的显示是直接获取的 Registry 的信息,那肯定快啊,所以我们不能这样来判断。

那怎么解决呢,解决方案当然就是改这些时间了,这个时间需要根据实际生产的情况来判断修改,这里仅提供一个示例。

修改 ribbon 同步缓存的时间为 3 秒:ribbon.ServerListRefreshInterval = 3000

修改客户端同步缓存时间为 3 秒 :eureka.client.registry-fetch-interval-seconds = 3

心跳间隔时间修改为 3 秒:eureka.instance.lease-renewal-interval-in-seconds = 3

超时剔除的时间改为 9 秒:eureka.instance.lease-expiration-duration-in-seconds = 9

清理线程定时时间改为 5 秒执行一次:eureka.server.eviction-interval-timer-in-ms = 5000

同步到只读缓存的时间修改为 3 秒一次:eureka.server.response-cache-update-interval-ms = 3000

需要注意的是这里的只读缓存其实是可以关闭的,通过修改参数eureka.server.use-read-only-response-cache = false可以做到,

但是建议不要没有太大必要不要这样做,Eureka 本身就是 AP 模型,用它你就应该有这个觉悟了,另外这个配置只针对原生的 Eureka 生效,SpringCloud Eureka 是没有的,必须一定会从 readOnlyCacheMap 去读。

如果按照这个时间参数设置让我们重新计算可能感知到服务下线的最大时间:

正常下线就是 3+3+3+3=12 秒,非正常下线再加 15 秒为 27 秒。

OK,今天内容就到这儿了,我是艾小仙,下期见。


192 声望
68 粉丝
0 条评论
推荐阅读
RabbitMQ、RocketMQ、Kafka延迟队列实现
延迟队列在实际项目中有非常多的应用场景,最常见的比如订单未支付,超时取消订单,在创建订单的时候发送一条延迟消息,达到延迟时间之后消费者收到消息,如果订单没有支付的话,那么就取消订单。

艾小仙阅读 948

Java12的新特性
Java语言特性系列Java5的新特性Java6的新特性Java7的新特性Java8的新特性Java9的新特性Java10的新特性Java11的新特性Java12的新特性Java13的新特性Java14的新特性Java15的新特性Java16的新特性Java17的新特性Java...

codecraft63阅读 11.9k

Java8的新特性
Java语言特性系列Java5的新特性Java6的新特性Java7的新特性Java8的新特性Java9的新特性Java10的新特性Java11的新特性Java12的新特性Java13的新特性Java14的新特性Java15的新特性Java16的新特性Java17的新特性Java...

codecraft32阅读 24.7k评论 1

一文搞懂秒杀系统,欢迎参与开源,提交PR,提高竞争力。早日上岸,升职加薪。
前言秒杀和高并发是面试的高频考点,也是我们做电商项目必知必会的场景。欢迎大家参与我们的开源项目,提交PR,提高竞争力。早日上岸,升职加薪。知识点详解秒杀系统架构图秒杀流程图秒杀系统设计这篇文章一万多...

王中阳Go34阅读 2.6k评论 1

封面图
Java11的新特性
Java语言特性系列Java5的新特性Java6的新特性Java7的新特性Java8的新特性Java9的新特性Java10的新特性Java11的新特性Java12的新特性Java13的新特性Java14的新特性Java15的新特性Java16的新特性Java17的新特性Java...

codecraft28阅读 15.4k评论 3

Java5的新特性
Java语言特性系列Java5的新特性Java6的新特性Java7的新特性Java8的新特性Java9的新特性Java10的新特性Java11的新特性Java12的新特性Java13的新特性Java14的新特性Java15的新特性Java16的新特性Java17的新特性Java...

codecraft13阅读 20.5k

Java9的新特性
Java语言特性系列Java5的新特性Java6的新特性Java7的新特性Java8的新特性Java9的新特性Java10的新特性Java11的新特性Java12的新特性Java13的新特性Java14的新特性Java15的新特性Java16的新特性Java17的新特性Java...

codecraft20阅读 14.6k

192 声望
68 粉丝
宣传栏