消息隊列如何保證消息能百分百成功被消費

　　目前常用的消息隊列有很多種,如RabbitMQ,ActiveMQ,Kafka...下面以RabbitMQ為例來講如何保證消息隊列中的信息能百分百被消費掉.

　　其中消費隊列的工作流程如下:
　　

　　寫個偽代碼:　　

public boolean sendOrderMessage(String orderMessage){
RabbitTemplate rb = new RabbitTemplate();

    try{
        rb.send(orderMessage);
    }catch (Exception e){
        return  false;
    }
    return  true;

}
　　那么在訂單服務(wù)發(fā)送完消息的情況下,物流服務(wù)器突然宕機,或者MQ服務(wù)器突然宕機怎么辦?發(fā)送方已經(jīng)將消息發(fā)送,而消費方卻沒有接收到任何需要消費的信息,這就會導(dǎo)致,消息消費失敗.

1）消息生產(chǎn)者把消息發(fā)送給MQ，如果接收成功，MQ會返回一個ack消息給生產(chǎn)者

2）如果消息接收不成功，MQ會返回一個nack消息給生產(chǎn)者

　　碰到上面的問題,我們首先第一會想到解決方案就是發(fā)送方在消息發(fā)送到MQ之后,將消息給寫到硬盤上,這樣即使MQ服務(wù)器宕機,也不會導(dǎo)致未消費的消息丟失.

那么問題又出現(xiàn)了,當(dāng)高并發(fā)場景下這種方式顯而易見是不合理的,因為與磁盤進行I/O交互是相對非常慢的.當(dāng)然這種情況我們可以有解決方案: 可以在緩存中將消息緩存下來,比如當(dāng)消息滿1000條時就將這些消息一次性寫到磁盤中.

這種方案雖然可以解決I/O交互問題.但是還是不能解決宕機出現(xiàn)的問題,假如緩存了900條消息,并且這些消息均為被消費,此時宕機了,同樣會導(dǎo)致消息的丟失.顯然這種解決方案還需要優(yōu)化.

　　在上面方案的基礎(chǔ)上.我們可以再增加一個機制,增加一個確認(rèn)機制,如圖:

流程解釋:

1）訂單服務(wù)生產(chǎn)者再投遞消息之前，先把消息持久化到Redis或DB中，建議redis，高性能。消息的狀態(tài)為發(fā)送中。

2）confirm機制監(jiān)聽消息是否發(fā)送成功？如ack成功消息，刪除redis中此消息。

3）如果nack不成功的消息，這個可以根據(jù)自身的業(yè)務(wù)選擇是否重發(fā)此消息。也可以刪除此消息，由自己的業(yè)務(wù)決定。

4）這邊加了個定時任務(wù)，來拉取隔一定時間了，消息狀態(tài)還是為發(fā)送中的，這個狀態(tài)就表明，訂單服務(wù)是沒有收到ack成功消息。

5）定時任務(wù)會作補償性的投遞消息。這個時候如果MQ回調(diào)ack成功接收了，再把redis中此消息刪除

這種方案其實就是加上一個補償機制,不管MQ有沒有真正的接收到,只要緩存redis中的消息還是發(fā)送中的狀態(tài),就意味著這個消息沒有成功的投遞出去,也沒有被消費,定時任務(wù)啟動時就要重新發(fā)送.

當(dāng)然定時任務(wù)那邊我們還可以加上一個補償?shù)拇螖?shù)，如果大于3次，還是沒有收到ack消息，那就直接把消息的狀態(tài)設(shè)置為【失敗】，由人工去排查到底是為什么？

不過這樣的方案，就會有可能發(fā)送多次相同的消息，很有可能MQ已經(jīng)收到了消息，就是ack消息回調(diào)時出現(xiàn)網(wǎng)絡(luò)故障，沒有讓生產(chǎn)者收到。那就要要求消費者一定在消費的時候保障冪等性。

總結(jié)

以上是生活随笔為你收集整理的消息队列如何保证消息能百分百成功被消费的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。