在應用開發中，持久化也是經常被提起的，持久化就是存在在內存當中的數據，要寫入到磁盤中，這樣在內存中的數據由于各種原因丟失掉后，可以通過磁盤重新加載到內存中來，對于消息中間件，持久化也至關重要。在生產者發布消息到broker后，消費者消費消息之前，消息是存在于內存當中，倘若消息丟失，那么就會造成消息的不一致性，這時就要對生產之后消費之前的消息做一下持久化操作。

RabbitMQ的持久化分為三個部分:交換器的持久化、隊列的持久化和消息的持久化，而我們要關注的就是消息的持久化。但是消息是依附于隊列而存在的，所以也要關注隊列的持久化，倘若隊列沒有做持久化而丟失了，那么消息還能依附到哪里呢？但是隊列的持久化能保證其本身的元數據不會因異常情況而丟失，但是并不能保證內部所存儲的 消息不會丟失。要確保消息不會丟失，需要將其設置為持久化。通過將消息的投遞模式 (BasicProperties中的deliveryMode屬性)設置為2，即可實現消息的持久化。代碼中消息投遞時設置的MessageProperties.PERSISTENT_TEXT_PLAIN實際上是封裝了這個屬性:

設置了隊列和消息的持久化，當RabbitMQ服務重啟之后，消息依舊存在。單單只設置隊 列持久化，重啟之后消息會丟失;單單只設置消息的持久化，重啟之后隊列消失，繼而消息也丟失。單單設置消息持久化而不設置隊列的持久化顯得毫無意義。這時要注意一個問題，如果將所有的消息都設為持久化，會嚴重影響RabbitMQ的性能。寫入 磁盤的速度比寫入內存的速度慢得不只一點點。所以對于可靠性不是那么高的消息可以不采用持久 化處理，以提高整體的吞吐量。在選擇是否要將消息持久化時，需要在可靠性和吐吞量之間做一個權衡。

那么隊列、消息都設置了持久化之后，就能百分百保證數據不丟失了嗎？

在持久化的消息正確發送到RabbitMQ之后，還需要有一段時間(雖然很短〉才能存入磁盤之中。RabbitMQ并不會為每條消息都進行同步存盤的處理，可能僅僅保存到操作系統緩存之中而不是物理磁盤之中。如果在這段時間內RabbitMQ 服務節點發生了巖機、重啟等異常情況，消息保存還沒來得及落盤，那么這些消息將會丟失。所以針對上面那個問題，答案是否定的。

對于這種問題的出現，需要保證RabbitMQ的高可用，來增加RabbitMQ的可靠性，也就是要引入RabbitMQ的鏡像隊列機制，進行主從配置，如果主節點master 在此特殊時間內掛掉，可以自動切換到從節點slave, 這樣有效地保證了高可用性，除非整個集群都掛掉。雖然這樣也不能完全保證RabbitMQ消息 不丟失，但是配置了鏡像隊列要比沒有配置鏡像隊列的可靠性要高很多，在實際生產環境中的關鍵業務隊列一般都會設置鏡像隊列。

還有一點就是消費者消費消息，如果在訂閱消費隊列時將autoAck參數設置為true，那么當消費者接 收到相關消息之后，還沒來得及處理就看機了，這樣也算數據丟失。這種情況很好解決，將autoAck參數設置為false，并進行手動確認，這點和生產者投遞消息保證一致性的處理機制，有著異曲同工之妙，就不再贅述了！

這樣的保證消息一致性的解決方案，完全是靠著RabbitMQ的自身機制來解決的，然而這樣的機制并不能保證消息百分之一百的不丟失，只是對于RabbitMQ來說已經盡力了，因為此時這樣的消息系統，已經接近保證消息的一致性了，要想再更一步的百分百的保證，還要借助于外力來解決，具體要借助于怎樣的外力，那么就要靠大家集思廣益了！原諒我的能力不足！

總結

以上是生活随笔為你收集整理的保证一致性吗_RabbitMQ消息一致性：重要消息，请设置持久化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。