于是,又经过了大量详细周密的考察和研究,终于找到了问题并且解决了。
网站建设公司,为您提供网站建设,网站制作,网页设计及定制网站建设服务,专注于成都定制网页设计,高端网页制作,对纯水机等多个行业拥有丰富的网站建设经验的网站建设公司。专业网站设计,网站优化推广哪家好,专业网站推广优化,H5建站,响应式网站。
为啥服务都下线了还会有那么多的请求一直进来呢?
呐,我们都知道 Eureka 是 AP 模型,其实根本原因在于 Eureka 使用了三级缓存来保存服务的实例信息。
如下图所示:
我们的服务注册的时候会和 server 保持一个心跳,这个心跳的时间是 30 秒,服务注册之后,客户端的实例信息保存到 Registry 服务注册表当中,注册表中的信息会立刻同步到 readWriteCacheMap 之中。
而客户端如果感知到这个服务,要从 readOnlyCacheMap 去读取,这个只读缓存需要 30 秒的时间去从 readWriteCacheMap 中同步。
客户端和 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 秒。
当前名称:一次 Eureka 服务下线太慢的惨痛经历!
URL网址:http://www.csdahua.cn/qtweb/news44/280144.html
网站建设、网络推广公司-快上网,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 快上网