高并发dubbo服务,每次重启后都大量超时,我懵圈了
前言
今天群里小伙伴黄晓峰咨询一个问题:"dubbo接口怎么做预热呢,每次上线,都会有一小部分超时?"。熟悉JVM都知道,JVM重启后有一段预热过程,要运行一段时间,它的性能才能达到最佳状态。阿里JVM团队就针对原生JVM这个缺陷进行了优化,其特性名曰:jwarmup,可以戳链接了解更多: Alibaba JVM创新提效 获国际社区认可登台JVM圈顶会(http://tech.gmw.cn/2017-08/26/content_25844099.htm);
另外,在JVM大神你假笨那里了解到jwarmup的大概原理:针对上次JIT对应用的优化,主动去触发JIT编译优化,而不是等jvm运行一段时间自己去感知!
阿里大厂可以这么做,我们小厂肿么办?事实上dubbo作者梁飞大神考虑到了这种情况,在dubbo中也引入了"warmup"特性(注意,虽然都叫warnup,但是dubbo的warmup和阿里JVM的jwarmup原理还是完全不一样的),核心源码在"com.alibaba.dubbo.rpc.cluster.loadbalance.AbstractLoadBalance.java"中:
protected int getWeight(Invoker<?> invoker, Invocation invocation) {// 先得到Provider的权重int weight = invoker.getUrl().getMethodParameter(invocation.getMethodName(), Constants.WEIGHT_KEY, Constants.DEFAULT_WEIGHT);if (weight > 0) {// 得到provider的启动时间戳long timestamp = invoker.getUrl().getParameter(Constants.REMOTE_TIMESTAMP_KEY, 0L);if (timestamp > 0L) {// provider已经运行时间int uptime = (int) (System.currentTimeMillis() - timestamp);// 得到warmup的值,默认为10分钟int warmup = invoker.getUrl().getParameter(Constants.WARMUP_KEY, Constants.DEFAULT_WARMUP);// provider运行时间少于预热时间,那么需要重新计算权重weight(即需要降权)if (uptime > 0 && uptime < warmup) {weight = calculateWarmupWeight(uptime, warmup, weight);}}}return weight;
}static int calculateWarmupWeight(int uptime, int warmup, int weight) {// 随着provider的启动时间越来越长,慢慢提升权重直到weightint ww = (int) ( (float) uptime / ( (float) warmup / (float) weight ) );return ww < 1 ? 1 : (ww > weight ? weight : ww);
}
warnup权重计算过程:
根据calculateWarmupWeight()方法实现可知,随着provider的启动时间越来越长,慢慢提升权重直到weight,且权重最小值为1,所以:
如果provider运行了1分钟,那么weight为10,即只有最终需要承担的10%流量;
如果provider运行了2分钟,那么weight为20,即只有最终需要承担的20%流量;
如果provider运行了5分钟,那么weight为50,即只有最终需要承担的50%流量;
... ...
这里需要注意的是,dubbo默认有3种负载均衡实现方式:随机,轮询,一致性哈希;其中一致性哈希是不受权重影响的,也就是说,如果选择一致性哈希负载均衡,就不支持dubbo的预热特性了。
问题
既然,dubbo有预热功能,为什么每次重启,还会有那么多的超时呢?后来咨询小伙伴黄晓峰VIVO,他们的dubbo是基于dubbox的自建分支,dubbox2.8.4和dubbo原生分支的代码是有一点出入的:
笔者查找Github上dubbo更新,从AbstractLoadBalance.java的提交记录发现有过一次fix,记录如下:
修改记录为如下所示:
fix来源:
https://github.com/apache/incubator-dubbo/commit/ed66afd9a38d80f839f0381fbd1dc1d3c068bc1c#diff-c5cb2df641f0a7d0553343c757425d2b
真相
真相原来如此,由于dubbox基于dubbo比较老的分支,而这个bug fix是committed on 10 Oct 2017
,所以dubbox分支的bug依然存在。我相信很多使用老版本dubbo或者dubbox的公司,都存在这个问题!
既然提到dubbo预热问题,另外一个优化点也可以参考一下(和warmup没有关系),dubbo官方称之为延迟暴露:
# 这个申明的含义是等spring容器启动后过5s再暴露dubbo服务:
<dubbo:provider delay="5000"/>
或者延迟暴露某个接口:
<dubbo:service delay="5000" interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" version="1.0.0"/>
验证日志如下--可以看到"Dubbo service server started"即dubbo服务启动后,过了5s才暴露服务:
[28/04/18 05:40:59:059 CST] main INFO support.DefaultListableBeanFactory: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@6b927fb: defining beans [dubbo-test,com.alibaba.dubbo.config.RegistryConfig,com.alibaba.dubbo.config.ProviderConfig,demoService,testService,com.alibaba.dubbo.demo.DemoService,com.alibaba.dubbo.demo.TestService]; root of factory hierarchy
[28/04/18 05:40:59:059 CST] main INFO container.Main: [DUBBO] Dubbo SpringContainer started!, dubbo version: 2.0.0, current host: 127.0.0.1
[2018-04-28 17:40:59] Dubbo service server started!
[28/04/18 05:41:04:004 CST] DelayExportServiceThread INFO config.AbstractConfig: [DUBBO] Export dubbo service com.alibaba.dubbo.demo.DemoService to local registry, dubbo version: 2.0.0, current host: 127.0.0.1
[28/04/18 05:41:04:004 CST] DelayExportServiceThread INFO config.AbstractConfig: [DUBBO] Export dubbo service com.alibaba.dubbo.demo.TestService to local registry, dubbo version: 2.0.0, current host: 127.0.0.1
总结
无论是dubbo的warmup特性还是延迟暴露服务,对生产环境都有很大的帮助,所以,赶紧做如下的优化吧:
如果是dubbox分支,或者旧的dubbo分支,请升级dubbo版本,或者merge这个PR修复warmup特性时间戳的问题;
配置
dubbo:provider delay="5000"
延迟暴露所有dubbo服务;
注意:按照dubbo参数等价转换特性,可以用-Ddubbo.provider.deplay代替,但是笔者跟踪源码发现这里有个bug并已经提交了issue,请戳【System property dubbo.service.delay invalid】,链接地址为:https://github.com/apache/incubator-dubbo/issues/1728,如果你的dubbo也存在这个问题,就老老实实用dubbo:provider delay="5000" 这种xml配置方式吧。
推荐阅读:
喜欢我可以给我设为星标哦
好文章,我 在看
高并发dubbo服务,每次重启后都大量超时,我懵圈了相关推荐
- 互联网公司高并发图片存储服务架构设计一
非常感谢http://blog.csdn.net/lizhitao/article/details/9323137 高并发图片存储服务架构技术学习 https://www.itkc8.com 互联网公 ...
- 虚拟机关机/重启后都要重装虚拟机的操作系统
问题:虚拟机关机/重启后都要重装虚拟机的操作系统,装的软件文件多不见了,非常烦人 按照网上的解决方案主要分为3类,一一尝试都无法解决 方案1:虚拟机设置--硬件--磁盘--高级里面有一个模式的设置,勾 ...
- HP LaserJet Pro 300 彩色打印机 M351a - 每次重启电脑都提示安装驱动
https://support.hp.com/cn-zh/document/c03640787 问题 本文介绍HP LaserJet Pro 300 彩色打印机 M351a ,每次重启电脑都提示安装驱 ...
- 打印机无法打印每次重启后才能访问打印文件
环境: EPSON WF-C 5790a 问题描述: 打印机搬了一个办公室,使用无线连接网络后,早上打印机正常到下午突然无法打印显示脱机,每次重启后才能访问打印 解决方案: 1.重新安装打印机驱动 2 ...
- ubuntu18.04LTS每次重启后蓝牙鼠标都要重新连接解决办法
1.把蓝牙鼠标处于可搜索状态,暂时不要连接 2.打开终端 3.开启命令输入: liuhao@liuhao-pc~$ bluetoothctl liuhao@liuhao-pc~$ list liuha ...
- 随手记录第二话 -- 高并发情况下秒杀、抢红包都有哪些实现方式?
1.何为高并发? 高并发:在短时间内涌入超量的请求 那么如果出现这几种情况,可能会导致的后果 服务宕机 商品库存,红包金额超量 2.何为高并发秒杀? 这是一个高频面试题,问题虽然简单,但是里面的细节有 ...
- 多线程高并发,docker容器启动后修改或添加端口
这种方式的优点是不会影响统一宿主机上的其他容器,缺点是管理起来显得比较乱.方法三:修改文件端口,重启docker服务---------------------### 1.停止docker(`一定`要先 ...
- 深入理解 RPC : 基于 Python 自建分布式高并发 RPC 服务
RPC(Remote Procedure Call)服务,也即远程过程调用,在互联网企业技术架构中占据了举足轻重的地位,尤其在当下微服务化逐步成为大中型分布式系统架构的主流背景下,RPC 更扮演了重要 ...
- 电商平台 高并发 微服务 方案_Java生鲜电商平台-秒杀系统微服务架构设计与源码解析实战...
Java生鲜电商平台- 什么是秒杀 通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动 比如说京东秒杀,就是一种定时定量秒杀,在规定的时间内,无论商品是否秒杀完毕,该场次的秒杀活动都会结束.这种 ...
最新文章
- Python 还能实现哪些 AI 游戏?附上代码一起来一把!
- 网速不给力,我们自己给——MinGW的手动安装与配置
- 私房库视频学习笔记-小清新BBS系统开发技术归纳
- android自定义离线地图,MapBox GL Android:已下载但未使用的自定义磁贴源的离线地图...
- 全球及中国无服务器应用程序行业应用调研与投资前景规划报告2022版
- python使用高阶函数实现_18.python高阶函数
- 计算机初级包括php吗,计算机的基本组成包括什么
- java调用 restapi 乱码_Java HttpURLConnection模拟请求Rest接口解决中文乱码问题
- 哈工大深圳计算机专业,《计算机考研择校》哈工大深圳和北航哪个好考些?
- Servlet验证码功能
- scala基础之函数和闭包
- android局部翻转动画,android 围绕中心旋转动画
- 2017-本命年总结
- 190102每日一句
- 【eclipse安装】安装包中-win32-x86_64的意思
- 应广单片机规格 应广MCU锂电池充电IC
- TimingExecutor —— 定时执行、定时任务管理软件,定时执行专家
- hzhost防asp攻击函数
- ubuntu20.04 重启黑屏 仅有左上角白色横杠闪烁
- 国自然结题规定:经费结余50%以上或将无法结题