建站
咨詢
售后
建站咨詢
新聞中心
一、簡介
市場上現(xiàn)在常用的消息隊(duì)列有：RabbitMQ、RocketMQ、Kafka，ActiveMQ。
二、MQ的優(yōu)勢
(1) 解耦
使用消息MQ后，只需要保證消息格式不變，不需要關(guān)心發(fā)布者及消費(fèi)者之間的關(guān)系，這兩者不需要彼此聯(lián)系。
(2) 異步
在一些不需要即時(shí)(同步)的返回結(jié)果操作，通過消息隊(duì)列來實(shí)現(xiàn)異步。
(3) 削峰
在大量請(qǐng)求時(shí)(秒殺場景)，使用消息隊(duì)列做緩沖處理，削弱峰值流量，防止系統(tǒng)在短時(shí)間內(nèi)被峰值流量沖垮。
場景：在大量流量涌入高峰，如數(shù)據(jù)庫只能抗住2000的并發(fā)流量，可以使用MQ控制2000到數(shù)據(jù)庫中。
(4) 日志處理
日志存儲(chǔ)在消息隊(duì)列中，用來處理日志，比如kafka。
三、MQ的劣勢
- 系統(tǒng)的可用性降低
在還未引進(jìn)MQ之前，系統(tǒng)只需要關(guān)系生產(chǎn)端與消費(fèi)端的接口一致性就可以了，現(xiàn)在引進(jìn)后，系統(tǒng)需要關(guān)注生產(chǎn)端、MQ與消費(fèi)端三者的穩(wěn)定性，這增加系統(tǒng)的負(fù)擔(dān)，系統(tǒng)運(yùn)維成本增加。
- 系統(tǒng)的復(fù)雜性提高
引入了MQ，需要考慮的問題就增加了，如何保障消息的一致性，消費(fèi)不被重復(fù)消費(fèi)等問題。
- 一致性問題
A系統(tǒng)發(fā)送完消息直接返回成功，但是BCD系統(tǒng)之中若有系統(tǒng)寫庫失敗，則會(huì)產(chǎn)生數(shù)據(jù)不一致的問題。
四、常見問題
(1) 怎么保證消息沒有重復(fù)消費(fèi)?使用消息隊(duì)列如何保證冪等性
冪等性：就是用戶對(duì)于同一操作發(fā)起的一次請(qǐng)求或者多次請(qǐng)求的結(jié)果是一致的，不會(huì)因?yàn)槎啻吸c(diǎn)擊而產(chǎn)生了副作用。
問題出現(xiàn)原因
我們先來了解一下產(chǎn)生消息重復(fù)消費(fèi)的原因，對(duì)于MQ的使用，有三個(gè)角色：生產(chǎn)者、MQ、消費(fèi)者，那么消息的重復(fù)這三者會(huì)出現(xiàn)：
- 生產(chǎn)者：生產(chǎn)者可能會(huì)推送重復(fù)的數(shù)據(jù)到MQ中，有可能controller接口重復(fù)提交了兩次，也可能是重試機(jī)制導(dǎo)致的。
- MQ：假設(shè)網(wǎng)絡(luò)出現(xiàn)了波動(dòng)，消費(fèi)者消費(fèi)完一條消息后，發(fā)送ack時(shí)，MQ還沒來得及接受，突然掛了，導(dǎo)致MQ以為消費(fèi)者還未消費(fèi)該條消息，MQ回復(fù)后會(huì)再次推送了這條消息，導(dǎo)致出現(xiàn)重復(fù)消費(fèi)。
- 消費(fèi)者：消費(fèi)者接收到消息后，正準(zhǔn)備發(fā)送ack到MQ，突然消費(fèi)者掛了，還沒得及發(fā)送ack，這時(shí)MQ以為消費(fèi)者還沒消費(fèi)該消息，消費(fèi)者重啟后，MQ再次推送該條消息。
解決方案
在正常情況下，生產(chǎn)者是客戶，我們很難避免出現(xiàn)用戶重復(fù)點(diǎn)擊的情況，而MQ是允許存在多條一樣的消息，但消費(fèi)者是不允許出現(xiàn)消費(fèi)兩條一樣的數(shù)據(jù)，所以冪等性一般是在消費(fèi)端實(shí)現(xiàn)的：
狀態(tài)判斷：消費(fèi)者把消費(fèi)消息記錄到redis中，再次消費(fèi)時(shí)先到redis判斷是否存在該數(shù)據(jù)，存在則表示消費(fèi)過，直接丟棄。
業(yè)務(wù)判斷：消費(fèi)完數(shù)據(jù)后，都是需要插入到數(shù)據(jù)庫中，使用數(shù)據(jù)庫的唯一約束防止重復(fù)消費(fèi)。插入數(shù)據(jù)庫前先查詢是否存在該數(shù)據(jù)，存在則直接丟棄消息，這種方式是比較簡單粗暴地解決問題。
(2) 消息丟失的情況
(3) 消息的傳輸順序性
解決思路
在生產(chǎn)端發(fā)布消息時(shí)，每次法發(fā)布消息都把上一條消息的ID記錄到消息體中，消費(fèi)者接收到消息時(shí)，做如下操作。
- 先根據(jù)上一條Id去檢查是否存在上一條消息還沒被消費(fèi)，如果不存在(消費(fèi)后去掉id)，則正常進(jìn)行，如果正常操作。
- 如果存在，則根據(jù)id到數(shù)據(jù)庫檢查是否被消費(fèi)，如果被消費(fèi)，則正常操作。
- 如果還沒被消費(fèi)，則休眠一定時(shí)間(比如30ms)，再重新檢查，如被消費(fèi)，則正常操作。
- 如果還沒被消費(fèi)，則拋出異常。
(4) 怎么解決百萬消息積壓問題
根據(jù)消息重要程度，可以分為兩種情況處理：
- 如果消息可以被丟棄，那么直接丟棄就好了。
- 一般情況下，消息是不可以被丟棄的，那么這樣需要考慮策略了，我們可以把原來的消費(fèi)端重新當(dāng)做生產(chǎn)端，重新部署一天MQ，再后面出現(xiàn)增加消費(fèi)端，這樣形成另一條生產(chǎn)-消息-消費(fèi)的線路。
網(wǎng)站標(biāo)題：了解MQ，讀這篇就夠了
網(wǎng)頁網(wǎng)址：http://m.5511xx.com/article/copdjoe.html
