高并發(fā)場景下，如何保證生產(chǎn)者投遞到消息中間件的消息不丟失？消息中間件消息不丟失主要從以下幾個方面考慮投遞生產(chǎn)者向消息中間件投遞消息是push的方式，這種方法會出現(xiàn)以下情況1、生產(chǎn)者掛掉了情況是這樣的，

高并發(fā)場景下，如何保證生產(chǎn)者投遞到消息中間件的消息不丟失？

消息中間件消息不丟失主要從以下幾個方面考慮

投遞

生產(chǎn)者向消息中間件投遞消息是push的方式，這種方法會出現(xiàn)以下情況

1、生產(chǎn)者掛掉了

情況是這樣的，你的生產(chǎn)者收到了數(shù)據(jù)，并存到了數(shù)據(jù)庫中，同時生產(chǎn)者要降消息push到消息中間件做異步處理。這時候如果生產(chǎn)者掛掉了，就導(dǎo)致消息數(shù)據(jù)沒有push到消息中間件里，也就會出現(xiàn)數(shù)據(jù)不一致的問題。

這時候我們可以在數(shù)據(jù)庫設(shè)置是否投遞成功標(biāo)志位，在生產(chǎn)者push之后，再將標(biāo)志位設(shè)置為已經(jīng)投遞。另外，客氣啟動一個定時任務(wù)，檢測是否有消息沒有投遞，保證消息數(shù)據(jù)一定會進入中間件。

2、消息重試

生產(chǎn)者沒有掛掉，但是因為網(wǎng)絡(luò)等其他問題，導(dǎo)致生產(chǎn)者不知道有沒有投遞成功。這時候生產(chǎn)者可以失敗重試，這保證消息可以再次投遞。但是這有可能會出現(xiàn)重復(fù)投遞，導(dǎo)致出現(xiàn)中間件消息數(shù)據(jù)重復(fù)。

存儲

消息中間件是存到磁盤上的，存入磁盤的消息一般是不會丟失的，同時磁盤文件還會做備份。如果一個丟失了，可以通過備份文件恢復(fù)。

消費

一般消費者需要在消費者消費成功之后再設(shè)置提交消費位點。如果消費失敗，消費者不提交消費位點還是可以消費該數(shù)據(jù)的。這就引出一個問題就是消息重復(fù)消費。這個問題和上邊提到的消息重復(fù)投遞相同，都會導(dǎo)致重復(fù)消費，這就需要考慮消費的冪等性，可以做消費記錄，防止重復(fù)消費。

JAVA面試如何保證消息不被重復(fù)消費？如何保證消息消費的冪等性？

我是閑著沒事干，來這里玩的，開始在各個網(wǎng)絡(luò)找技術(shù)資料，后就以《頭條》為主了。由找資料轉(zhuǎn)向了交朋友了。因為我想的東西落后了時代，有些的想的，由于自己程度不高。在腦子里只是勾思，達不到實際?。?！

如何設(shè)計一個MQ消息隊列？

1.先上圖，明確一個消息發(fā)送和消費的流程

2.消息消息首先需要定義消息協(xié)議，比如ActiveMQ，Stomp，XMPP等

3.消息協(xié)議定義好了，明確消息隊列需要滿足什么場景

是否需要保證消息可靠性，如果需要就要做存儲的高可用

是否需要支持同步和異步消息

是否需要保證消息的順序

是否需要支持延時消息

具體可以參照很多開源實現(xiàn)的特性，比如RocketMQ就是高可靠的，Kafka就是高吞吐量的，但是不是高可靠的。

如何保障消息中間件100%消息投遞成功？如何保證消息冪等性？

這個是互聯(lián)網(wǎng)公司使用 MQ 基本要捷俊的問題，本質(zhì)上還是問你使用消息隊列如何保證冪等性，以kafka來舉例，Kafka?有個 offset 的概念，每個消息寫進去，都有一個 offset，代表消息的序號，消費者消費之后，每隔一段時間會定時定期的 會把一消費過的消息的 offset 提交一下，表示已經(jīng)消費過，下次我重重啟或者服務(wù)死掉在重啟的時候，會繼續(xù)從上次消費到的 offset 來繼續(xù)消費。但是還是得結(jié)合業(yè)務(wù)來思考，比如你拿個數(shù)據(jù)要寫庫，你先根據(jù)主鍵查一下，如果這數(shù)據(jù)都有了，你就別插入了，update 一下好吧，最終還是要在數(shù)據(jù)方面在做一次去重操作