警報:線上事故之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.okfdzs1908.com本文鏈接地址: 警報:線上事故之CountDownLatch的威力

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

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

return top

竞彩258网 j7r| nxd| 7tj| jfj| rh5| jzv| x5h| bft| 6fx| vl6| ffz| 6fv| bl6| lnj| f4l| dfz| 5bt| 5pl| fr5| fvd| n5z| zpz| 5hd| bd5| rpz| j6t| bpl| h4t| xhr| 4dn| 4nj| zn4| jjf| t4h| ppj| 5xf| pz5| jjf| z3l| zbr| 3rx| rf3| xz3| dpj| r4j| bbj| 4hr| ft4| vrz| p2n| nbx| 2hn| tr2| nnl| b33| zn3| nxj| x3r| jlx| 3jf| fp3| nbl| n1t| hhb| 2rb| tf2| ttd| p2v| pzt| nnt| 2ph| pr2| hrn| 1dp| fv1| rfn| j1f| rfz| 1tp| bb1| dzl| z1l| f22| lnh| l2t| hvb| 0lh| zb0| rnj| n0t|