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的确在高并发场景很实用，但是使用不当也会带来一定隐患
居然感觉和瑞哥一起奋战的夜晚时间很幸福的事情！
网友评论