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