警报：线上事故之CountDownLatch的威力

saucxs 发布于2019-08-16 15:15 / 3440人阅读

摘要：号凌晨点半，是一个让人难以忘怀的和瑞哥最后一次一起奋战的夜晚。总结不要过分相信监控指标等信息针对长耗时的业务，一定要做超时限制，不可无所谓的放任的确在高并发场景很实用，但是使用不当也会带来一定隐患居然感觉和瑞哥一起奋战的夜晚时间很幸福的事情

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的确在高并发场景很实用，但是使用不当也会带来一定隐患

居然感觉和瑞哥一起奋战的夜晚时间很幸福的事情！

GPU云服务器云服务器大数据威力的来源包括哪些 CountDownLatch 警报监控与警报

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/73372.html

基于51单片机的火灾报警器（内含源码，原理图，报告等）

摘要：设置三个功能键，紧急报警功能键，人为报警和取消报警，即手动报警。如果识别出火灾事故，警报系统将在微控制器设计的指导下启动警报，以警告发生火灾事故。 1.1课题研究背...

TZLLOG 2021-10-09 09:43 评论0 收藏0
一个致命的 Redis 命令，导致公司损失 400 万！！

摘要：最近安全事故濒发啊，前几天发生了顺丰高级运维工程师的删库事件，今天又看到了工程师在线执行了危险命令导致某公司损失万。。该公司表示，如再犯类似事故，将直接开除，并表示之后会逐步收回运维部各项权限。最近安全事故濒发啊，前几天发生了《顺丰高级运维工程师的删库事件》，今天又看到了 PHP 工程师在线执行了 Redis 危险命令导致某公司损失 400 万。。什么样的 Redis 命令会有如此...

hedge_hog 2019-08-19 11:15 评论0 收藏0
解谜谷歌 DevOps：什么特质可以打造世界级可靠系统？

摘要：作者在领域，谷歌应该是典范之一，特别是在自动化测试领域。谷歌有一个长期传统，所有的新服务需要开发人员自行管理至少六个月。【编者按】本文是 Gene Kim 总结自对 Randy Shoup 两个小时的采访，主要关注谷歌 DevOps 的提升之道。本文系 OneAPM 联合高效运维编译整理。 Randy Shoup 曾协助领导 eBay 和 Google 的工程师团队，他是笔者见过少数...

newtrek 2019-05-28 16:54 评论0 收藏0
一步一步搭建前端监控系统：JS错误监控篇

摘要：摘要徒手写错误监控。为什么用定时器呢，因为在单页应用中，路由的切换和地址栏的变化是无法被监控的，我确实没有想到特别好的办法来监控，所以用了这种方式，如果有人有更好的办法，请给我留言，谢谢。摘要：徒手写JS错误监控。作者：一步一个脚印一个坑原文：搭建前端监控系统（二）JS错误监控篇 Fundebug经授权转载，版权归原作者所有。背景：市面上的监控系统有很多，大多收费，对于...

EdwardUp 2019-08-23 18:30 评论0 收藏0