朱艷

摘要：隨著智能設(shè)備的快速普及和移動(dòng)應(yīng)用的迅猛發(fā)展，已進(jìn)入移動(dòng)互聯(lián)網(wǎng)時(shí)代。消息推送是移動(dòng)應(yīng)用的一個(gè)顯著特征，是移動(dòng)互聯(lián)網(wǎng)時(shí)代的基礎(chǔ)設(shè)施。蘋(píng)果和谷歌都提供消息推送服務(wù)，但并不能滿足企業(yè)級(jí)移動(dòng)應(yīng)用的推送要求。MQTT協(xié)議是由IBM提出的面向物聯(lián)網(wǎng)的通訊協(xié)議，其簡(jiǎn)潔，高效，可靠等特征非常適合用于構(gòu)建消息推送服務(wù)。文章討論了使用MQTT協(xié)議構(gòu)建消息推送服務(wù)的必要性和適用性，并指出了在具體實(shí)現(xiàn)上應(yīng)注意的一些關(guān)鍵問(wèn)題，同時(shí)給出了相關(guān)建議。

關(guān)鍵詞：移動(dòng)應(yīng)用；消息推送；MQTT

1消息推送是移動(dòng)應(yīng)用的基礎(chǔ)功能

現(xiàn)今已經(jīng)從互聯(lián)網(wǎng)時(shí)代快速進(jìn)入到了移動(dòng)互聯(lián)網(wǎng)時(shí)代。根據(jù)相關(guān)資料，早在2014年，智能手機(jī)和平板電腦的銷售量就已經(jīng)超過(guò)了傳統(tǒng)Pc的銷售量，而且這一趨勢(shì)還在不斷加強(qiáng)，以智能手機(jī)為主的移動(dòng)設(shè)備仍然在高速增長(zhǎng)。

信息化系統(tǒng)建設(shè)也相應(yīng)地轉(zhuǎn)向移動(dòng)設(shè)備，傳統(tǒng)的基于桌面瀏覽器的應(yīng)用系統(tǒng)日漸式微，移動(dòng)應(yīng)用（APP）已成為主流趨勢(shì)。以前的熱門網(wǎng)站不再受到人們的追捧，取而代之的是運(yùn)行在手機(jī)上的各種APP0一個(gè)顯著的例子是微信和QQ，同樣由騰訊公司開(kāi)發(fā)的社交應(yīng)用，兩者分別代表了移動(dòng)互聯(lián)網(wǎng)和傳統(tǒng)互聯(lián)網(wǎng)，微信的歷史只有短短的4-5年，但其活躍用戶數(shù)已經(jīng)遠(yuǎn)超歷史悠久的QQ。在企業(yè)內(nèi)部，政府部門、事業(yè)單位內(nèi)部，也紛紛調(diào)整其信息化建設(shè)，向移動(dòng)應(yīng)用方向傾斜，移動(dòng)化已成為共識(shí)。

移動(dòng)應(yīng)用作為一種新的應(yīng)用類型，與傳統(tǒng)基于桌面的瀏覽器/服務(wù)器（Browser/Server）架構(gòu)相比較，在應(yīng)用場(chǎng)景，交互方式，開(kāi)發(fā)技術(shù)等方面都有所不同。對(duì)于使用者而言，移動(dòng)應(yīng)用將其從電腦前解放了出來(lái)，使用者可以在任何時(shí)間，任意地點(diǎn)打開(kāi)移動(dòng)應(yīng)用，瀏覽自己所需要的信息，或者進(jìn)行相應(yīng)的操作，只需設(shè)備聯(lián)網(wǎng)即可。這種便利性使得移動(dòng)應(yīng)用迅速受到使用者的歡迎。而且，由于移動(dòng)設(shè)備隨身攜帶，并一直保持網(wǎng)絡(luò)連接狀態(tài)，移動(dòng)應(yīng)用能夠做到主動(dòng)的消息推送和提醒，而無(wú)需使用者不時(shí)打開(kāi)應(yīng)用去查看，實(shí)現(xiàn)了信息主動(dòng)找人。

消息推送是移動(dòng)應(yīng)用的基礎(chǔ)功能，是移動(dòng)互聯(lián)網(wǎng)時(shí)代的重要基礎(chǔ)設(shè)施，是移動(dòng)應(yīng)用區(qū)別于傳統(tǒng)應(yīng)用的一個(gè)重要特征和優(yōu)勢(shì)，可以說(shuō)，沒(méi)有消息推送的移動(dòng)應(yīng)用就不能稱之為移動(dòng)應(yīng)用。

2現(xiàn)有推送服務(wù)及問(wèn)題

根據(jù)移動(dòng)操作系統(tǒng)的不同，當(dāng)前移動(dòng)領(lǐng)域主要分為兩個(gè)體系：蘋(píng)果公司的iOS系統(tǒng)和由谷歌公司主導(dǎo)的Andriod系統(tǒng)。這兩大陣營(yíng)都意識(shí)到了移動(dòng)消息推送在移動(dòng)應(yīng)用建設(shè)上的基礎(chǔ)性地位，并提供了相應(yīng)的推送服務(wù)，供開(kāi)發(fā)者或企業(yè)用戶調(diào)用。但是，無(wú)論是蘋(píng)果還是谷歌的推送服務(wù)，都存在服務(wù)質(zhì)量，安全性，處理容量等問(wèn)題，特別是對(duì)于企業(yè)、政府等高端用戶而言，這些推送服務(wù)都無(wú)法滿足實(shí)際需要。

2.1蘋(píng)果推送通知服務(wù)（APNS，Apple Push NotificationService）

蘋(píng)果為全球范圍的lOS設(shè)備提供推送通知服務(wù)。當(dāng)服務(wù)的提供方（Provider）希望給某個(gè)設(shè)備上的應(yīng)用推送消息時(shí)，需要調(diào)用蘋(píng)果APNS提供的推送服務(wù)，將目標(biāo)設(shè)備（設(shè)備令牌）和消息內(nèi)容（有效載荷）傳遞給APNS服務(wù)，APNS會(huì)負(fù)責(zé)找到相應(yīng)的目標(biāo)設(shè)備，并將消息傳遞給該設(shè)備；該設(shè)備收到消息后，會(huì)將消息傳給相應(yīng)的應(yīng)用APP，由APP處理消息，提醒用戶。其處理過(guò)程在蘋(píng)果的開(kāi)發(fā)者網(wǎng)站有詳細(xì)描述如圖1所示。

從實(shí)際使用情況看，APNS服務(wù)比較穩(wěn)定，一般情況下消息也能被及時(shí)傳遞，基本能夠滿足一般性消費(fèi)類移動(dòng)應(yīng)用的需要。但是，對(duì)于具有更高消息推送要求的企業(yè)級(jí)市場(chǎng)，APNS就顯得力不從心，具有以下問(wèn)題。

（1）不保證消息到達(dá)。如果移動(dòng)設(shè)備暫時(shí)無(wú)法聯(lián)網(wǎng)，服務(wù)的提供方也可以推送消息，蘋(píng)果會(huì)負(fù)責(zé)暫時(shí)保存該消息；當(dāng)設(shè)備再次可用時(shí)，保存的消息會(huì)被推送。但是，蘋(píng)果只會(huì)為同一個(gè)設(shè)備保留最近的一條消息。如果在設(shè)備持續(xù)無(wú)法聯(lián)網(wǎng)的情況下，服務(wù)提供方再次推送消息，會(huì)導(dǎo)致上一條推送消息的丟失，而且不會(huì)告知。這對(duì)于普通消費(fèi)型應(yīng)用問(wèn)題不大，但對(duì)于企業(yè)級(jí)應(yīng)用則不然，特別是對(duì)于某些重要性很高，而且推送消息很頻繁的移動(dòng)應(yīng)用而言，隨意丟棄消息是不可接受的。

（2）不保證消息傳遞時(shí)效。APNS服務(wù)宣稱會(huì)盡快傳遞消息，但不保證多長(zhǎng)時(shí)間內(nèi)可以傳遞到，不能要求限時(shí)到達(dá)。而且，它沒(méi)有消息優(yōu)先級(jí)的設(shè)置，所有的消息都按照同樣的優(yōu)先級(jí)傳遞，不能對(duì)消息區(qū)別對(duì)待。

（3）消息大小有限制。如果移動(dòng)設(shè)備的操作系統(tǒng)不是最新的iOS 8，那么推送消息內(nèi)容不能超過(guò)256字節(jié)，只能用來(lái)傳遞一些最簡(jiǎn)單的消息。企業(yè)級(jí)應(yīng)用中，這么小的數(shù)據(jù)量幾乎是無(wú)法使用的。如果將移動(dòng)設(shè)備升級(jí)到iOS 8，最大推送字節(jié)數(shù)會(huì)增加到2000字節(jié)。很多情況下，這一數(shù)值也無(wú)法滿足企業(yè)級(jí)移動(dòng)應(yīng)用的要求。

（4）發(fā)送頻率受控。蘋(píng)果官方對(duì)單位時(shí)間內(nèi)允許推送的消息數(shù)沒(méi)有限定，但在實(shí)際使用時(shí)發(fā)現(xiàn)，如果與推送服務(wù)器建立的網(wǎng)絡(luò)連接數(shù)過(guò)多，或者推送消息的頻率過(guò)于密集，都會(huì)導(dǎo)致蘋(píng)果拒絕服務(wù)，無(wú)法推送。

（5）不支持消息回執(zhí)。最終用戶有沒(méi)有收到消息？如果客戶端收到了，具體是什么時(shí)間點(diǎn)收到的？這種需求對(duì)于企業(yè)應(yīng)用很常見(jiàn)，但APNS并沒(méi)有提供類似的消息回執(zhí)機(jī)制。

（6）無(wú)法控制數(shù)據(jù)安全。雖然APNS提供了相應(yīng)的數(shù)據(jù)傳輸安全機(jī)制，確保在傳輸過(guò)程中的安全，但數(shù)據(jù)畢竟是經(jīng)過(guò)蘋(píng)果的服務(wù)器傳遞，而且，如果設(shè)備不在線，消息還會(huì)在蘋(píng)果的服務(wù)器上保存。這對(duì)于一些對(duì)數(shù)據(jù)敏感性有要求的組織或機(jī)構(gòu)而言是不允許的。某些要求嚴(yán)格的企業(yè)，甚至?xí)笠苿?dòng)設(shè)備全部使用VPN專有網(wǎng)絡(luò)，所有的互聯(lián)網(wǎng)服務(wù)都不允許訪問(wèn)，這種情況TAPNS就更無(wú)法使用了。

2.2谷歌云推送（GcM，Google Cloud Messaging forAndroid）

與蘋(píng)果類似，谷歌也為Android設(shè)備提供了一個(gè)公共的消息推送服務(wù)，其架構(gòu)如圖2所示。與APNS類似，第三方應(yīng)用需要推送消息時(shí)，只需要連接到一個(gè)GCM服務(wù)器，調(diào)用消息推送服務(wù)，就可以將消息傳遞到指定的移動(dòng)設(shè)備，并喚起相應(yīng)的移動(dòng)應(yīng)用。

谷歌云推送在功能上較APNS有不少增強(qiáng)，支持包括消息回執(zhí)功能，send-to-sync消息機(jī)制等，其最大可推送的消息內(nèi)容也較蘋(píng)果的大，為4000字節(jié)。

但是，現(xiàn)實(shí)的情況是，由于網(wǎng)絡(luò)原因，谷歌的推送服務(wù)在國(guó)內(nèi)根本無(wú)法訪問(wèn)，無(wú)法訪問(wèn)谷歌的GCM服務(wù)器，谷歌的GCM服務(wù)器也無(wú)法與我們的移動(dòng)手機(jī)建立推送連接。而且，消息推送需要手機(jī)與服務(wù)器兩者的相互配合，手機(jī)端必須具備相應(yīng)的GCM接收服務(wù)，才能接收到推送的消息，但由于Android手機(jī)廠商的分裂狀態(tài)，幾乎每個(gè)手機(jī)廠商都會(huì)用自己的推送服務(wù)替代原有的GCM接收服務(wù)，這就導(dǎo)致即使GcM月艮務(wù)器可以訪問(wèn)，手機(jī)端也無(wú)法接收到消息。除非能全部限定所有的移動(dòng)設(shè)備為同一家供應(yīng)商，否則也無(wú)法使用手機(jī)廠商提供的推送服務(wù)。而現(xiàn)實(shí)中，幾乎不存在這種設(shè)備完全由同一個(gè)廠商供應(yīng)的可能性。

需要說(shuō)明的是，基于谷歌一貫的開(kāi)放策略，GCM也是一個(gè)開(kāi)放性的標(biāo)準(zhǔn)，任何人或企業(yè)都可以直接使用谷歌提供的推送云服務(wù)，也可以自行根據(jù)GCM服務(wù)端的標(biāo)準(zhǔn)規(guī)范實(shí)現(xiàn)私有的GCM推送服務(wù)。不過(guò)，GCM在消息通訊協(xié)議上只有HTTP和XMPP兩種選擇，這兩種協(xié)議無(wú)論從傳輸效率，可靠性角度，還是從安全的角度看，都不是最適合移動(dòng)應(yīng)用的協(xié)議。

綜上所述，消息推送作為一個(gè)新的技術(shù)話題，在協(xié)議規(guī)范和技術(shù)標(biāo)準(zhǔn)方面都還沒(méi)有形成業(yè)界標(biāo)準(zhǔn)，蘋(píng)果和谷歌作為業(yè)界領(lǐng)先的兩大企業(yè)，雖然提供了針對(duì)各自平臺(tái)的推送服務(wù)，但都存在不同程度的問(wèn)題，特別是對(duì)于企業(yè)級(jí)高端用戶而言。

構(gòu)建消息推送服務(wù)是一個(gè)系統(tǒng)工程，需要進(jìn)行完備的架構(gòu)設(shè)計(jì)。這其中，推送協(xié)議的選擇至關(guān)重要，不同的協(xié)議會(huì)直接影響推送的速度，服務(wù)質(zhì)量和用戶滿意度。

3MQTT協(xié)議

消息隊(duì)列遙測(cè)傳輸（MQTT，Message QueuingTelemetry Transport）協(xié)議是IBM公司提出的開(kāi)放協(xié)議，最初的設(shè)想是應(yīng)用于大量計(jì)算能力有限的傳感器等微型設(shè)備，其工作的網(wǎng)絡(luò)帶寬低且不穩(wěn)定，但又需要保證網(wǎng)絡(luò)節(jié)點(diǎn)之間的可靠通訊。

該協(xié)議目前已經(jīng)被結(jié)構(gòu)化信息標(biāo)準(zhǔn)促進(jìn)組織（OASIS）接受，并將其建議為物聯(lián)網(wǎng)消息傳遞協(xié)議的首選標(biāo)準(zhǔn)。MQTT已經(jīng)成為物聯(lián)網(wǎng)領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，IBM公司已經(jīng)成功將其應(yīng)用于智能實(shí)驗(yàn)室、遠(yuǎn)程醫(yī)療中心等項(xiàng)目，并推出了MessageSight等MQTT中間件產(chǎn)品，其它企業(yè)和機(jī)構(gòu)也相繼跟進(jìn)，發(fā)布支持MOTT協(xié)議的開(kāi)源/商業(yè)產(chǎn)品，或采用MQTT協(xié)議構(gòu)建相關(guān)應(yīng)用。伴隨著物聯(lián)網(wǎng)的迅猛發(fā)展，MQTT協(xié)議未來(lái)的發(fā)展不可限量。

由于物聯(lián)網(wǎng)傳感器等設(shè)備的計(jì)算能力和電量都非常有限，因此MQTT的設(shè)計(jì)理念從一開(kāi)始就是簡(jiǎn)單，輕量，節(jié)省電力，這正好滿足了移動(dòng)應(yīng)用的一個(gè)重要訴求。當(dāng)前電池儲(chǔ)能技術(shù)的發(fā)展遠(yuǎn)遠(yuǎn)不能滿足智能手機(jī)的發(fā)展需要，使用智能手機(jī)用戶最痛苦的事情就是手機(jī)耗電太快，手機(jī)的電量甚至不能支持完8小時(shí)的工作時(shí)間。但如果要保證消息及時(shí)到達(dá)，手機(jī)就必須時(shí)刻保持與服務(wù)器的連接，并定期與其通訊，檢查是否有新消息。MQTT協(xié)議非常精簡(jiǎn)，額外的數(shù)據(jù)傳輸量非常小，可以在最大限度節(jié)省電力，同時(shí)也節(jié)省網(wǎng)絡(luò)流量。這是選擇MQTT構(gòu)建消息推送服務(wù)的最大原因。

MOTT協(xié)議的消息頭固定為2個(gè)字節(jié)，當(dāng)前只使用了第一個(gè)字節(jié)，第二個(gè)字節(jié)保留。第一個(gè)字節(jié)共8個(gè)bit位，前4位為控制類型，可取值為16種，按照功能可以分為連接類，訂閱類，保持活動(dòng)類幾種，后4位攜帶每種控制類型的特有信息如表1所示。

作為對(duì)比，讓我們來(lái)看看最常見(jiàn)的HTTP協(xié)議的消息頭，如圖3所示為訪問(wèn)百度主頁(yè)（www.baidu.com）時(shí)，HTTP請(qǐng)求所提交的消息頭信息，其數(shù)據(jù)量超過(guò)300字節(jié)，是MQTT協(xié)議（2個(gè)字節(jié)）的150倍。而且，這只是一個(gè)比較小的HTTP消息頭，如果用戶多次訪問(wèn)同一網(wǎng)站，會(huì)有不斷增長(zhǎng)的Cookie信息，消息頭的內(nèi)容會(huì)更多。

為了實(shí)現(xiàn)及時(shí)推送，手機(jī)需要周期性給服務(wù)器發(fā)送請(qǐng)求（心跳），以保持與消息推送服務(wù)器的連接不中斷。假設(shè)手機(jī)每30秒發(fā)送一次心跳，每天就需要發(fā)送2880次，如果采用MQTT協(xié)議，只需5k的通訊流量，而如果采用HTTP方式，則需要的流量為864k，其高下一目了然。而手機(jī)需要消耗的電力與需要傳輸?shù)臄?shù)據(jù)量直接相關(guān)。

除了短小精悍，節(jié)約帶寬，節(jié)省電量消耗，MQTT協(xié)議還具有其它的特性，非常適合用于構(gòu)建移動(dòng)應(yīng)用的消息推送服務(wù)。

（1）保證服務(wù)質(zhì)量。MQTT提供三種消息傳輸?shù)姆?wù)質(zhì)量保障水平，用戶可以根據(jù)實(shí)際需要進(jìn)行選擇：

QoS0：至多傳遞一次。消息有可能會(huì)丟失。這種服務(wù)質(zhì)量下，消息傳遞的速度最快，但不能保證消息的可靠到達(dá)。通常適用于網(wǎng)絡(luò)環(huán)境差，而且不在意單次數(shù)據(jù)丟失的情況，例如GPS數(shù)據(jù)的采集。

QoS1：至少傳遞一次。可以確保消息被可靠傳遞到目標(biāo)，但可能會(huì)有消息被重復(fù)傳遞。這種服務(wù)質(zhì)量權(quán)衡了傳輸效率和消息可靠性，最常被采用。

QoS2：確定只傳遞一次。消息不會(huì)被丟失，也不會(huì)被重復(fù)傳遞。這種服務(wù)質(zhì)量被用來(lái)保證最高的消息傳遞服務(wù)質(zhì)量。

（2）連接中斷通知。與物聯(lián)網(wǎng)類似，手機(jī)的網(wǎng)絡(luò)質(zhì)量遠(yuǎn)不能與連接網(wǎng)線的臺(tái)式機(jī)相比，當(dāng)我們發(fā)生位移時(shí)，或者進(jìn)入電梯，地下室等區(qū)域時(shí)，手機(jī)經(jīng)常會(huì)發(fā)生基站切換，網(wǎng)絡(luò)信號(hào)消失，連接中斷等情況。MQTT協(xié)議可以很好地適應(yīng)這種不穩(wěn)定的網(wǎng)絡(luò)環(huán)境，并且保證數(shù)據(jù)的可靠傳輸。而且，當(dāng)發(fā)生網(wǎng)絡(luò)異常中斷時(shí)，MQTT還支持遺囑機(jī)制，將網(wǎng)絡(luò)中斷事件通知給指定的目標(biāo)對(duì)象。

（3）信息廣播機(jī)制。MQTT采用發(fā)布/訂閱機(jī)制來(lái)傳遞信息，多個(gè)手機(jī)終端可以訂閱同一個(gè)主題；服務(wù)端只需要針對(duì)主題發(fā)布信息，所有訂閱者都可以收到，而無(wú)需對(duì)逐個(gè)手機(jī)發(fā)送，簡(jiǎn)單高效。例如，股票價(jià)格信息，不同的人可以訂閱關(guān)注同一個(gè)股票的價(jià)格信息，當(dāng)該股票的價(jià)格發(fā)生變化時(shí)，服務(wù)端只需發(fā)布一次最新價(jià)格，所有的訂閱者都會(huì)收到同樣消息。

4其它問(wèn)題

在采用MQTT協(xié)議構(gòu)建移動(dòng)應(yīng)用的消息推送服務(wù)時(shí)，也應(yīng)當(dāng)了解MQTT的不足，并妥善處理如下問(wèn)題。

4.1避免客戶端越權(quán)訂閱

MQTT采用發(fā)布/訂閱模式處理消息傳遞，消息是針對(duì)主題傳遞，而不是目標(biāo)客戶端。客戶端只要進(jìn)行訂閱，就可以收到消息。理論上，如果某個(gè)客戶端訂閱了根主題，就可以收到所有人的消息，這是不可接受的。

可以啟用MQTT的用戶認(rèn)證機(jī)制，只有經(jīng)過(guò)認(rèn)證的用戶才可以訂閱主題，但這只能防止非認(rèn)證用戶的惡意訂閱，對(duì)于認(rèn)證通過(guò)的用戶則不起作用。

徹底的解決方法需要在服務(wù)端進(jìn)行控制，不允許用戶訂閱其沒(méi)有權(quán)限的主題。另外，一些MQTT產(chǎn)品對(duì)此也有處理，例如，IBM的MessageSight產(chǎn)品就支持點(diǎn)對(duì)點(diǎn)和發(fā)布/訂閱兩種方式，而使用點(diǎn)對(duì)點(diǎn)方式時(shí)，任意訂閱都不起作用。

4.2處理iOS后臺(tái)服務(wù)運(yùn)行

ios系統(tǒng)對(duì)于后臺(tái)服務(wù)的長(zhǎng)時(shí)間運(yùn)行有很多限制，MQTT要求與服務(wù)端—直保持連接，在iOS系統(tǒng)下不容易做到。當(dāng)移動(dòng)APP在前臺(tái)運(yùn)行時(shí)，MQTT可以建立并保持與推送服務(wù)器的連接，但是，一旦移動(dòng)APP被推入后臺(tái)，所有的活動(dòng)，包括連接都會(huì)被中斷。

iOS允許某些應(yīng)用在后臺(tái)保持運(yùn)行，但需要經(jīng)過(guò)蘋(píng)果的-審核，而且服務(wù)端還需要定期給移動(dòng)設(shè)備發(fā)送數(shù)據(jù)以保持網(wǎng)絡(luò)連接，相對(duì)而言較為繁瑣。

另4中解決方式是將MQTT推送與APNS相結(jié)合，當(dāng)MQTT連接被中斷時(shí)，推送改為使用APNS通道。當(dāng)有新消息需要推送時(shí)，推送服務(wù)器發(fā)送一個(gè)APNS的提示消息（沒(méi)有具體消息內(nèi)容），然后由APNS消息激活移動(dòng)應(yīng)用，喚起MQTT月艮務(wù)，再通過(guò)MQTT渠道具體的推送消息內(nèi)容。這種方式只將APNS作為一個(gè)旁路提醒通道，不傳遞消息內(nèi)容，保證了數(shù)據(jù)的安全性。

4.3可擴(kuò)展的MQTT服務(wù)端

消息推送需要移動(dòng)設(shè)備與推送服務(wù)器保持長(zhǎng)連接，這與傳統(tǒng)應(yīng)用不同。傳統(tǒng)的B/s應(yīng)用是短連接模式，客戶端向服務(wù)端發(fā)起請(qǐng)求，服務(wù)端處理完成后返回結(jié)果給客戶端，然后釋放連接。如果不考慮業(yè)務(wù)邏輯處理對(duì)服務(wù)器資源的使用，單個(gè)服務(wù)器可以輕松支持幾十萬(wàn)，甚至上百萬(wàn)的用戶訪問(wèn)。但是，如果拿一臺(tái)普通的服務(wù)器當(dāng)做消息推送服務(wù)器，單臺(tái)服務(wù)器的連接能力大約在2萬(wàn)到10萬(wàn)之間，如果要保證穩(wěn)定的服務(wù)能力，客戶端的連接數(shù)通常不允許超過(guò)5萬(wàn)。IBM的MessageSight可以支持100萬(wàn)的客戶端連接。但不論其數(shù)值多少，單臺(tái)服務(wù)器的處理能力總有極限。

如果要推送的設(shè)備數(shù)量超過(guò)了單臺(tái)的處理能力，就需要考慮服務(wù)端集群。MQTT在服務(wù)端的集群擴(kuò)展方面沒(méi)有規(guī)定，需要自行設(shè)計(jì)實(shí)現(xiàn)水平擴(kuò)展架構(gòu)。