在實時訊息系統中,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。