ActiveMQ的訊息對列的使用

2021-08-07 08:45:14 字數 2172 閱讀 9642

賦予執行許可權 chmod +x,windows可以忽略此步

執行 ./active start | stop

啟動後,activemq會占用兩個埠,乙個是負責接收傳送訊息的tcp埠:61616,乙個是基於web負責使用者介面化管理的埠:8161。這兩個埠可以在conf下面的xml中找到。http伺服器使用了jettry。這裡有個問題是啟動mq後,很長時間管理介面才可以顯示出來。

先附上bean**:

public

class

mqbean

implements

serializable

public

void

setage

(integer age)

public string getname

() public

void

setname

(string name)

}

2.1 佇列訊息的傳送:
public

static

void

main(string args)

producer.close();

system.out.println("呵呵");

} catch (jm***ception e)

}

注:在上面的**中,確認模式有三種,裡面的dups_ok_acknowledge和auto_acknowledge一直沒明白有什麼區別。因為無法測試。不過大概也明白了一些。其實主要是mq處理訊息的流程決定的:

訊息從生成方客戶端傳送到訊息伺服器。

訊息伺服器讀取訊息。

訊息被放置到永續性儲存器當中(出於可靠性的考慮)。

訊息伺服器確認收到訊息(出於可靠性的考慮)。

訊息伺服器確定訊息的路由。

訊息伺服器寫出訊息。

訊息從訊息伺服器傳送到使用方客戶端。

使用方客戶端確認收到訊息(出於可靠性的考慮)。

訊息伺服器處理客戶端確認(出於可靠性的考慮)。

訊息伺服器確定已經處理客戶端確認。

這些步驟是連續的,所以任何步驟都可能成為訊息從生成方客戶端到使用方客戶端的傳送過程的瓶頸。這些步驟中的大多數都取決於訊息傳送系統的物理特徵:網路頻寬、計算機處理速度和訊息伺服器體系結構等等。但是,有一些步驟還取決於訊息傳送應用程式的特徵和該應用程式要求的可靠性級別。其實就是基於可靠性還是效能的選擇.

2.2 佇列訊息的接收:

public

static

void main(string args)

} catch (exception e)

}});

} catch (exception e)

}

注:對於佇列來說,比較簡單的優化策略,應該就是佇列分載了。由於每個消費者都是單執行緒的,所以可以設定多個消費者來提高速度。大家可以複製個消費者自己測試下,在消費者中新增sleep測試下效果。

2.3 訂閱訊息的傳送

public

static

void

main(string args)

producer.close();

system.out.println("呵呵");

} catch (exception e)

}

2.4 訂閱訊息的接收
public

static

void main(string args)

} catch (exception e)

}});

} catch (exception e)

}

以上的訊息傳送後,如果沒有接收到,可以登入自己的mq管理頁面:  ,預設帳號密碼都是admin,檢視佇列中的訊息

number of pending messages 等待消費的訊息 這個是當前未出佇列的數量。可以理解為總接收數-總出佇列數

messages enqueued 進入佇列的訊息 進入佇列的總數量,包括出佇列的。 這個數量只增不減

messages dequeued 出了佇列的訊息 可以理解為是消費這消費掉的數量

ActiveMQ的訊息儲存方式

1.佇列儲存 採取先進先出模式,同一時間,訊息只會傳送給某乙個消費者,只有當該訊息被消費並告知已收到時,它才能在 的儲存中被刪除。對於永續性訂閱來說,每乙個消費者都會獲取訊息的拷貝。為了節約空間,的儲存介質中只儲存了乙份訊息,儲存介質的持久訂閱物件為其以後的被儲存的訊息維護了乙個指標,消費者消費時,...

ActiveMQ處理積壓的訊息

如果消費者變為慢速消費者,那麼後面可能會導致訊息積壓,導致生產者速度也變慢,甚至停止。我們可以配置訊息的過期時間,並設定訊息過期丟棄策略,以及使用死信佇列來處理訊息的積壓。activemq提供了乙個timestampingbrokerplugin外掛程式,通過此外掛程式,我們可以為持久化訊息設定過期...

ActiveMQ訊息的可靠性

我們在activemq訊息持久化訂閱中,介紹了對topic模式下的訊息進行持久化訂閱,使其在暫無消費者消費或activemq服務重啟的情況下,不會導致訊息的丟失,這裡其實就是保證了一定程度的訊息可靠性。那麼還會在其他地方傳送訊息不可靠的情況麼,首先我們從訊息的生產及消費的流程中來看,訊息有生產者傳送...