博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
警报:线上事故之CountDownLatch的威力
阅读量:5823 次
发布时间:2019-06-18

本文共 1181 字,大约阅读时间需要 3 分钟。

2019.2.22号凌晨3点半,是一个让人难以忘怀的、和瑞哥最后一次一起奋战的夜晚。

背景

我们有这样一个业务场景:用户提供各种数据源配置信息,然后基于数据源配置的模板,再者在模板基础上构建报表,而大数据计算平台则会根据这些信息生成数据计算任务,以实时、离线、混合的方式跑数,并将计算结果落到存储设备中。

线上事故

应用每天凌晨1点10分进行自清理重启后,会进行数据源连接池的初始化操作。而报表跑数也只能在数据源是连通的状态下正常进行,所以,这里我们就借助于CountDownLatch进行了数据源连接池初始化等待操作。

正常情况下,不论是Hive集群、DRUID集群还是MySQL等数据源都没出现问题。然后,事不绝对,海外的Hive集群的HS2却莫名其妙的不健康了(端口和服务监听仍在,但是就是不做任何feedback),然而Hive连接是没有超时配置,和MySQL等不同,所以导致CountDownLatch计数器一直Waiting在最后一个数据源连接池初始化上,进而无法继续后续作业(因为数据源不完整,跑数便无意义),导致任务管理器、任务解析器以及后续的各个组件无法启动工作,最终还是我们的监控人员发现了该状况(任务量不正常、集群负载不正常、任务并发数不正常),紧急通知我们,经过排查发现是因为海外的Hive数据源连接池初始化无响应造成阻塞,影响任务运行,此时如果再大费周章联系对方集群负责人,估计受影响任务量会更大,白天根本追加不回来,会严重影响数据KPI,苦逼些可能忙碌一年,到年底没了年终奖,岂不扯皮。所以,当机立断,禁用了海外Hive数据源,应用正常启动运行,然后就是追补数据的工作,还好抢救及时,今天白天任务正常完成。

事后反思

CountDownLatch就是这么强大,你只要不调用CountDownLatch#countDown(),那我就敢等到地老天荒。但是,使用CountDownLatch的人也有责任,太过于相信集群的健康程度以及监控,即使知道Hive连接没有超时限制,却没有通过代码把控最大连接超时时间,如果指定时间内没有返回,就直接调用一次countDown()即可。可能你会说,那如果刚好那个时间点出现了网络延迟,导致连接请求一直没返回呢?你这样岂不是就无法初始化该数据源连接池了?这也简单,我们可以通过重试机制来处理,比如重试3次连接请求,如果均不可行,就直接调用countDown方法返回即可,这样就不会影响其他业务了。当然,后续也可以针对不同数据源进行相应隔离初始化,这样也只有使用该数据源的报表会受影响。

总结

  • 不要过分相信监控指标等信息
  • 针对长耗时的业务,一定要做超时限制,不可无所谓的放任
  • CountDownLatch的确在高并发场景很实用,但是使用不当也会带来一定隐患
居然感觉和瑞哥一起奋战的夜晚时间很幸福的事情!

转载地址:http://lhbdx.baihongyu.com/

你可能感兴趣的文章
ios xmpp demo
查看>>
python matplotlib 中文显示参数设置
查看>>
【ros】Create a ROS package:package dependencies报错
查看>>
通过容器编排和服务网格来改进Java微服务的可测性
查看>>
re:Invent解读:没想到你是这样的AWS
查看>>
PyTips 0x02 - Python 中的函数式编程
查看>>
阿里云安全肖力:安全基础建设是企业数字化转型的基石 ...
查看>>
使用《Deep Image Prior》来做图像复原
查看>>
Linux基础命令---rmdir
查看>>
Android图片添加水印图片并把图片保存到文件存储
查看>>
BigDecimal 舍入模式(Rounding mode)介绍
查看>>
开源 免费 java CMS - FreeCMS1.2-标签 infoSign
查看>>
开源 免费 java CMS - FreeCMS1.9 移动APP生成栏目列表数据
查看>>
Squid 反向代理服务器配置
查看>>
Java I/O操作
查看>>
Tomcat性能调优
查看>>
Android自学--一篇文章基本掌握所有的常用View组件
查看>>
灰度图像和彩色图像
查看>>
通过vb.net 和NPOI实现对excel的读操作
查看>>
TCP segmentation offload
查看>>