www.久久久久|狼友网站av天堂|精品国产无码a片|一级av色欲av|91在线播放视频|亚洲无码主播在线|国产精品草久在线|明星AV网站在线|污污内射久久一区|婷婷综合视频网站

當前位置:首頁 > 公眾號精選 > 架構(gòu)師社區(qū)
[導讀]1、問題現(xiàn)象 首先接到項目反饋使用 RocketMQ 會出現(xiàn)如下錯誤: 錯誤信息關鍵點:MQBrokerException:CODE:2 DESC:[TIMEOUT_CLEAN_QUEUE]broker busy,start flow control for a while,period in queue:205ms,size of queue:880。 由于項目組并沒有對消息發(fā)送

RocketMQ 一行代碼造成大量消息丟失

1、問題現(xiàn)象


首先接到項目反饋使用 RocketMQ 會出現(xiàn)如下錯誤:

RocketMQ 一行代碼造成大量消息丟失

錯誤信息關鍵點:MQBrokerException:CODE:2 DESC:[TIMEOUT_CLEAN_QUEUE]broker busy,start flow control for a while,period in queue:205ms,size of queue:880。

由于項目組并沒有對消息發(fā)送失敗做任何補償,導致丟失消息發(fā)送失敗,故需要對這個問題進行深層次的探討,并加以解決。

2、問題分析


首先我們根據(jù)關鍵字:TIMEOUT_CLEAN_QUEUE 去 RocketMQ 中查詢,去探究在什么時候會拋出如上錯誤。根據(jù)全文搜索如下圖所示:

RocketMQ 一行代碼造成大量消息丟失

該方法是在 BrokerFastFailure 中定義的,通過名稱即可以看成其設計目的:Broker端快速失敗機制。

Broker 端快速失敗其原理圖如下:

RocketMQ 一行代碼造成大量消息丟失
  • 消息發(fā)送者向 Broker 發(fā)送消息寫入請求,Broker 端在接收到請求后會首先放入一個隊列中(SendThreadPoolQueue),默認容量為 10000。

  • Broker 會專門使用一個線程池(SendMessageExecutor)去從隊列中獲取任務并執(zhí)行消息寫入請求,為了保證消息的順序處理,該線程池默認線程個數(shù)為1。

如果 Broker 端受到垃圾回收等等因素造成單條寫入數(shù)據(jù)發(fā)生抖動,單個 Broker 端積壓的請求太多從而得不到及時處理,會極大的造成客戶端消息發(fā)送的時間延長。

設想一下,如果由于 Broker 壓力增大,寫入一條消息需要500ms甚至超過1s,并且隊列中積壓了5000條消息,消息發(fā)送端的默認超時時間為3s,如果按照這樣的速度,這些請求在輪到 Broker 執(zhí)行寫入請求時,客戶端已經(jīng)將這個請求超時了,這樣不僅會造成大量的無效處理,還會導致客戶端發(fā)送超時。

故 RocketMQ 為了解決該問題,引入 Broker 端快速失敗機制,即開啟一個定時調(diào)度線程,每隔10毫秒去檢查隊列中的第一個排隊節(jié)點,如果該節(jié)點的排隊時間已經(jīng)超過了 200ms,就會取消該隊列中所有已超過 200ms 的請求,立即向客戶端返回失敗,這樣客戶端能盡快進行重試,因為 Broker 都是集群部署,下次重試可以發(fā)送到其他 Broker 上,這樣能最大程度保證消息發(fā)送在默認 3s 的時間內(nèi)經(jīng)過重試機制,能有效避免某一臺 Broker 由于瞬時壓力大而造成的消息發(fā)送不可用,從而實現(xiàn)消息發(fā)送的高可用。

從 Broker 端快速失敗機制引入的初衷來看,快速失敗后會發(fā)起重試,除非同一時刻集群內(nèi)所有的 Broker 都繁忙,不然消息會發(fā)送成功,用戶是不會感知這個錯誤的,那為什么用戶感知了呢?難道 TIMEOUT_ CLEAN _ QUEUE 錯誤,Broker 不重試?

為了解開這個謎團,接下來會采用源碼分析的手段去探究真相。接下來將以消息同步發(fā)送為例揭示其消息發(fā)送處理流程中的核心關鍵點。

MQ Client 消息發(fā)送端首先會利用網(wǎng)絡通道將請求發(fā)送到 Broker,然后接收到請求結(jié)果后并調(diào)用 processSendResponse 方法對響應結(jié)果進行解析,如下圖所示:

RocketMQ 一行代碼造成大量消息丟失
在這里返回的 code 為 RemotingSysResponseCode . SYSTEM_BUSY。

我們從 proccessSendResponse 方法中可以得知如果 code 為 SYSTEM_BUSY,該方法會拋出 MQBrokerException,響應 code 為 SYSTEM_BUSY,其錯誤描述為開頭部分的錯誤信息。

那我們沿著該方法的調(diào)用鏈路,可以找到其直接調(diào)用方:DefaultMQProducerImpl 的 sendKernelImpl,我們重點考慮如果底層方法拋出  MQBrokerException 該方法會如何處理。

其關鍵代碼如下圖所示:

RocketMQ 一行代碼造成大量消息丟失
可以看出在 sendKernelImpl 方法中首先會捕捉異常,先執(zhí)行注冊的鉤子函數(shù),即就算執(zhí)行失敗,對應的消息發(fā)送后置鉤子函數(shù)也會執(zhí)行,然后再原封不動的將該異常向上拋出。

sendKernelImpl 方法被 DefaultMQProducerImpl 的 sendDefaultImpl 方法調(diào)用,下面是其核心實現(xiàn)截圖:

RocketMQ 一行代碼造成大量消息丟失
從這里可以看出 RocketMQ 消息發(fā)送高可用設計一個非常關鍵的點,重試機制,其實現(xiàn)是在 for 循環(huán)中 使用 try catch 將 sendKernelImpl 方法包裹,就可以保證該方法拋出異常后能繼續(xù)重試。從上文可知,如果 SYSTEM_BUSY 會拋出 MQBrokerException,但發(fā)現(xiàn)只有上述幾個錯誤碼才會重試,因為如果不是上述錯誤碼,會繼續(xù)向外拋出異常,此時 for 循環(huán)會被中斷,即不會重試。

這里非常令人意外的是連 SYSTEM_ERROR 都會重試,卻沒有包含 SYSTEM_BUSY,顯然違背了快速失敗的設計初衷,故筆者斷定,這是 RocketMQ 的一個BUG,將 SYSTEM_BUSY 遺漏了,后續(xù)會提一個 PR,增加一行代碼,將 SYSTEM_BUSY 加上即可。

問題分析到這里,該問題應該就非常明了。

3、解決方案


如果大家在網(wǎng)上搜索 TIMEOUT_CLEAN_QUEUE 的解決方法,大家不約而同提出的解決方案是增加 waitTimeMillsInSendQueue 的值,該值默認為 200ms,例如將其設置為 1000s 等等,以前我是反對的,因為我的認知里 Broker 會重試,但現(xiàn)在發(fā)現(xiàn) Broker 不會重試,所以我現(xiàn)在認為該 BUG未解決的情況下適當提高該值能有效的緩解。

但這是并不是好的解決方案,我會在近期向官方提交一個PR,將這個問題修復,建議大家在公司盡量對自己使用的版本進行修改,重新打一個包即可,因為這已經(jīng)違背了 Broker 端快速失敗的設計初衷。

但在消息發(fā)送的業(yè)務方,盡量自己實現(xiàn)消息的重試機制,即不依賴 RocketMQ 本身提供的重試機制,因為受制于網(wǎng)絡等因素,消息發(fā)送不可能百分之百成功,建議大家在消息發(fā)送時捕獲一下異常,如果發(fā)送失敗,可以將消息存入數(shù)據(jù)庫,再結(jié)合定時任務對消息進行重試,盡最大程度保證消息不丟失。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關注的小伙伴,可以長按關注一下:

RocketMQ 一行代碼造成大量消息丟失

長按訂閱更多精彩▼

RocketMQ 一行代碼造成大量消息丟失

如有收獲,點個在看,誠摯感謝

免責聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

ckquote>
本站聲明: 本文章由作者或相關機構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫毥谦F公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務中斷的風險,如企業(yè)系統(tǒng)復雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務連續(xù)性,提升韌性,成...

關鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關鍵字: 華為 12nm EDA 半導體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務引領增長 以科技創(chuàng)新為引領,提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強核心競爭優(yōu)勢...

關鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術學會聯(lián)合牽頭組建的NVI技術創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術創(chuàng)新聯(lián)...

關鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關鍵字: BSP 信息技術
關閉
關閉