MQ消息積壓如何處理
優(yōu)化性能避免消息積壓
MQ本身的處理能力是遠大于業(yè)務系統(tǒng)的處理能力的沟绪、主流消息隊列的單個節(jié)點氧吐、消息收發(fā)的性能可以達到每秒幾萬到幾十萬的水平、水平擴展Broker的實例數(shù)可以成倍的提升處理能力怀樟、應該更多的關注在消息的收發(fā)兩端功偿、讓業(yè)務代碼和MQ配合、達到最佳性能
- 發(fā)送端性能優(yōu)化
若代碼發(fā)送消息的性能較弱、很可能是發(fā)MQ之前的邏輯太耗時導致械荷、一般設置合理的并發(fā)和批量大小共耍、就可以達到很好的性能
MQ的完整交互: P -> Broker -> R
假設單線程發(fā)送、每秒處理請求 1000ms/1ms*1條/1ms = 1000 條msg吨瞎、并不能發(fā)揮MQ的實力
- 增加batch大小痹兜、2. 并發(fā)請求 都可以提升性能
對于關注延時的RPC系統(tǒng)、可以選擇增加并發(fā)量
對于關注吞吐量的離線分析系統(tǒng)颤诀、它不關心時延字旭、可以選擇批量發(fā)送
- 消費端性能優(yōu)化
若消費的速度跟不上msg生產(chǎn)的速度、MQ存儲被填滿之后就會造成無法提供服務崖叫、消息丟失遗淳、對于整個系統(tǒng)都是嚴重故障
消費端的性能優(yōu)化除了優(yōu)化消費業(yè)務邏輯之外、還可以通過簡單的水平擴容來增加消費端的并發(fā)數(shù)來提高整體的消費性能
注意
在擴容consumer實例的同時心傀、必須同步擴容主題中的分區(qū)(隊列)數(shù)量屈暗、確保consumer的實例數(shù)和分區(qū)數(shù)相等、因為每個分區(qū)只支持單線程消費
- 消息積壓了如何處理脂男？
- 若單位時間內(nèi)發(fā)送的消息增多养叛、最快的辦法就是通過擴容消費端的實例來提升總體的消費能力，或者可以通過系統(tǒng)降級宰翅、減少生產(chǎn)者發(fā)送數(shù)據(jù)
- 若是消費和生產(chǎn)速度都無明顯變化一铅、需要檢查消費端、數(shù)不勝數(shù)消費失敗導致反復消費
- 若是消費變慢堕油、可以快速排查消費日志潘飘、看看消費線程是不是卡著不動了
疑問點記錄
假如、有一個topic掉缺、Q為5卜录、Broker為2
有3個生產(chǎn)者實例、如何對應到5個Q ?
不用對應眶明、隨便發(fā)或者指定Q選取規(guī)則每個消費組都是單獨的訂閱艰毒、擁有隊列的全部消息、消費完后消息不會刪除
多個消費組訂閱同一個topic彼此不影響搜囱、
eg. 消費組G0 | G1 丑瞧、G0掛掉、積壓很多消息蜀肘、對G1也沒有任何影響消費位置
每個消費組會維護一組消費位置绊汹、每個隊列對應一個消費位置、并且消費位置和消費者無關扮宠、保存在服務端如何實現(xiàn)單個隊列的并行消費
eg. MQ中有10條消息西乖、對應的編號是0-9、當前消費位置是5、同時有5获雕、6薄腻、7三個消費者拉取消息、5届案、6庵楷、7三個消息給每個消費者一人一條、理想情況下楣颠、3個消費者成功響應尽纽、消費位置更新為8 實現(xiàn)并行消費
假如5卡著某個環(huán)節(jié)不動了、位置5就是消息空洞球碉、為了避免整個隊列卡住蜓斧、將5復制到一個重試隊列仓蛆、然后更新消費位置睁冬、消費時優(yōu)先給出重試隊列的數(shù)據(jù)
這是實現(xiàn)并行消費的一種實現(xiàn)方式、但是開銷很大看疙、不應該作為常規(guī)手段豆拨、若需要增加消費者的并發(fā)數(shù)、還是需要擴容隊列數(shù)
