原创 ActiveMQ死信隊列

在ActiveMQ消息的可靠性中,介紹到在消費者接到到消息後,在處理過程中如果發生了異常,那麼ActiveMQ會對其進行重發,默認會重試6次,重發6次失敗後,就會進入死信隊列中。 這裏我們就來看一看死信隊列,死信隊列主要是用於保

原创 ActiveMQ之虛擬主題

虛擬主題主要用於什麼地方呢?這裏我們就來看一個運行場景,如一個系統中的消息消費者是有一個集羣組成的,這裏我們ActiveMQ需要發送M1~M8共8條消息,給A、B兩個消費者集羣進行消費,其示意圖如下: 效果如上,ActiveMQ

原创 ActiveMQ鏡像隊列

在之前我們介紹了ActiveMQ的Queue模式和Topic模式,其中Queue模式下,每一個消息只能被一個消費者消費,然而有時我們希望能夠監視生產者和消費者之間的消息流。 這裏我們可以通過ActiveMQ之組合Destinat

原创 ActiveMQ的延遲和定時投遞

在介紹ActiveMQ的延遲和定時投遞之前,這裏我們先來回顧下在併發編程中介紹的堵塞隊列(二)—— DelayQueue實現限時訂單,其中我們就提到了一個運行場景,即網上購物下單未支付,等支付時間到了之後的處理,最簡單的方式肯定就

原创 ActiveMQ消息的可靠性

我們在ActiveMQ消息持久化訂閱中,介紹了對Topic模式下的消息進行持久化訂閱,使其在暫無消費者消費或ActiveMQ服務重啓的情況下,不會導致消息的丟失,這裏其實就是保證了一定程度的消息可靠性。 那麼還會在其他地方發送消

原创 ActiveMQ存儲的持久化機制

我們在使用原生ActiveMQ的API編程中,介紹ActiveMQ的使用過程中,在介紹其Point-to-Point(P2P) /點對點模式時,我們發現在該模式下消息時不會丟失的 那麼這裏是如果做到消息的持久化呢?Active

原创 ActiveMQ集羣(二) —— Broker Cluster

ActiveMQ的集羣方式主要由兩種:Master-Slave和Broker Cluster。 我們在ActiveMQ集羣(一) —— Master-Slave 中,介紹了Master-Slave,發現了Master-Slave

原创 ActiveMQ通配符式訂閱

之前我們在介紹ActiveMQ的時候,在進行舉例的時候其生產者和消費者配置的目的地Destination一般都是一致的,不然我們的消費者也接受不到生產者發送的消息呀,但是其實我們的消費者在配置Destination的時候是可以進行

原创 RabbitMQ消息應答

消費者收到的每一條消息都必須進行確認。消息確認後,RabbitMQ纔會從隊列刪除這條消息,RabbitMQ不會爲未確認的消息設置超時時間,它判斷此消息是否需要重新投遞給消費者的唯一依據是消費該消息的消費者連接是否已經斷開。這麼設計

原创 RabbitMQ在Windows下安裝和運行

RabbitMQ在安裝上和ActiveMQ相比,就顯得麻煩多了,因爲在初識消息中間件中瞭解到Rabbit是採用erlang語言進行實現的,那麼首先我們肯定需要安裝其erlang的環境。 下載Erlang 首先這裏我們可以先去Er

原创 ActiveMQ消息持久化訂閱

在之前的介紹中,我們瞭解到在ActiveMQ中默認的Queue模式下,我們的消息是會進行持久化的,我們也介紹了其相關的機制,見ActiveMQ存儲的持久化機制,而在Topic模式下,消息在消費者消費的情況下,以及ActiveMQ服

原创 ActiveMQ集羣(一) —— Master-Slave

ActiveMQ的集羣方式主要由兩種:Master-Slave和Broker Cluster。 Master-Slave方式中,只能是Master提供服務,Slave是實時地備份Master的數據,以保證消息的可靠性。 當Mas

原创 RabbitMQ的基礎使用 —— Direct模式(二)

在RabbitMQ的基礎使用 —— Direct模式(一)中,我們已經瞭解了基礎的Direct模式的使用,其中我們發現一個隊列不僅僅可以對應一個路由鍵,它可以同時綁定多個路由鍵。 這裏我們繼續來了解下Rabbit中信道問題,之前

原创 RabbitMQ的管理

之前在RabbitMQ在Linux環境下安裝及運行中,我們介紹了CentOS環境下如何安裝Erlang及RabbitMQ,這裏緊接着來了解一下RabbitMQ的常用操作管理。 啓動和關閉RabbitMQ 啓動: rabbitmq

原创 RabbitMQ消息發佈之發送方確認

在RabbitMQ之失敗確認中,我們提到失敗確認只會讓RabbitMQ向你通知失敗,而不會通知成功。如果消息正確路由到隊列,則發佈者不會受到任何通知。帶來的問題是無法確保發佈消息一定是成功的,因爲通知失敗的消息可能會丟失。