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

 在實時消息系統中，MQ消息中間件普遍應用於各種消息系統中，在異步消息處理架構中，MQ幾乎是必備的中間件。 同時，MQ的處理性能也將直接影響整個系統的性能。若是MQ出現故障，那麼整個系統將癱瘓，其後果將是災難性的。 因此在通常狀況下MQ會中HA，或是failover，可是若是要求消息處理能力在10萬/秒以上時，簡單的HA或failover將不能知足要求。

    1、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模式，但此模式的應用場景不是很明確。

    2、多個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也就越低，系統吞吐量也就越高。

    3、Activemq 性能優化。

    一、 producer消息發送端，須要採用 AsyncSend模式， 在 activemq 的鏈接串中增長jsm.useAsyncSend, 例如 tcp://127.0.0.1:61616?jms.useAsyncSend=true 

    二、consumer消息消費端，若是有多個不一樣的應用程序去消費同一個隊列中的消息，那麼 activemq的 prefetchSize應該設置爲1。

   以上兩個參數對性能的影響很是大。