MQTT在游戏运营发行中的实践

前言

在游戏生态中，主要包含游戏的研发方以及运营发行方。一款游戏的运行，分为研发和运营两个阶段。研发的主体有个人、独立工作室、游戏研发公司等；

游戏的研发主体专注于游戏内容的研发，对游戏的发行及运营往往在人力、财力上投入不足，促使游戏发行及运营业务应运而生，产生了独立的运营发行方。目前市场上很多大型游戏厂商将自己的发行及运营能力打包给运营发行方。另外还有一些游戏的分发渠道方，依托于自己的流量优势，也提供仅针对本渠道的联合运营服务。

上图中有关的交互的部分：

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。