摘要:號凌晨點半,是一個讓人難以忘懷的和瑞哥最后一次一起奮戰(zhàn)的夜晚??偨Y不要過分相信監(jiān)控指標等信息針對長耗時的業(yè)務,一定要做超時限制,不可無所謂的放任的確在高并發(fā)場景很實用,但是使用不當也會帶來一定隱患居然感覺和瑞哥一起奮戰(zhàn)的夜晚時間很幸福的事情
2019.2.22號凌晨3點半,是一個讓人難以忘懷的、和瑞哥最后一次一起奮戰(zhàn)的夜晚。背景
我們有這樣一個業(yè)務場景:用戶提供各種數(shù)據(jù)源配置信息,然后基于數(shù)據(jù)源配置的模板,再者在模板基礎上構建報表,而大數(shù)據(jù)計算平臺則會根據(jù)這些信息生成數(shù)據(jù)計算任務,以實時、離線、混合的方式跑數(shù),并將計算結果落到存儲設備中。
線上事故應用每天凌晨1點10分進行自清理重啟后,會進行數(shù)據(jù)源連接池的初始化操作。而報表跑數(shù)也只能在數(shù)據(jù)源是連通的狀態(tài)下正常進行,所以,這里我們就借助于CountDownLatch進行了數(shù)據(jù)源連接池初始化等待操作。
正常情況下,不論是Hive集群、DRUID集群還是MySQL等數(shù)據(jù)源都沒出現(xiàn)問題。然后,事不絕對,海外的Hive集群的HS2卻莫名其妙的不健康了(端口和服務監(jiān)聽仍在,但是就是不做任何feedback),然而Hive連接是沒有超時配置,和MySQL等不同,所以導致CountDownLatch計數(shù)器一直Waiting在最后一個數(shù)據(jù)源連接池初始化上,進而無法繼續(xù)后續(xù)作業(yè)(因為數(shù)據(jù)源不完整,跑數(shù)便無意義),導致任務管理器、任務解析器以及后續(xù)的各個組件無法啟動工作,最終還是我們的監(jiān)控人員發(fā)現(xiàn)了該狀況(任務量不正常、集群負載不正常、任務并發(fā)數(shù)不正常),緊急通知我們,經(jīng)過排查發(fā)現(xiàn)是因為海外的Hive數(shù)據(jù)源連接池初始化無響應造成阻塞,影響任務運行,此時如果再大費周章聯(lián)系對方集群負責人,估計受影響任務量會更大,白天根本追加不回來,會嚴重影響數(shù)據(jù)KPI,苦逼些可能忙碌一年,到年底沒了年終獎,豈不扯皮。所以,當機立斷,禁用了海外Hive數(shù)據(jù)源,應用正常啟動運行,然后就是追補數(shù)據(jù)的工作,還好搶救及時,今天白天任務正常完成。
CountDownLatch就是這么強大,你只要不調(diào)用CountDownLatch#countDown(),那我就敢等到地老天荒。但是,使用CountDownLatch的人也有責任,太過于相信集群的健康程度以及監(jiān)控,即使知道Hive連接沒有超時限制,卻沒有通過代碼把控最大連接超時時間,如果指定時間內(nèi)沒有返回,就直接調(diào)用一次countDown()即可??赡苣銜f,那如果剛好那個時間點出現(xiàn)了網(wǎng)絡延遲,導致連接請求一直沒返回呢?你這樣豈不是就無法初始化該數(shù)據(jù)源連接池了?這也簡單,我們可以通過重試機制來處理,比如重試3次連接請求,如果均不可行,就直接調(diào)用countDown方法返回即可,這樣就不會影響其他業(yè)務了。當然,后續(xù)也可以針對不同數(shù)據(jù)源進行相應隔離初始化,這樣也只有使用該數(shù)據(jù)源的報表會受影響。
總結不要過分相信監(jiān)控指標等信息
針對長耗時的業(yè)務,一定要做超時限制,不可無所謂的放任
CountDownLatch的確在高并發(fā)場景很實用,但是使用不當也會帶來一定隱患
居然感覺和瑞哥一起奮戰(zhàn)的夜晚時間很幸福的事情!
文章版權歸作者所有,未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://www.ezyhdfw.cn/yun/73372.html
摘要:設置三個功能鍵,緊急報警功能鍵,人為報警和取消報警,即手動報警。如果識別出火災事故,警報系統(tǒng)將在微控制器設計的指導下啟動警報,以警告發(fā)生火災事故。 1.1課題研究背...
摘要:最近安全事故瀕發(fā)啊,前幾天發(fā)生了順豐高級運維工程師的刪庫事件,今天又看到了工程師在線執(zhí)行了危險命令導致某公司損失萬。。該公司表示,如再犯類似事故,將直接開除,并表示之后會逐步收回運維部各項權限。 最近安全事故瀕發(fā)啊,前幾天發(fā)生了《順豐高級運維工程師的刪庫事件》,今天又看到了 PHP 工程師在線執(zhí)行了 Redis 危險命令導致某公司損失 400 萬。。 什么樣的 Redis 命令會有如此...
摘要:作者在領域,谷歌應該是典范之一,特別是在自動化測試領域。谷歌有一個長期傳統(tǒng),所有的新服務需要開發(fā)人員自行管理至少六個月。 【編者按】本文是 Gene Kim 總結自對 Randy Shoup 兩個小時的采訪,主要關注谷歌 DevOps 的提升之道。本文系 OneAPM 聯(lián)合高效運維編譯整理。 Randy Shoup 曾協(xié)助領導 eBay 和 Google 的工程師團隊,他是筆者見過少數(shù)...
摘要:摘要徒手寫錯誤監(jiān)控。為什么用定時器呢,因為在單頁應用中,路由的切換和地址欄的變化是無法被監(jiān)控的,我確實沒有想到特別好的辦法來監(jiān)控,所以用了這種方式,如果有人有更好的辦法,請給我留言,謝謝。 摘要: 徒手寫JS錯誤監(jiān)控。 作者:一步一個腳印一個坑 原文:搭建前端監(jiān)控系統(tǒng)(二)JS錯誤監(jiān)控篇 Fundebug經(jīng)授權轉載,版權歸原作者所有。 背景:市面上的監(jiān)控系統(tǒng)有很多,大多收費,對于...
閱讀 2715·2021-09-01 10:41
閱讀 1546·2019-08-30 14:12
閱讀 619·2019-08-29 12:32
閱讀 2935·2019-08-29 12:25
閱讀 3025·2019-08-28 18:30
閱讀 1784·2019-08-26 11:47
閱讀 1147·2019-08-26 10:35
閱讀 2698·2019-08-23 18:06