1. 程式人生 > >RabbitMQ實戰-訊息持久化

RabbitMQ實戰-訊息持久化

在前面的第七和第八節我們講解了如何實現訊息的釋出和訂閱。同時也提到了一些問題,比如說如果RabbitMQ服務掛掉了,那麼我們的訊息也就丟失了。怎麼解決這樣的問題呢?這就需要我們將訊息進行持久化啦

這節,我們就在原有的基礎上來講解訊息的持久化

如何持久化
其實,在之前我們已經將訊息進行了持久化。只是我們並沒有去關注。

簡單說說訊息釋出訂閱的流程:

生產者將訊息傳送到訊息交換機,交換機根據一定的規則將訊息路由到指定的佇列。消費者再從指定的佇列上訂閱訊息。

所以,我們可以可以看到。如果想將訊息進行持久化,只需要將交換機和佇列持久化就可以了。當然,spring也為我們提供了很好的封裝。我們在建立交換機和佇列的時候都需要傳入一個引數 durable

durable true if we are declaring a durable queue (the queue will survive a server restart)
這是官方的說明,也就是說當我們在建立佇列時指定durable = true,當服務重啟的時候這個佇列將會存活。也就是說佇列被持久化了。同樣的,交換機的durable也和佇列同理。

測試持久化
接下來我們來測試下:

我們只啟動order服務,釋出訊息,而不消費它(比如傳送兩個訊息)。我們登入rabbitMQ,可以看到現在有2個訊息待消費。

然後停掉RabbitMQ的服務,

可以看到,服務已經被停了。

也不知道什麼鬼,停掉服務後重新整理瀏覽器是這個東東:

我們再次啟動服務,重新整理瀏覽器

可以看到,剛才的兩個訊息還在。證明訊息被持久化了。
--------------------- 
作者:朱_哲 
來源:CSDN 
原文:https://blog.csdn.net/zhuzhezhuzhe1/article/details/80705334 
版權宣告:本文為博主原創文章,轉載請附上博文連結!

相關推薦

RabbitMQ實戰-訊息持久化

在前面的第七和第八節我們講解了如何實現訊息的釋出和訂閱。同時也提到了一些問題,比如說如果RabbitMQ服務掛掉了,那麼我們的訊息也就丟失了。怎麼解決這樣的問題呢?這就需要我們將訊息進行持久化啦 這節,我們就在原有的基礎上來講解訊息的持久化 如何持久化 其實,在之前我們已

RabbitMQ(三):訊息持久化策略

一、前言   在正常的伺服器執行過程中,時常會面臨伺服器宕機重啟的情況,那麼我們的訊息此時會如何呢?很不幸的事情就是,我們的訊息可能會消失,這肯定不是我們希望見到的結果。所以我們希望AMQP伺服器崩潰了也可以將訊息恢復,這稱之為訊息持久化。RabbitMQ自然存在這種策略可以幫助我們完成這件事情。 二、持

RabbitMQ訊息持久化(轉)

原文地址 https://blog.csdn.net/u013256816/article/details/60875666/   訊息的可靠性是RabbitMQ的一大特色,那麼RabbitMQ是如何保證訊息可靠性的呢——訊息持久化。 為了保證RabbitMQ在退出或者crash等異常

RabbitMQ訊息持久化(佇列持久化訊息持久化)

訊息的可靠性是RabbitMQ的一大特色,那麼RabbitMQ是如何保證訊息可靠性的呢——訊息持久化。  為了保證RabbitMQ在退出或者crash等異常情況下資料沒有丟失,需要將queue,exchange和Message都持久化。 queue的持久化 queue

RabbitMQ 佇列訊息持久化

參考連結: https://www.cnblogs.com/Keep-Ambition/p/8044752.html  假如訊息佇列test裡面還有訊息等待消費者(consumers)去接收,但是這個時候伺服器端宕機了,這個時候訊息是否還在?  

RabbitMQ實戰-訊息確認機制之訊息的正確消費

上節中我們講了如何確保訊息的準確釋出,今天我們來看看如何確保訊息的正確消費。 在之前的基礎上我們對消費者(倉庫服務)進行完善。 修改配置檔案application.yml 消費者的ack方式預設是自動的,也就是說訊息一旦被消費(無論是否處理成功),訊息都會被確認,然後會從

RabbitMQ實戰篇9-訊息持久化

在前面的第七和第八節我們講解了如何實現訊息的釋出和訂閱。同時也提到了一些問題,比如說如果RabbitMQ服務掛掉了,那麼我們的訊息也就丟失了。怎麼解決這樣的問題呢?這就需要我們將訊息進行持久化啦這節,我們就在原有的基礎上來講解訊息的持久化如何持久化其實,在之前我們已經將訊息進

activemq實戰訊息持久化

對於activemq訊息的持久化我們在第二節的時候就簡單介紹過,今天我們詳細的來分析一下activemq的持久化過程以及持久化外掛。在生產環境中為確保訊息的可靠性,我們肯定的面臨持久化訊息的問題,今天就一起來攻克他吧。 1. 持久化方式介紹 前面我們也簡單提

RabbitMQ實戰篇8-在庫存服務中配置RabbitMQ,實現訊息接收

上節介紹瞭如何實現訊息的傳送,這節我們接著上節說說如何實現訊息的接收。 新增依賴,進行配置 同樣的,訊息消費者也需要新增RabbitMQ的依賴,配置連線資訊。 因為在上一節已經說過了,這裡過於依賴和連線資訊的配置就不在贅述了。 訂閱訊息 新建一個OrderConsumer,用於訂閱和消費訊

(四) RabbitMQ實戰教程(面向Java開發人員)之@RabbitListener訊息消費

使用RabbitListener註解進行訊息消費 在前一篇部落格中我們往MessageListenerContainer設定了MessageListener進行訊息的消費,本篇部落格將介紹一種更為簡單的訊息消費方式:使用@RabbitListener註解方式。

(六) RabbitMQ實戰教程(面向Java開發人員)之RabbitMQ訊息的可靠性

訊息可靠性 在專案中使用RabbitMQ時,我們可能會遇到這樣的問題:如一個訂單系統當用戶付款成功時我們往訊息中介軟體新增一條記錄期望訊息消費者修改訂單狀態,但是最終實際訂單狀態並沒有被修改成功。遇到這種問題我們排查的思路如下: 1.訊息是否已經成功傳送

RabbitMQ實戰教程(十二):訊息佇列的應用場景

這是網上的一篇教程寫的很好,不知原作者是誰,沒法註明出處,我看的時候也是別人轉載的,這裡就註明一下那篇轉載的地址:http://blog.csdn.net/cws1214/article/details/52922267 訊息佇列中介軟體是分散式系統中

RabbitMQ應用例項Python版-訊息確認和訊息持久化

訊息確認 當處理一個比較耗時得任務的時候,你也許想知道消費者(consumers)是否執行到一半就掛掉。當前的程式碼中,當訊息被RabbitMQ傳送給消費者(consumers)之後,馬上就會在記憶體中移除。這種情況,你只要把一個工作者(worker)停止,正在處理的訊

RabbitMQ 訊息持久化、事務、Publisher的訊息確認機制

RabbitMQ  訊息持久化、事務、Publisher的訊息確認機制 1. 宣告MessageQueue 在RabbitMQ中,無論是生產者傳送訊息還是消費者接受訊息,都首先需要宣告一個MessageQueue。 這就存在一個問題,是生產者宣告還是消費者宣告呢?要解決這個

RabbitMQ-訊息應答和訊息持久化

1.訊息應答 Ack (Message Acknowledgement) 訊息應答預設開啟 false autoAck = true (自動確認模式) 一旦rabbitMQ將訊息分發給消費者,就會從記憶體中刪除 這種情況下,如果消費者未處理完訊息就異常結束,

RabbitMQ原理三--訊息持久化

原文地址:http://www.cnblogs.com/ericli-ericli/p/5938106.html問題及方案描述1.當有多個消費者同時收取訊息,且每個消費者在接收訊息的同時,還要處理其它的事情,且會消耗很長的時間。在此過程中可能會出現一些意外,比如訊息接收到一半

rabbitmq 訊息持久化問題

       在開發階段,研究過一遍rabbitmq的訊息持久化問題,以為完美。但沒有想到準備釋出版本,有個BUG沒有時間處理,拖著,重啟了伺服器,卻發現rabbitmq的訊息已丟失,沒有持久。。鄙視一下當時的自己。      查找了一下官方文件,我用得是紅色框框這種

RabbitMQ訊息持久化

一、前言   如果我們希望即使在RabbitMQ服務重啟的情況下,也不會丟失訊息,我們可以將Queue與Message都設定為可持久化的(durable),這樣可以保證絕大部分情況下我們的RabbitMQ訊息不會丟失。當然還是會有一些小概率事件會導致訊息丟失。 二、佇列持久化   2.1 檢視存在的佇列

RabbitMQ(三)—訊息應答與訊息持久化

Message acknowledgment(訊息應答) 執行一個任務可能需要花費幾秒鐘,你可能會擔心如果一個消費者在執行任務過程中掛掉了。基於現在的程式碼,一旦RabbitMQ將訊息分發給了消費者,就會從記憶體中刪除。在這種情況下,如果殺死正在執行任務的消費

根據《RabbitMQ實戰--高效部署分散式訊息佇列》這本書來具體總結下

僅供個人學習,如有抄襲請包容cry.... 理解訊息通訊 一、       訊息通訊的概念--消費者、生產者和代理 生產者建立訊息,消費者接受這些訊息。你的應用程式可以作為生產者,向其他應用程式傳送訊息,或者作為一個消費者,接收訊息。也可以在兩者之間進行切換。不過在此之前,