基于商用多媒體云平臺的終端推送服務設計

王鈺， 葉徳建

(1. 復旦大學 軟件學院， 上海 201203； 2. 網絡信息安全審計與監控教育部工程研究中心， 上海 201203)

基于商用多媒體云平臺的終端推送服務設計

王鈺1， 葉徳建2

(1. 復旦大學 軟件學院， 上海 201203； 2. 網絡信息安全審計與監控教育部工程研究中心， 上海 201203)

從商用多媒體云平臺的業務需求出發，設計了一種終端推送服務。將推送流水的存儲、推送消息的發送和推送消息的確認分成3個不同的模塊分別完成，實現點對點推送，同時上層服務管理終端分組，保證了推送消息的可靠到達。實驗證明，該推送服務的內存占用穩定，推送效率高，吞吐量高，能滿足商用多媒體云平臺的點對點分組推送功能。

終端推送； 消息可靠到達； 點對點推送

0 引言

互聯網時代，消息推送服務[1]在我們身邊得到了廣泛的應用。推送服務指的是客戶端與服務器之間保持長連接心跳，服務器有新消息需要發送時，主動向客戶端推送信息，相比客戶端的定時請求服務，這種方式減少了交互次數，提高了推送效率。

近年來，在酒店VOD、校園OTT-TV、戶外廣告等行業中，以視頻業務和信息發布業務為主的商用多媒體系統的應用越來越廣泛。隨著云計算技術的發展，基于云平臺構建的商用多媒體系統成為了主流。

終端推送服務是商用多媒體云平臺[2]面向終端的重要服務，信息發布系統、OTT系統等均依靠該服務將廣告、節目單等信息推送到指定終端設備。在云平臺的終端推送[3]方面，運營商往往需要向不同的終端推送不同的內容,例如商場的信息發布系統可在多個屏幕展示不同的產品介紹，推送內容大多是運營商需要發布的重要信息，不允許信息丟失。

文獻[1]中采用Netty框架開發，對傳統網絡服務器采用的阻塞IO開發引起的大量客戶情況下推送服務中CPU利用效率低下的問題，但是并沒有解決推送服務中信息丟失的問題。文獻[4]是多媒體終端推送業務功能的研究，但未能解決商用多媒體云平臺推送服務的點對點推送需求。

目前可用的推送技術主要基于MQTT[5]或XMPP協議，二者均使用長連接實現推送。

MQTT協議，是一個輕量級的基于“發布/訂閱”模式的消息傳輸協議，協議開放，擴展性強，提供一對多的消息發布，適用于帶寬比較低或者不穩定的網絡環境。

XMPP[6]協議，是用于實時通信的協議，通信報文格式基于XML，實時通信技術和推送的底層技術是一樣的。該協議可實現點對點推送，但其基于XML的通信報文數據傳輸量較大，為實時通信而設計的XMPP對于推送冗余功能過多。在商用多媒體系統中，各種云服務之間的業務數據需要互相關聯，而XMPP服務器的集群部署模式下只支持單一數據庫，無法分庫分表，數據相對封閉。在XMPP協議中，各服務器不存儲在線消息的發送流水，當在線功能由于異常(如服務器負載過高或突然故障)導致發送失敗時，缺乏容錯機制，無法保證消息的可靠到達。

綜上，MQTT協議需要為每個終端分配唯一的Topic來實現點對點推送，管理不便，XMPP協議可用于點對點推送，但協議內容冗余，傳輸的數據量大，數據模型相對封閉，消息容易丟失。所以，它們均不適用于商用多媒體云平臺的終端推送服務。商用多媒體云平臺終端推送服務的需求是：實現點對點推送，終端推送服務本身不管理終端分組，上層服務基于點對點推送可以方便實現分組管理及分組發送；保證推送消息至少成功到達終端一次。基于此需求，我們針對該商用多媒體云平臺設計一個定制的推送協議，基于Exchange ActiveSync[7]協議改進。

1 背 景

1.1 可靠消息隊列RocketMQ

RocketMQ是一款分布式消息中間件，基于消息隊列模式，持久化存儲隊列，消息順序可靠，實時消息訂閱，具有高可靠、高性能、易擴展的特點。

RocketMQ分為NameServer和Broker兩部分，NameServer存儲了消息隊列中所有的配置信息，Broker則負責消息的存儲轉發。RocketMQ使用“Topic/Queue”的模型，一個Topic是多個隊列的集合，平均部署在多個Broker上，增加Broker數量就可以直接提高吞吐量，易擴展的同時實現負載均衡。每個Broker分為Master節點和Slave節點，Master負責接收、存儲和投遞消息，Slave則負責進行冗余備份，從而提升可靠性。生產者和Broker之間保持心跳連接，從而在某個Broker故障時，自動選擇其他Broker發送消息，消費者從該Broker的Slave節點繼續接收消息，提高可用性。RocketMQ采用高并發的方式提高吞吐量，消息消費失敗不會阻塞后續消息的投遞，性能很高但不保證消息嚴格有序。

1.2 Java的Netty框架

Netty[8]是基于Java非阻塞IO的網絡編程框架，該框架將非阻塞IO與IO復用結合起來，具有較高的網絡傳輸效率，同時還提供了基于事件響應和回調方法的異步編程模型，是目前主流的Java網絡編程框架。使用Netty框架可以極大簡化選擇器監聽、連接創建、心跳處理、連接異常處理等各個環節的開發工作。

1.3 Memcache緩存

Memcache[9]是開源的基于一致哈希的分布式鍵值系統，數據全部存儲于內存中，常用作系統緩存，讀寫速度快，當節點故障時，相鄰節點的替代提高了其可用性。

2 設 計

2.1 架構設計

終端推送服務要保證推送消息可靠到達終端，需要在異常情況下對丟失的推送消息進行記錄并重試，因此終端推送需要存儲所有的推送發送流水，終端在收到推送消息之后要反饋確認，從而確定丟失的推送。但是若在發送推送過程中存儲發送流水，則會降低終端推送的吞吐量。本文在終端推送服務的設計中，將推送流水的存儲、推送消息的發送和推送消息的確認分成3個不同的模塊分別完成，從而將3部分操作解耦。在3個模塊中，可以調節部署的服務器數量來維持系統整體吞吐量的平衡。

終端推送服務的整體架構，如圖1所示。

整體架構分為3部分：

門戶模塊(Facade模塊)：接收來自其他服務的推送請求，通知相應的broker模塊發送推送消息，保存和維護終端推送服務的狀態(終端與Broker之間的映射關系、終端在線狀態等)，保存推送消息的發送流水；

圖1 終端推送服務的整體架構

推送模塊(Broker模塊)：接收來自Facade模塊的請求，將推送消息發送給指定終端；

消息確認模塊：接收來自終端的確認消息，更新推送消息發送流水的狀態；

3個模塊的職責及維護的數據，如表1所示。

表1 推送服務各模塊的職責

其中，每臺Broker服務器都存儲了終端MAC地址和終端Channel連接之間的映射關系，這部分數據只存儲在內存中。Facade模塊在終端上下線時接收終端發來的RocketMQ消息，之后對終端與Broker模塊中各服務器的映射關系進行修改和保存。此處采用異步的RocketMQ消息，其他云服務也可以訂閱終端上下線的該消息，例如：云平臺的運營服務可以通過訂閱各個終端的上下線消息來計算終端的活躍時間。Facade模塊還負責接收分布式定時任務的通知，查詢發送失敗的推送消息流水，通過不斷重試進行異步補償，直至推送消息被確認。

2.2 協議設計

推送協議，如表2所示。

該推送協議設計十分精簡，共有4種指令：login指令是終端在發起長連接時，發送給推送服務的第一條指令，攜帶終端在開機認證過程中生成的token等信息，推送服務可以調用終端的管理認證服務驗證合法性，如果認證失敗或者連接建立后未發送login指令，則推送服務關閉連接，認證成功則云平臺通過推送服務返回認證結果給終端；heart指令用于維護終端和云平臺之間的推送服務的長連接，如果任何一方在一定時間內未收到心跳則主動關閉連接，終端開始重連；push指令是在長連接中發送給終端的指令，執行推送操作，該指令包含終端MAC地址、推送消息內容體等；ack指令是終端在收到push指令之后回復給推送服務的確認命令，推送服務在收到ack指令之后記錄相應終端的push消息為到達狀態。

表2 推送協議

整體協議由長連接和HTTP兩部分組成，通過長連接來發送推送消息的內容，通過HTTP來確認推送消息的到達。這種設計極大地降低了長連接管理方面的難度，管理長連接的服務器不需要記錄推送消息是否到達，提高了推送效率。對于未收到確認的推送消息，由分布式定時任務異步補償不斷重試直到確認為止。

2.3 終端、Broker模塊及Facade模塊之間的交互

Broker模塊使用Java的Netty框架實現，Netty框架將網絡套接字封裝成Channel類型，后文將使用Channel表示非阻塞的Socket連接。

終端/二級服務器在上/下線時與Broker模塊之間的交互順序，如圖2所示。

圖2 終端與Broker模塊的交互

終端通過與Broker模塊的連接進行登錄，完成登錄認證的初始化階段。

終端與Broker模塊建立連接之后，先發送攜帶Token的login指令，Broker模塊收到指令后調用終端認證服務檢測Token的合法性，并返回認證結果，認證成功則返回Token對應終端的MAC地址。認證通過后，broker模塊將終端MAC地址和Channel的映射關系保存在內存中，之后broker模塊發送RocketMQ消息通知Facade終端上線，Facade模塊記錄并保存終端和Broker模塊服務器的映射，RocketMQ消息內容為“[online]終端MAC地址+Broker模塊服務器IP+時間戳”。Broker模塊和終端之間始終保持心跳交互，一方超過指定時間未收到心跳包，broker模塊將主動關閉終端對應的Channel，如果Channel在認證成功后被關閉，broker模塊會將MAC地址和Channel的映射關系中刪除對應的數據，并發送RocketMQ消息通知Facade該終端下線，該消息和上線時發送的內容類似。

Facade與Broker模塊之間的交互，如圖3所示。

圖3 Facade模塊和Broker模塊的交互

Facade模塊同樣作為Broker模塊的客戶端進行登錄認證，與終端不同，Facade模塊登錄時使用特殊的Token——字符串facade，Broker模塊檢測到該Token之后，對登錄者的IP進行驗證，Facade模塊的IP地址應為內網IP，Broker模塊檢測出是內網IP則返回登錄成功，否則返回登錄失敗。當Facade模塊收到來自其他服務的推送調用請求時，查找終端對應的Broker模塊，發送push指令給對應的Broker服務器，Broker模塊在終端MAC地址和Channel的映射關系中查找到對應Channel并將push指令發送給終端。Facade模塊和Broker模塊之間也要維持心跳交互，如果二者之間的連接被關閉，Facade模塊將不斷重試連接直至成功。

2.4 Broker模塊

Broker模塊有幾個關鍵工作。在收到客戶端發來的報文時，首先判斷發過來的指令是否為login指令，根據協議規定，客戶端建立連接之后，發送的第一條必須是login指令，因此對于非login指令，處理器將關閉channel。然后，檢測login指令的Token是否為字符串facade，從而區分客戶端類型為終端設備或Facade模塊的服務器。對于來自內部的Facade模塊連接請求，通過客戶端IP地址是否為內網進行認證，后對Channel做標記。對于來自外部終端設備的連接請求，Broker模塊將調用終端認證服務檢測該終端合法性，認證通過后，發送RocketMQ消息通知Facade模塊終端上線，同時保存該MAC地址和Channel之間的映射關系，并注冊Channel關閉事件的回調方法。當Channel被關閉時，將該Channel和MAC地址的映射關系刪除并給Facade發送終端下線的RocketMQ消息，最后將Channel標記為外部連接并記錄終端的MAC地址。以上的認證操作只在連接新建立的時候執行一次，之后通過這個Channel進行后續操作時，無需認證操作，但是Broker與客戶端之間要維持心跳交互。

Broker模塊在收到push指令時，檢查是否由Facade模塊發出和指令的正確性。然后Broker模塊根據該指令中的指定的終端MAC地址查找到對應的Channel，將push指令從該Channel轉發出去，如果在轉發push指令的過程中發生任何異常，例如終端MAC地址對應的Channel不存在，Broker模塊將簡單地丟棄消息，后續由分布式定時任務進行異步補償。

2.5 Facade模塊

Broker模塊的輕量型設計使得我們的推送系統具有較高的性能，而Facade模塊需要處理較為重量級的工作：1) 維護終端與Broker模塊服務器之間的映射關系；2) 存儲推送消息發送流水；3) 執行分布式定時任務，對發送失敗的push消息進行異步補償。

Facade模塊的數據庫需要保存終端與Broker模塊服務器之間的映射，同時存儲推送消息的發送流水，數據庫模型，如圖4所示。

圖4 Facade模塊的數據庫模型

其中MAC_BROKER表記錄了終端MAC地址與Broker模塊服務器之間的映射關系，終端MAC地址具有唯一性約束。Facade模塊在發送push消息時，為了查找終端對應的Broker模塊服務器，需要在MAC_BROKER表中進行大量的查詢操作。為了提高查詢效率，在Memcache集群中為該表建立Key-Value查詢緩存，Key為終端MAC地址。每次查詢先從緩存查詢，查詢不到再從數據庫查詢，并將結果寫入緩存；每次更新數據庫時對緩存進行更新，保持數據一致性。

MAC_MSG表記錄了Facade模塊對push消息的發送流水，終端MAC地址和Push消息ID聯合組成唯一性約束，表中STATUS字段表示push流水狀態：INIT表示未收到回復，ACK表示已收到回復。MSG表則為push消息的歷史記錄表。一定時間后通過定時任務將這段時間的MAC_MSG數據表遷移到歷史記錄表中，同時檢查push流水狀態，記錄并報告未收到回復的流水，但是將放棄重新推送該push消息。

外圍系統在調用終端推送服務時，需要在Facade模塊注冊push消息并獲得ID，然后向Facade模塊發送RocketMQ消息，內容包括push消息ID和終端MAC地址列表，在列表數量過多的情況下將拆分成多個RocketMQ消息發送給推送服務。

Facade模塊的推送服務流程，如圖5所示。

圖5 Facade模塊的流程圖

Facade模塊收到推送請求后，將push消息發送流水插入到數據庫MAC_MSG表中，同時由另一個消費者將發送流水向業務線程池提交push任務，由業務線程池異步執行push消息推送。RocketMQ消息中如果有push消息流水未插入成功，則返回失敗，RocketMQ將重新投遞失敗的消息，MAC_MSG表的唯一索引可以防止重復插入。業務線程池在MAC_BROKER表中查找當前push流水需要的Broker服務器IP，并通過Broker模塊的客戶端將push消息發送出去。

當Facade模塊收到終端上下線的RocketMQ消息時，要更新MAC_BROKER表和Memcache緩存中的MAC地址和服務器IP的映射關系。終端上線時，將表中Broker字段更新為真實IP，下線時更新為OFFLINE。并同步更新Memchache緩存，比較RocketMQ消息中的時間戳和數據庫記錄的時間戳大小，防止更新過期的RocketMQ消息。終端上線時，Facade模塊需要查詢該終端是否有未確認的push消息流水記錄，有則需要發送對應push消息到業務線程池。

由于Facade模塊的兩個消費者異步處理RocketMQ消息，一個負責落庫發送流水，一個負責封裝并提交push任務，若出現一條流水在落庫之前已經完成了推送操作，則直接在數據庫中插入該流水，并將該流水狀態記錄為ack。同一條流水多次發送的情況由客戶端自行處理。

對于終端未成功收到push消息的情況，通過分布式定時任務進行異步補償，執行頻率為每分鐘一次。Facade模塊將查詢MAC_MSG表中所有需要重發的push消息流水記錄。當流水狀態為INIT，終端處于在線狀態，流水的更新時間超過一分鐘這三個條件同時滿足時，從MSG表中將流水的push內容體封裝，并和push流水組裝成pushTask提交到Facade模塊的業務線程池，從而將push消息發送到終端。

3 應用與測試

商用多媒體平臺終端推送服務為了達到點對點推送、分組管理發送、準確到達等需求，定制設計成推送流水的存儲、推送消息的發送和推送消息的確認三個模塊，以下是該終端推送服務的相關測試。

3.1 Broker模塊的內存占用和推送效率測試

由于Broker模塊所在的服務器會與大量的終端建立長連接，因此對Broker模塊內存占用和連接數之間的關系進行了測試。在Clear商用多媒體云平臺環境下，用單臺虛擬機搭建了Broker模塊，用軟件模擬支持自定義推送協議的終端，記錄Broker服務器的內存隨著終端增加的變化。同時使用了相同的虛擬機搭建了常用的基于XMPP協議的開源Openfire[10]服務器，并用軟件模擬終端XMPP客戶端與服務器保持長連接，進行同樣的測試來對比。

測試結果發現，隨著終端數的增加，Broker模塊內存增長并不明顯，每個終端的連接平均消耗11.83KB內存；隨著終端數的增加，Openfire的內存占用明顯增高，平均每個連接占用146.2KB，是Broker的12倍。這是因為Openfire支持的XMPP協議較復雜，保存了很多無關數據，自帶Web管理界面，因此對內存消耗較大，而Broker模塊只維護連接的開銷及連接與終端的映射，得益于終端推送協議的精簡設計。

然后對Broker模塊的推送效率進行了測試，同樣以Openfire作為對比，共9000個終端，每個終端發送12條push消息，共計108000條push消息。對于Broker模塊，直接向其發送push指令，不使用Facade模塊是為了避免流水落庫對實驗結果的影響。對Openfire通過XMPP標準客戶端類庫Smack進行模擬，在推送過程中均沒有持久化存儲push消息的發送流水。如表3所示。

表3 Broker模塊推送效率測試結果

Broker模塊的平均吞吐量是Openfire的2.1倍，同時Broker模塊發送的push消息通過異步補償的方式確保無丟失，而Openfire的push消息到達率為93.77%，Openfire沒有相應的補償機制。

3.2 Facade模塊的吞吐量測試

Facade模塊負責接收推送請求，將push消息的發送流水落庫，并發送push給Broker模塊。Facade的吞吐量測試，如圖6所示。

圖6 Facade吞吐量測試

測試過程中共模擬3000個終端，向每個終端推送10條消息，實驗有兩次，第一次由單臺(Facade模塊的)虛擬機對外發送，第二次是由兩臺虛擬機組成的集群共同發送。

圖6中發現，單臺服務器的吞吐量為每秒872.1條，兩臺的綜合吞吐量為每秒1685.4條。在push消息的發送過程匯總，Facade模塊的吞吐量基本比較平滑，這是由于Facade模塊用了線程池異步提交的方式，對外暴露RocketMQ的消息接口，在推送請求的接收、push流水的落庫、發送push給Broker模塊這3個環節中全部異步化操作，可以緩解流量高峰，起到緩沖作用。

Facade模塊和Broker模塊在單臺服務器的吞吐量方面有較大的差距，這是由于Broker模塊精簡化，但Facade模塊需要與數據庫交互。在生產環境中，兩個模塊分開各自部署在集群中，需增加Facade模塊的集群數量以提高系統整體的吞吐量，實驗過程中發現Facade集群數與Broker集群數比值為5∶1較為合適。

4 總結

本文在設計終端推送服務的時候，結合商用多媒體云平臺的行業需求特征，將存儲發送流水、推送push消息和push消息確認3個環節異步解耦以提高吞吐量，主要解決了推送消息可靠到達的問題。

后續工作可以將推送服務進一步完善，提高吞吐量，在實驗中改進推送效率和資源消耗問題，嘗試將推送服務對其他云服務開放，提供更多分析數據，加強平臺的開放性建設。

[1] 代超,鄧中亮.基于Netty的面向移動終端的推送服務設計[J].軟件,2015,12:002.

[2] 吉亞云, 劉新, 葉德建. 商用多媒體信息發布系統持久層設計與優化[J]. 計算機工程, 2015, 41(1): 261-265.

[3] Gudla S K, Bose J, Sunkara S, et al. A unified push notifications service for mobile devices[C]//Electronics, Computing and Communication Technologies (CONECCT), 2015 IEEE International Conference. IEEE, 2015: 1-6.

[4] 蘇毅. 移動多媒體推送業務終端功能研究[D]. 北京：北京郵電大學, 2009.

[5] Thangavel D, Ma X, Valera A, et al. Performance evaluation of MQTT and CoAP via a common middleware[C]//Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP), 2014 IEEE Ninth International Conference. IEEE, 2014: 1-6.

[6] 汪海占, 邸萌, 黃祥林. 基于 XMPP 協議的 Android 消息推送設計與實現[J]. 科技廣場, 2015 (2): 40-46.

[7] Sinha A, Paul N, Devarajan S. Cloud based mobile device management systems and methods: U.S. Patent 9,060,239[P]. 2015-6-16.

[8] Maurer N, Wolfthal M. Netty in Action[M]. Manning Publications, 2016.

[9] Foong A, Hady F. Storage As Fast As Rest of the System[C]//Memory Workshop (IMW), 2016 IEEE 8th International. IEEE, 2016: 1-4.

[10] Sun M, Wang S, Fang Z, et al. Design of an Instant Messaging System Based on the IaaS Cloud Platform[J]. Journal of Communications, 2015, 10(9).

Design of Terminal Push Service Based on Commercial Multimedia Cloud

Wang Yu1, Ye Dejian2

(1. Software School, Fudan University, Shanghai 201203, China;2. Engineering Research Center of Cyber Security Auditing and Monitoring, Ministry of Education, Shanghai 201203, China)

In order to meet the business needs of commercial multimedia cloud platform, we design a new terminal push service which divides the push service into three parts, i.e. the storage of push record, the delivery of push message, and the confirm of the delivery. This terminal push service realizes point-to-point delivery, the management of terminal grouping of the upper service ensures the reliable arrival of the push message. According to the experiments, this terminal push service satisfies the point-to-point grouping push demands with high push efficiency, high throughput, and stable memory usage.

Terminal push service； Reliable arrival of message； Point-to-point delivery

王鈺(1993-)，女，江西，碩士研究生，研究方向：網絡多媒體。 葉德建(1976-)，男，浙江，副教授，研究方向：網絡多媒體。

1007-757X(2017)06-0045-05

TP311

A

2017.04.07)