消息堆積
[TOC]
一、消息堆積主要原因
消息堆積主要原因：
1朽寞、生產(chǎn)者的生產(chǎn)消息速度>>消費(fèi)者的處理消息速度渤涌，速度不匹配從引起的堆積；（消費(fèi)者活著但是處理慢）
2凡怎、消費(fèi)者實(shí)例IO阻塞嚴(yán)重或者掛機(jī)；（消費(fèi)者宕機(jī)等）
3赊抖、消費(fèi)者故障期間消息的堆積统倒。（堆積累加）
單從增加消費(fèi)者數(shù)是遠(yuǎn)遠(yuǎn)不夠。之所以要處理消息堆積氛雪，是為了防止消息堆積所引起MQ的異常房匆，所以在所有MQ的業(yè)務(wù)場(chǎng)景，消息如果是重要的报亩，不容丟棄時(shí)浴鸿，需要有備選方案，可以采用數(shù)據(jù)轉(zhuǎn)移弦追，增加中間緩沖技術(shù)岳链。
二、不同消息中間件面對(duì)消息堆積的能力理解
2.1 RocketMQ消息堆積
RocketMQ在介紹消息堆積能力時(shí)劲件，介紹如下：
除了異步解耦功能掸哑，消息隊(duì)列 RocketMQ 版還有擋住前端數(shù)據(jù)洪峰的重要功能左胞，以此保證后端系統(tǒng)的穩(wěn)定性。這要求消息隊(duì)列 RocketMQ 版具有一定的消息堆積能力举户。消息隊(duì)列 RocketMQ 版能支持 10 億級(jí)別的消息堆積烤宙，不會(huì)因?yàn)橄⒍逊e導(dǎo)致性能明顯下降。
---阿里云官網(wǎng) 如何處理消息堆積俭嘁？
2.2 RabbitMQ消息堆積
而RabbitMQ在介紹優(yōu)缺點(diǎn)時(shí)躺枕，消息堆積作為缺點(diǎn)之一：
RabbitMQ 對(duì)消息堆積的支持并不好，在它的設(shè)計(jì)理念里面供填，消息隊(duì)列是一個(gè)管道拐云，大量的消息積壓是一種不正常的情況，應(yīng)當(dāng)盡量去避免近她。當(dāng)大量消息積壓的時(shí)候叉瘩，會(huì)導(dǎo)致 RabbitMQ 的性能急劇下降
延伸一：為什么說(shuō)RabbitMQ，對(duì)消息堆積的支持并不好粘捎？
2.3 從存儲(chǔ)模型來(lái)理解
關(guān)于消息隊(duì)列對(duì)于消息堆積的堆積能力薇缅，還需要從消息隊(duì)列的存儲(chǔ)模型來(lái)分析：
- 1、 RabbitMQ：內(nèi)存攒磨、磁盤都保存泳桦，消息保存到內(nèi)存中，通過(guò)鏡像隊(duì)列保證HA娩缰，通過(guò)磁盤存儲(chǔ)保證持久化灸撰。但由于內(nèi)存隊(duì)列中需要保存所有完整的
消息本地，因此當(dāng)消息堆積太多時(shí)拼坎，會(huì)使得內(nèi)存空間不可用浮毯，嚴(yán)重可能內(nèi)存溢出，服務(wù)宕機(jī)泰鸡。
? -----即 內(nèi)存债蓝、磁盤，支持少量堆積
- 2鸟顺、 RocketMQ：消息持久化保存到磁盤中惦蚊，且消費(fèi)隊(duì)列本身不保存
消息本地器虾，保存消息磁盤索引讯嫂，通過(guò)FileChannel的MMAP機(jī)制實(shí)現(xiàn)內(nèi)存映射，處理消息時(shí)能達(dá)到基本和內(nèi)存相同的效率兆沙。設(shè)置同步復(fù)制和同步刷盤即可保存消息不丟失欧芽。
? -----即 磁盤+內(nèi)存映射技術(shù)，支持大量堆積葛圃∏樱【磁盤空間還是足夠富裕的】
- 3憎妙、 Kafka：同RocketMQ。
附：RocketMQ存儲(chǔ)模型圖如下：
三曲楚、如何處理消息堆積
如何處理消息堆積呢厘唾？可以從兩個(gè)當(dāng)面考慮：
- 如何通過(guò)優(yōu)化代碼來(lái)避免消息堆積
- 消息已經(jīng)堆積了，線上如何快速處理
3.1 如何預(yù)防消息堆積
在消息的收發(fā)兩端龙誊，我們的業(yè)務(wù)代碼怎么和消息隊(duì)列配合抚垃，達(dá)到一個(gè)最佳的性能。
1趟大、發(fā)送端性能優(yōu)化
從消息堆積若干原因來(lái)看鹤树，消息堆積的原因主要在消費(fèi)端處理上，本身生產(chǎn)者端應(yīng)該遵循的原則應(yīng)該是盡可能快的將消息發(fā)送到Broker中去逊朽，因此發(fā)送端除了業(yè)務(wù)處理時(shí)批量發(fā)送暫無(wú)好的手段優(yōu)化罕伯，而且并不是所有的業(yè)務(wù)處理都支持批量發(fā)送和批量接收處理。
發(fā)送端業(yè)務(wù)代碼的處理性能叽讳，實(shí)際上和消息隊(duì)列的關(guān)系不大追他，因?yàn)橐话惆l(fā)送端都是先執(zhí)行自己的業(yè)務(wù)邏輯，最后再發(fā)送消息岛蚤。如果說(shuō)湿酸，你的代碼發(fā)送消息的性能上不去，你需要優(yōu)先檢查一下灭美，是不是發(fā)消息之前的業(yè)務(wù)邏輯耗時(shí)太多導(dǎo)致的推溃。
- 批量發(fā)送是發(fā)送端預(yù)防消息堆積的方式之一。
2届腐、消費(fèi)端性能優(yōu)化
在設(shè)計(jì)系統(tǒng)的時(shí)候铁坎，一定要保證消費(fèi)端的消費(fèi)性能要高于生產(chǎn)端的發(fā)送性能，這樣的系統(tǒng)才能健康的持續(xù)運(yùn)行犁苏。
-
方式1 增加單個(gè)消費(fèi)者處理能力
增加單個(gè)消費(fèi)者的處理能力這塊沒(méi)有絕對(duì)的辦法硬萍，只能盡可能的優(yōu)化消息處理業(yè)務(wù)邏輯的能力，減少不必要的非業(yè)務(wù)相關(guān)處理時(shí)間消耗围详；如果消息處理業(yè)務(wù)已經(jīng)優(yōu)化到無(wú)法再優(yōu)化了朴乖，那只能通過(guò)方式2水平擴(kuò)展消費(fèi)者個(gè)數(shù)來(lái)優(yōu)化。
注意：部分同學(xué)采用在業(yè)務(wù)處理OnMessage時(shí)助赞，先將消息保存到內(nèi)存隊(duì)列中买羞，再開啟線程池并發(fā)處理內(nèi)存隊(duì)列緩存消息這種方式（即通過(guò)內(nèi)存隊(duì)列增加一個(gè)異步環(huán)節(jié)）-----這種方式存在丟消息的風(fēng)險(xiǎn)，如果消費(fèi)節(jié)點(diǎn)宕機(jī)雹食，內(nèi)存隊(duì)列中的消息直接丟失畜普。慎用這種方式。
- 方式2 水平擴(kuò)容消費(fèi)者個(gè)數(shù)
消費(fèi)端的性能優(yōu)化除了優(yōu)化消費(fèi)業(yè)務(wù)邏輯以外群叶，也可以通過(guò)水平擴(kuò)容吃挑，增加消費(fèi)端的并發(fā)數(shù)來(lái)提升總體的消費(fèi)性能钝荡。
注意：水平擴(kuò)容是應(yīng)保證 擴(kuò)容后消費(fèi)者個(gè)數(shù)<=分區(qū)或者隊(duì)列個(gè)數(shù)
反過(guò)來(lái)，即如果擴(kuò)容后消費(fèi)者個(gè)數(shù)超過(guò)分區(qū)或者隊(duì)列個(gè)數(shù)后舶衬，再擴(kuò)容已經(jīng)沒(méi)有意義埠通。---因?yàn)閱蝹€(gè)消費(fèi)隊(duì)列同一時(shí)間內(nèi)只能被一個(gè)消費(fèi)者消費(fèi)，再多的消費(fèi)者也沒(méi)有用逛犹。
此時(shí)植阴，需要在Broker中同步增加分區(qū)或者隊(duì)列個(gè)數(shù)，擴(kuò)容消費(fèi)者才有意義圾浅。
補(bǔ)充：Kafka中叫分區(qū)Partition掠手，RocketMQ和RabbitMQ中叫隊(duì)列Queue
3.2 消息已經(jīng)堆積，如何快速處理
如果消息已經(jīng)堆積了狸捕，線上如何快速處理喷鸽。對(duì)于系統(tǒng)發(fā)生消息積壓的情況，需要先解決積壓灸拍，再分析原因做祝，畢竟保證系統(tǒng)的可用性是首先要解決的問(wèn)題。
快速解決積壓的方法就是通過(guò)水平擴(kuò)容增加 Consumer 的實(shí)例數(shù)量鸡岗，以及其他方式如下混槐。
- 1、消費(fèi)端擴(kuò)容轩性；--通用方式
- 2声登、服務(wù)降級(jí)；--快速失敗揣苏，不一定適用所有業(yè)務(wù)場(chǎng)景
- 3悯嗓、異常監(jiān)控。--屬于運(yùn)維層面措施
同步文章見同步博客地址
附 參考文章
1卸察、阿里云官網(wǎng) 如何處理消息堆積脯厨？
