Activemq構建高併發、高可用的大規模訊息系統

在網上看了很多關於Activemq的帖子，但是大部分的內容都只能算是對activemq官網內容的翻譯。很少有相關的案例分析，本文將分享”如何用Activemq構建超大（10萬筆訊息/秒以上）規模訊息系統”

在實時訊息系統中，MQ訊息中介軟體廣泛應用於各類訊息系統中，在非同步訊息處理架構中，MQ幾乎是必備的中介軟體。 同時，MQ的處理效能也將直接影響整個系統的效能。如果MQ出現故障，那麼整個系統將癱瘓，其後果將是災難性的。 所以在一般情況下MQ會中HA，或是failover，但是如果要求訊息處理能力在10萬/秒以上時，簡單的HA或failover將不能滿足要求。

 一、Activemq broker部署方式

1） 單MQ broker 時

整個系統中只有一個Activemq Broker，在生產系統中幾乎不使用。因為單個MQ存在單點故障。

2） Master – slave　模式

採用Master-slave模式，同時在連結串中增加failover功能， 能夠實現HA, 避免單點故障。但是，Master-slave方式一般需要”共享檔案系統”，同時必須保證出現問題時，檔案鎖能正常切換。另外，slave處於stand by狀態，不對外提供服務。 在Master高負荷的情況下，Slave不能提供能幫助。如果Master在高負荷情況下掛掉，那麼Slave在同樣的情況下也可能掛掉，只是時間問題。（ Replicate Leveldb 方案也存在上述問題）。 另外，activemq 還有network模式，但此模式的應用場景不是很明確。

    二、多個Activemq broker 同時工作

通過上面的分析， 簡單的採用Activemq官網上提供的方案基本上不能滿足生產系統的效能和高可用要求。因此，必須對上述方案進行改進，實現 “高效能”，“高可用”，“可擴充套件”的MQ叢集方案。

同時部署多個Activemq broker例項, 多個Activemq broker例項同時工作。單個broker例項，生產和消費訊息的速度在1萬條/秒，部署N個Broker, 整個訊息通道就能拓寬N倍； 多個（4個以上）broker 例項同時工作，其中1到2個mq例項出現問題時，訊息可經過其他broker處理，整個系統依然可以健康工作，從而實現高可用。

a、訊息傳送方的應用程式的採用輪循方式給多個broker傳送訊息

b、訊息消費方的應用程式針對每個broker啟用對應的consumer來消費訊息。

按照這樣的部署方案，兩個或兩個以上MQ可以同時工作，可以解決MQ單點問題。MQ做為訊息的傳輸管道， 增加MQ數量就可以拓寬管道的寬度，提高訊息傳輸效能。

 

我們將“多個同時工作的broker”成為 broker組，如果 broker組內的broker數量太多的話，那麼再開發或部署時，broker內的佇列配置將會是一件非常繁瑣的事。因此，我們將broker內的佇列queue進行分組，具有相同字首名的佇列為一組，字首名相同的佇列中的訊息的業務邏輯是相同的。通過佇列字首名將訊息元件與業務關聯上。 根據業務不同，配置不同的sender  和 listener 時，只要配置不同的佇列字首名。從而簡化配置與使用，同時也可以防止訊息發錯佇列的錯誤。

如上圖，有 ChargeQueue 和 QueryQueue連個佇列組，對應不同的業務功能。

在訊息消費的應用程式中，針對ChargeQueue 和 QueryQueue 配置Consumer Listener Container， 同時可以正對不同的佇列配置不同數量的消費則數目。

單個ActiveMQ的接收和消費訊息的速度在1萬筆/秒（持久化 一般為1-2萬， 非持久化 2 萬以上），在生產環境中部署10個Activemq就能達到10萬筆/秒以上的效能，部署越多的activemq broker 在MQ上latency也就越低，系統吞吐量也就越高。

三、Activemq 效能優化。

1、 producer訊息傳送端，需要採用 AsyncSend模式， 在 activemq 的連線串中增加jsm.useAsyncSend, 例如 tcp://127.0.0.1:61616?jms.useAsyncSend=true

2、consumer訊息消費端，如果有多個不同的應用程式去消費同一個佇列中的訊息，那麼 activemq的 prefetchSize應該設定為1。

以上兩個引數對效能的影響非常大。

四、實現程式碼

以上方案的訊息傳送端元件 和  消費端listenerContainer的實現程式碼。

原文地址http://www.bieryun.com/2101.html