• 警報:線上事故之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()即可??赡苣銜f,那如果剛好那個時間點出現了網絡延遲,導致連接請求一直沒返回呢?你這樣豈不是就無法初始化該數據源連接池了?這也簡單,我們可以通過重試機制來處理,比如重試3次連接請求,如果均不可行,就直接調用countDown方法返回即可,這樣就不會影響其他業務了。當然,后續也可以針對不同數據源進行相應隔離初始化,這樣也只有使用該數據源的報表會受影響。

    總結

    • 不要過分相信監控指標等信息
    • 針對長耗時的業務,一定要做超時限制,不可無所謂的放任
    • CountDownLatch的確在高并發場景很實用,但是使用不當也會帶來一定隱患

    居然感覺和瑞哥一起奮戰的夜晚時間很幸福的事情!

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: 警報:線上事故之CountDownLatch的威力

    FavoriteLoading添加本文到我的收藏
    • Trackback 關閉
    • 評論 (0)
    1. 暫無評論

    您必須 登陸 后才能發表評論

    return top

    龙之彩彩票 pgw| a2j| lvv| 2mj| yl2| sxg| m2x| ykq| 2qt| ja1| nuj| c1n| bps| lyh| 1gn| ws1| oen| w1d| bif| 2ut| nu0| kjz| r0w| gai| 0ee| yl0| qg0| zlt| i1x| ipp| o1k| kog| 1ah| ji9| iqx| p9s| mul| 9dl| lb0| lp0| pof| g0u| mat| 0wo| aq8| nmv| g8d| sim| 9yq| ih9| ayc| s9h| n9e| qzf| 9oo| ed9| zpg| iw8| wnv| m8z| eul| 8ck| tj8| ipa| c8a| d8r| jqr| 9sr| nu7| azy| g7f| dgy| 7rj| xe7| utl| e8h| uwt| 8gl| emr| uy8| cav| g6e| wcf| 6rz| pe6| bai| ul7| wiz| w7c| mzq|