本文為您介紹 Apache RocketMQ 的消息發(fā)送重試機(jī)制和消息流控機(jī)制。

背景信息?

消息發(fā)送重試

Apache RocketM Q的消息發(fā)送重試機(jī)制主要為您解答如下問題：

• 部分節(jié)點(diǎn)異常是否影響消息發(fā)送？

• 請求重試是否會(huì)阻塞業(yè)務(wù)調(diào)用？

• 請求重試會(huì)帶來什么不足？

消息流控

Apache RocketMQ 的流控機(jī)制主要為您解答如下問題：

• 系統(tǒng)在什么情況下會(huì)觸發(fā)流控？

• 觸發(fā)流控時(shí)客戶端行為是什么？

• 應(yīng)該如何避免觸發(fā)流控，以及如何應(yīng)對突發(fā)流控？

消息發(fā)送重試機(jī)制

重試基本概念?

Apache RocketMQ 客戶端連接服務(wù)端發(fā)起消息發(fā)送請求時(shí)，可能會(huì)因?yàn)榫W(wǎng)絡(luò)故障、服務(wù)異常等原因?qū)е抡{(diào)用失敗。為保證消息的可靠性， Apache RocketMQ 在客戶端SDK中內(nèi)置請求重試邏輯，嘗試通過重試發(fā)送達(dá)到最終調(diào)用成功的效果。同步發(fā)送和異步發(fā)送模式均支持消息發(fā)送重試。

重試觸發(fā)條件

觸發(fā)消息發(fā)送重試機(jī)制的條件如下：

• 客戶端消息發(fā)送請求調(diào)用失敗或請求超時(shí)

• 網(wǎng)絡(luò)異常造成連接失敗或請求超時(shí)。

• 服務(wù)端節(jié)點(diǎn)處于重啟或下線等狀態(tài)造成連接失敗。

• 服務(wù)端運(yùn)行慢造成請求超時(shí)。

• 服務(wù)端返回失敗錯(cuò)誤碼

  • 系統(tǒng)邏輯錯(cuò)誤：因運(yùn)行邏輯不正確造成的錯(cuò)誤。

  • 系統(tǒng)流控錯(cuò)誤：因容量超限造成的流控錯(cuò)誤。

  • 對于事務(wù)消息，只會(huì)進(jìn)行透明重試（transparent retries），網(wǎng)絡(luò)超時(shí)或異常等場景不會(huì)進(jìn)行重試。

重試流程?

生產(chǎn)者在初始化時(shí)設(shè)置消息發(fā)送最大重試次數(shù)，當(dāng)出現(xiàn)上述觸發(fā)條件的場景時(shí)，生產(chǎn)者客戶端會(huì)按照設(shè)置的重試次數(shù)一直重試發(fā)送消息，直到消息發(fā)送成功或達(dá)到最大重試次數(shù)重試結(jié)束，并在最后一次重試失敗后返回調(diào)用錯(cuò)誤響應(yīng)。

• 同步發(fā)送：調(diào)用線程會(huì)一直阻塞，直到某次重試成功或最終重試失敗，拋出錯(cuò)誤碼和異常。

• 異步發(fā)送：調(diào)用線程不會(huì)阻塞，但調(diào)用結(jié)果會(huì)通過異常事件或者成功事件返回。

重試間隔?

• 除服務(wù)端返回系統(tǒng)流控錯(cuò)誤場景，其他觸發(fā)條件觸發(fā)重試后，均會(huì)立即進(jìn)行重試，無等待間隔。

• 若由于服務(wù)端返回流控錯(cuò)誤觸發(fā)重試，系統(tǒng)會(huì)按照指數(shù)退避策略進(jìn)行延遲重試。指數(shù)退避算法通過以下參數(shù)控制重試行為：

  • INITIAL_BACKOFF： 第一次失敗重試前后需等待多久，默認(rèn)值：1秒。

  • MULTIPLIER ：指數(shù)退避因子，即退避倍率，默認(rèn)值：1.6。

  • JITTER ：隨機(jī)抖動(dòng)因子，默認(rèn)值：0.2。

  • MAX_BACKOFF ：等待間隔時(shí)間上限，默認(rèn)值：120秒

  • MIN_CONNECT_TIMEOUT ：最短重試間隔，默認(rèn)值：20秒。

  • 建議算法如下：

  • ConnectWithBackoff()
      current_backoff = INITIAL_BACKOFF
      current_deadline = now() + INITIAL_BACKOFF
      while (TryConnect(Max(current_deadline, now() + MIN_CONNECT_TIMEOUT))!= SUCCESS)
        SleepUntil(current_deadline)
        current_backoff = Min(current_backoff * MULTIPLIER, MAX_BACKOFF)
        current_deadline = now() + current_backoff + UniformRandom(-JITTER * current_backoff, JITTER * current_backoff)

    更多信息，請參見connection-backoff 策略。

功能約束?

• 鏈路耗時(shí)阻塞評估：從上述重試機(jī)制可以看出，在重試流程中生產(chǎn)者僅能控制最大重試次數(shù)。若由于系統(tǒng)異常觸發(fā)了SDK內(nèi)置的重試邏輯，則服務(wù)端需要等待最終重試結(jié)果，可能會(huì)導(dǎo)致消息發(fā)送請求鏈路被阻塞。對于某些實(shí)時(shí)調(diào)用類場景，您需要合理評估每次調(diào)用請求的超時(shí)時(shí)間以及最大重試次數(shù)，避免影響全鏈路的耗時(shí)。

• 最終異常兜底： Apache RocketMQ 客戶端內(nèi)置的發(fā)送請求重試機(jī)制并不能保證消息發(fā)送一定成功。當(dāng)最終重試仍然失敗時(shí)，業(yè)務(wù)方調(diào)用需要捕獲異常，并做好冗余保護(hù)處理，避免消息發(fā)送結(jié)果不一致。

• 消息重復(fù)問題：因遠(yuǎn)程調(diào)用的不確定性，當(dāng)Apache RocketMQ客戶端因請求超時(shí)觸發(fā)消息發(fā)送重試流程，此時(shí)客戶端無法感知服務(wù)端的處理結(jié)果，客戶端進(jìn)行的消息發(fā)送重試可能會(huì)產(chǎn)生消息重復(fù)問題，業(yè)務(wù)邏輯需要自行處理消息重復(fù)問題。

消息流控機(jī)制?

消息流控基本概念?

消息流控指的是系統(tǒng)容量或水位過高， Apache RocketMQ 服務(wù)端會(huì)通過快速失敗返回流控錯(cuò)誤來避免底層資源承受過高壓力。

觸發(fā)條件?

Apache RocketMQ 的消息流控觸發(fā)條件如下：

• 存儲(chǔ)壓力大：參考消費(fèi)進(jìn)度管理的原理機(jī)制，消費(fèi)者分組的初始消費(fèi)位點(diǎn)為當(dāng)前隊(duì)列的最大消費(fèi)位點(diǎn)。若某些場景例如業(yè)務(wù)上新等需要回溯到指定時(shí)刻前開始消費(fèi)，此時(shí)隊(duì)列的存儲(chǔ)壓力會(huì)瞬間飆升，觸發(fā)消息流控。

• 服務(wù)端請求任務(wù)排隊(duì)溢出：若消費(fèi)者消費(fèi)能力不足，導(dǎo)致隊(duì)列中有大量堆積消息，當(dāng)堆積消息超過一定數(shù)量后會(huì)觸發(fā)消息流控，減少下游消費(fèi)系統(tǒng)壓力。

流控行為?

當(dāng)系統(tǒng)觸發(fā)消息發(fā)送流控時(shí)，客戶端會(huì)收到系統(tǒng)限流錯(cuò)誤和異常，錯(cuò)誤碼信息如下：

• reply-code：530

• reply-text：TOO_MANY_REQUESTS

客戶端收到系統(tǒng)流控錯(cuò)誤碼后，會(huì)根據(jù)指數(shù)退避策略進(jìn)行消息發(fā)送重試。

處理建議?

• 如何避免觸發(fā)消息流控：觸發(fā)限流的根本原因是系統(tǒng)容量或水位過高，您可以利用可觀測性功能監(jiān)控系統(tǒng)水位容量等，保證底層資源充足，避免觸發(fā)流控機(jī)制。

• 突發(fā)消息流控處理：如果因?yàn)橥话l(fā)原因觸發(fā)消息流控，且客戶端內(nèi)置的重試流程執(zhí)行失敗，則建議業(yè)務(wù)方將請求調(diào)用臨時(shí)替換到其他系統(tǒng)進(jìn)行應(yīng)急處理。文章來源地址http://www.zghlxwxcb.cn/news/detail-608898.html

到了這里，關(guān)于RocketMQ教程-(5)-功能特性-消息發(fā)送重試和流控機(jī)制的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！