前言

在遊戲生態中，主要包含遊戲的研發方以及運營發行方。一款遊戲的運行，分爲研發和運營兩個階段。研發的主體有個人、獨立工作室、遊戲研發公司等；

遊戲的研發主體專注於遊戲內容的研發，對遊戲的發行及運營往往在人力、財力上投入不足，促使遊戲發行及運營業務應運而生，產生了獨立的運營發行方。目前市場上很多大型遊戲廠商將自己的發行及運營能力打包給運營發行方。另外還有一些遊戲的分發渠道方，依託於自己的流量優勢，也提供僅針對本渠道的聯合運營服務。

上圖中有關的交互的部分：

l 遊戲本身的操控交互是在遊戲客戶端與遊戲服務端間進行的，大部分會採用Socket長鏈接的方式進行通信。
l 遊戲客戶端與遊戲發行方平臺的交互，包括登錄，支付等等，這些由遊戲玩家主動請求的會採用http的方式進行鏈接通信。

這兩部分的交互選型相對固定。
但在運營發行方中關於運營消息以及廣告推送等場景，例如各類服務器運維升級等跑馬燈信息；賬號踢下線信息；懸浮窗廣告；普通消息推送等等服務更多是由遊戲的運營發行方主動推送的。在百萬級遊戲客戶的情況下，如何選擇更適合的交互方式是一件頭痛的事情。

我們在本章中探討如何更好地選擇運營發行消息的技術實現。

運營發行方推送的特點與要求

1．觸達用戶多：一款成功的遊戲總客戶數經常超百萬千萬。同時在線數高。
2．消息的時效性不同：有些消息是在某時間段內都生效的（例如主遊戲服運維升級通知），無論客戶當前的狀態是否在線，如果當前客戶在線那麼就立刻收到，離線的客戶在下次進入遊戲時也會收到相應的消息。有些消息是對於當前在線的客戶（例如賬號踢下線信息）纔有意義。
3．精準的羣發性訴求：推送的消息都是對於具有某類特徵的客戶羣體進行廣播（例如不同的廣告對應不同等級的遊戲玩家）
4．連接的輕量級消耗：這類數據的交互對比遊戲本身操控來說，頻率較低，所以遊戲客戶端與廣告運營等數據推送的流量佔用的客戶端運行資源儘可能的少。
5． SDK依賴資源簡潔：在遊戲領域裏，由研發團隊會產生遊戲母包，而運營發行方會在母包的基礎上嵌入運營所需要的SDK包，例如支付功能, 數據推送功能；那麼對於推送功能本身所依賴的資源包就越小越好了。

備選的技術方案分析

1.http輪詢方案：
優點：
遊戲客戶端依賴最少，實現方便。
缺點：
無效輪詢佔比高：多個客戶端，多種類的輪詢多，鑑於本類消息的頻率不高，那麼絕大部分輪詢都是沒有實際業務意義的。
運營端實現複雜：需要使用額外的代碼邏輯專門維護已讀取狀態。
資源佔用高：周邊配套的調用鏈，日誌信息，併發處理能力這些推高了資源佔用情況。

2.Socket方案：
優點：
遊戲客戶端依賴比較少，實現方便。
缺點：
連接維護：運營方會有不同種類型的應用劃分（例如廣告可能是單獨的應用，系統管理也會是另一單獨的應用），如果都需要推送，那麼就必須有不同的socket連接到不同類型的應用；這樣遊戲客戶端的連接就會增多，從而佔用比較多的資源。
運營端實現複雜：需要使用額外的代碼邏輯專門維護訂閱推送類型，在推送過程中需要代碼實現過濾，精準投遞到目標羣體； 爲了保證推送的質量（到達與否），需要額外記錄推送狀態；對於推送數據的時效需要額外的控制，有些過期的消息（例如服務運維時間通知）。

3.KAFKA方案：
優點：
接入簡單：成熟的消息中間件，支持各種實現語言。只需要對接Kafka 節點本身，不需要直接與發行方的應用進行連接，天然解耦。
功能強大： 推送數據的狀態維護，存儲等都可以借用Kafka的來提供。
缺點：
客戶端連接數支持不足，無法通過簡單的集羣來支持數量衆多的遊戲玩家（客戶端）。

4.MQTT方案：
優點：
接入簡單，MQTT的協議非常簡潔，支持各種實現語言。
支持各種訂閱關係。
支持p2p消息。
支持各種消息觸達的QoS質量。
可觀測客戶端的連接情況。
支持百萬級的連接。
缺點：
MQTT技術當前階段不如其它方案大衆。

MQTT技術方案

通過對比，上面的三種方案， MQTT方案是非常符合作爲遊戲的運營發行方與遊戲客戶端進行推送數據的交互場景。那麼我們來看看這個技術的設計原則。

1、輕量級與高效的微消息，MQTT協議精簡，消息頭特別簡單；
2、基於發佈/訂閱（Pub/Sub）通訊模式，可以進行雙向通信；
3、支持topic進行消息存儲落盤；
4、支持訂閱關係設定；支持p2p的模式與廣播模式；
5、支持百萬級別的連接設備；
6、提供消息服務質量管理；
7、適用於低帶寬、高延遲、不穩定的網絡；

這裏，我們比較一下阿里雲的產品微消息隊列MQTT與開源MQTT。

結語

在遊戲發佈運營平臺中，使用阿里雲微消息隊列MQTT產品可以滿足運營平臺與遊戲客戶端間的數據推送服務場景，即既保證了百萬級連接，又實現了資源佔用少，也能做到各種複雜的消息數據發佈訂閱管控。

本文爲阿里雲原創內容，未經允許不得轉載。