物聯網環境下的大吞吐量下消息服務集羣設計

1、基於IBM MQ產品來實施JMS技術的消息服務應用服務器。

2、物聯網消息採用MQTT協議,WebSphere MQ Telemetry Transport (MQTT) 是一項專爲受限設備和受限網絡設計的異步消息通信協議,以輕量、精簡、開放和易於實現爲主要特點。

3、MQTT 規範是開放並且免版稅使用的,這有助於更好地推廣。提供開源的實現,在 http://eclipse.org/paho/上有各種客戶端的開源實現

4、發佈 - 訂閱的消息通信協議,允許一條消息只發布一次,便可被多個消費端(應用程序 / 設備)所接收

5、提供多種消息服務質量,包括 MQ 的黃金準則 -- 保證傳遞且僅有一次傳遞

  • 0 :消息最多被傳遞一次
  • 1 :消息會被傳遞但可能會重複傳遞
  • 2 :消息保證傳遞且僅有一次傳遞
6、爲受限的設備所設計 :
  • 預期客戶端應用程序 / 設備有可能僅具備非常有限的處理能力和資源
  • 佔用空間極小的 MQTT 客戶端 ( 和服務器 ) 類庫
7、易於使用(和實現)
  • 簡單的動詞集合,包括 connect, publish, subscribe 和 disconnect
  • 內建結構支持處理客戶端和服務器之間的連接丟失
  • 如果客戶端意外掉線,使用“遺願和遺囑”發佈一條消息
8、WebSphere MQ Telemetry 由 Telemetry 服務和 Telemetry 客戶端組成。其中 Telemetry 服務作爲 Queue Manager 的一部分,可作爲 MQTT 連接的服務器,Telemetry 客戶端可用來測試 MQTT 連接的可用性。

9、在傳統的開放平臺 WebSphere MQ 應用架構中,每個隊列管理器都是獨立的。當一個 QM 給另一個 QM 發送消息時,需要定義一個傳輸隊列(transmission queue), 一個連接到目的端 QM 的通道,並且需要在發送消息的客戶端上定義遠程隊列定義(remote queue definition)。爲了簡化 MQ 系統配置,可以通過 MQ 集羣的使用,減少隊列管理器上的對象數量,使得不同的 QM 可以互相通信而不需要定義衆多的傳輸隊列、通道以及遠程隊列定義。當集羣中含有一個以上的同一隊列實例時,WebSphere® MQ 會根據負載均衡算法選擇最佳的隊列進行消息路由。

10、MQ 集羣中的完全存儲倉庫存儲集羣中隊列管理器的元數據信息,一個集羣不建議使用超過兩個完全存儲倉庫

11、完全存儲倉庫建議不做業務應用,具體業務應用使用不完全存儲倉庫

12、在 MQ 集羣中使用 MQTT Telemetry 服務時,只需要在集羣中建立集羣主題(Cluster Topic),並且只需要在集羣中的一個隊列管理器創建,不需要創建共享隊列,默認使用 SYSTEM.MQTT.TRANSMIT.QUEUE

13、使用 MQ Telemetry 不需要手動創建訂閱對象(Subscriptions),MQXR 服務默認使用 client ID :topic string 爲名字自動創建訂閱對象

14、完整的MQTT協議規範pdf下載:http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/MQTT_V3.1_Protocol_Specific.pdf

15、 java -Xms50M -Xmx50M -Djava.ext.dirs=/root/mq/lib -cp mqttperf.jar SingleTopicSub -b 9.119.154.235 -c 1000 -m 50000 -t TestTopic -s 1 即一共創建了 1000 個訂閱者,無差錯情況下會接收到 50000 條消息。命令中參數 -Xms 指程序的初始化內存大小,-Xmx 指程序佔用的最大內存,-Djava.ext.dirs 指引用包路徑,該路徑文件夾中應該包含有 org.eclipse.paho.client.mqttv3.jar。注意:其中 -m 參數主要用來標記所有客戶端應該收到的消息總數,其值爲所有客戶端數與發佈程序發佈的消息數之乘積,用來和實際接收到的消息總數做比較,判斷所有消息是否被可靠傳輸。

發佈了497 篇原創文章 · 獲贊 34 · 訪問量 159萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章