rabbitmq 如何處理消息丟失的問題

這篇文章主要講解了“rabbitmq 如何處理消息丟失的問題”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“rabbitmq 如何處理消息丟失的問題”吧！

（1）rabbitmq

1）生產者弄丟了數據

生產者將數據發送到rabbitmq的時候，可能數據就在半路給搞丟了，因為網絡啥的問題，都有可能。

此時可以選擇用rabbitmq提供的事務功能，就是生產者發送數據之前開啟rabbitmq事務（channel.txSelect），然后發送消息，如果消息沒有成功被rabbitmq接收到，那么生產者會收到異常報錯，此時就可以回滾事務（channel.txRollback），然后重試發送消息；如果收到了消息，那么可以提交事務（channel.txCommit）。但是問題是，rabbitmq事務機制一搞，基本上吞吐量會下來，因為太耗性能。

所以一般來說，如果你要確保說寫rabbitmq的消息別丟，可以開啟confirm模式，在生產者那里設置開啟confirm模式之后，你每次寫的消息都會分配一個唯一的id，然后如果寫入了rabbitmq中，rabbitmq會給你回傳一個ack消息，告訴你說這個消息ok了。如果rabbitmq沒能處理這個消息，會回調你一個nack接口，告訴你這個消息接收失敗，你可以重試。而且你可以結合這個機制自己在內存里維護每個消息id的狀態，如果超過一定時間還沒接收到這個消息的回調，那么你可以重發。

事務機制和cnofirm機制最大的不同在于，事務機制是同步的，你提交一個事務之后會阻塞在那兒，但是confirm機制是異步的，你發送個消息之后就可以發送下一個消息，然后那個消息rabbitmq接收了之后會異步回調你一個接口通知你這個消息接收到了。

所以一般在生產者這塊避免數據丟失，都是用confirm機制的。

2）rabbitmq弄丟了數據

就是rabbitmq自己弄丟了數據，這個你必須開啟rabbitmq的持久化，就是消息寫入之后會持久化到磁盤，哪怕是rabbitmq自己掛了，恢復之后會自動讀取之前存儲的數據，一般數據不會丟。除非極其罕見的是，rabbitmq還沒持久化，自己就掛了，可能導致少量數據會丟失的，但是這個概率較小。

設置持久化有兩個步驟，第一個是創建queue的時候將其設置為持久化的，這樣就可以保證rabbitmq持久化queue的元數據，但是不會持久化queue里的數據；第二個是發送消息的時候將消息的deliveryMode設置為2，就是將消息設置為持久化的，此時rabbitmq就會將消息持久化到磁盤上去。必須要同時設置這兩個持久化才行，rabbitmq哪怕是掛了，再次重啟，也會從磁盤上重啟恢復queue，恢復這個queue里的數據。

而且持久化可以跟生產者那邊的confirm機制配合起來，只有消息被持久化到磁盤之后，才會通知生產者ack了，所以哪怕是在持久化到磁盤之前，rabbitmq掛了，數據丟了，生產者收不到ack，你也是可以自己重發的。

哪怕是你給rabbitmq開啟了持久化機制，也有一種可能，就是這個消息寫到了rabbitmq中，但是還沒來得及持久化到磁盤上，結果不巧，此時rabbitmq掛了，就會導致內存里的一點點數據會丟失。

3）消費端弄丟了數據

rabbitmq如果丟失了數據，主要是因為你消費的時候，剛消費到，還沒處理，結果進程掛了，比如重啟了，那么就尷尬了，rabbitmq認為你都消費了，這數據就丟了。

這個時候得用rabbitmq提供的ack機制，簡單來說，就是你關閉rabbitmq自動ack，可以通過一個api來調用就行，然后每次你自己代碼里確保處理完的時候，再程序里ack一把。這樣的話，如果你還沒處理完，不就沒有ack？那rabbitmq就認為你還沒處理完，這個時候rabbitmq會把這個消費分配給別的consumer去處理，消息是不會丟的。

感謝各位的閱讀，以上就是“rabbitmq 如何處理消息丟失的問題”的內容了，經過本文的學習后，相信大家對rabbitmq 如何處理消息丟失的問題這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！