MSMQ 和 MQTT

MSMQ

MicroSoft Message Queuing（微軟消息隊列)是在多個不一樣的應用之間實現相互通訊的一種異步傳輸模式，相互通訊的應用能夠分佈於同一臺機器上，也能夠分佈於相連的網絡空間中的任一位置。它的實現原理是：消息的發送者把本身想要發送的信息放入一個容器中（咱們稱之爲Message），而後把它保存至一個系統公用空間的消息隊列(Message Queue)中；本地或者是異地的消息接收程序再從該隊列中取出發給它的消息進行處理。

在消息傳遞機制中，有兩個比較重要的概念。一個是消息，一個是隊列。消息是由通訊的雙方所須要傳遞的信息，它能夠是各式各樣的媒體，如文本、聲音、圖象等等。消息最終的理解方式，爲消息傳遞的雙方事先商定，這樣作的好處是，一是至關於對數據進行了簡單的加密，二則採用本身定義的格式能夠節省通訊的傳遞量。消息能夠含有發送和接收者的標識，這樣只有指定的用戶才能看到只傳遞給他的信息和返回是否操做成功的回執。消息也能夠含有 時間戳，以便於接收方對某些與時間相關的應用進行處理。消息還能夠含有到期時間，它代表若是在指定時間內消息還未到達則做廢，這主要應用與時間性關聯較爲緊密的應用。

消息隊列是發送和接收消息的公用存儲空間，它能夠存在於內存中或者是物理文件中。消息能夠以兩種方式發送，即快遞方式(express)和可恢復模式(recoverable)，它們的區別在於，快遞方式爲了消息的快速傳遞，把消息放置於內存中，而不放於 物理磁盤上，以獲取較高的處理能力；可恢復模式在傳送過程的每一步驟中，都把消息寫入物理磁盤中，以獲得較好的故障恢復能力。消息隊列能夠放置在發送方、接收方所在的機器上，也能夠單獨放置在另一臺機器上。正是因爲消息隊列在放置方式上的靈活性，造成了 消息傳送機制的可靠性。當保存消息隊列的機器發生故障而從新啓動之後，以可恢復模式發送的消息能夠恢復到故障發生以前的狀態，而以快遞方式發送的消息則丟失了。另外一方面，採用消息傳遞機制，發送方沒必要要再擔憂接收方是否啓動、是否發生故障等等非必要因素，只要消息成功發送出去，就能夠認爲處理完成，而實際上對方可能甚至不曾開機，或者實際完成交易時可能已是次日了。

能夠說是內部消息隊列傳輸，接收到消息後有造成隊列處理，或分佈式處理，是內部服務器處理的機制

 

MQTT

MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發的一個即時通信協議，有可能成爲物聯網的重要組成部分。該協議支持全部平臺，幾乎能夠把全部聯網物品和外部鏈接起來，被用來當作傳感器和制動器（好比經過Twitter讓房屋聯網）的通訊協議。

MQTT應用

編輯

IBM和St. Jude醫療中心經過MQTT開發了一套Merlin系統，該系統使用了用於家庭保健的傳感器。St. Jude醫療中心設計了一個叫作Merlin@home的心臟裝置，這種無線發射器能夠用來監控那些已經植入復律-除顫器和起搏器（二者都是基本的傳感器）的心臟病人。

該產品利用MQTT把病人的即時更新信息傳給醫生/醫院，而後醫院進行保存。這樣的話，病人就不用親自去醫院檢查心臟儀器了，醫生能夠隨時查看病人的數據，給出建議，病人在家裏就能夠自行檢查。

IBM稱該發射器包括一個大型觸摸屏，一個嵌入式鍵盤平臺，以及一個Linux操做系統。

在將來幾年，MQTT的應用會愈來愈廣，值得關注。

經過MQTT協議，目前已經擴展出了數十個MQTT服務器端程序，能夠經過PHP，JAVA，Python，C，C#等系統語言來向MQTT發送相關消息。

此外，國內不少企業都普遍使用MQTT做爲Android手機客戶端與服務器端推送消息的協議。其中Sohu，Cmstop手機客戶端中均有使用到MQTT做爲消息推送消息。據Cmstop主要負責消息推送的高級研發工程師 李文凱稱，隨着移動互聯網的發展，MQTT因爲開放源代碼，耗電量小等特色，將會在移動消息推送領域會有更多的貢獻，在物聯網領域，傳感器與服務器的通訊，信息的收集，MQTT均可以做爲考慮的方案之一。在將來MQTT會進入到咱們生活的各各方面。

若是須要下載MQTT服務器端，能夠直接去MQTT官方網站點擊software進行下載MQTT協議衍生出來的各個不一樣版本。

MQTT特色

編輯

MQTT協議是爲大量計算能力有限，且工做在低帶寬、不可靠的網絡的遠程傳感器和控制設備通信而設計的協議，它具備如下主要的幾項特性：

一、使用發佈/訂閱消息模式，提供一對多的消息發佈，解除應用程序耦合；

二、對負載內容屏蔽的消息傳輸；

三、使用 TCP/IP 提供網絡鏈接；

四、有三種消息發佈服務質量：

• 「至多一次」，消息發佈徹底依賴底層 TCP/IP 網絡。會發生消息丟失或重複。這一級別可用於以下狀況，環境傳感器數據，丟失一次讀記錄無所謂，由於不久後還會有第二次發送。
• 「至少一次」，確保消息到達，但消息重複可能會發生。
• 「只有一次」，確保消息到達一次。這一級別可用於以下狀況，在計費系統中，消息重複或丟失會致使不正確的結果。

五、小型傳輸，開銷很小（固定長度的頭部是 2 字節），協議交換最小化，以下降網絡流量；

六、使用 Last Will 和 Testament 特性通知有關各方客戶端異常中斷的機制；  [2]