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