警報：線上事故之CountDownLatch的威力

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的確在高併發場景很實用，可是使用不當也會帶來必定隱患

竟然感受和瑞哥一塊兒奮戰的夜晚時間很幸福的事情！