小米11.11：海量数据压力下的推送服务

        作者 臧秀涛 

        11. 11 大促，随着移动端业务量的急剧提升，像小米推送这样的基础服务也经受了巨大的考验。11 月 12 日，小米的项目总监汪轩然在微博上宣布，“小米推送服务共发出 9.65 亿条消息，平均每分钟发送 67 万条。更值得一提的是，后台监控显示，推送服务后台系统在全天运作非常平稳，没有任何卡顿拥堵现象，让各种促销、返利、订单更新消息第一时间触达用户。”

        汪轩然，2007 年毕业于清华大学计算机系，后加入微软亚洲工程院，曾参与 WP7 上的浏览器的开发。2010 年 7 月加入小米，曾担任米聊安卓团队的团队主管，现在在小米任项目总监，负责小米的开发者服务，掌管推送服务、统计服务和移动广告联盟三大业务，旨在为小米搭 建一个移动 App 业务的互联网生态圈。

        我们联系了汪轩然，就小米推送服务的架构、特点、性能等问题对他进行了采访，以下内容根据本次采访整理而成。

        基础技术架构

        协议是推送服务的核心。小米推送服务所采用的协议是由之前的米聊演变过来的，而米聊从一开始就选择使用 XMPP 协议，之后开发团队对 XMPP 协议做过几轮精简和重构。现在 XMPP 部分只是作为一个数据的传输层，之上跑着各种独立的业务，每个业务称为一个“channel”；每个 channel 上跑的数据格式可以是不一样的。消息推送服务是其中一个 channel，这个 channel 上传输的数据是通过 Thrift 进行二进制化的协议格式。

        再来看一下小米推送服务的服务端架构。下图是后台服务端的一个基本架构图。整个服务端包含如下几层：

1. XMPP 前端：用于维护跟客户端之间的长连接，使用 EJabberd 项目来处理来自客户端的 XMPP 请求，同时通过 XMQ 模块来处理推送服务特有的 XMPP 消息协议。
2. 中间层：业务逻辑层，主要用于将消息请求异步化、创建和维护消息队列、以及处理客户端的一些命令请求（注册、设置别名、设置 topic 等）。
3. HTTP 前端：这一层负责对接来自第三方 App 的服务器的发消息的 HTTPS 请求，以及来自客户端生成账号的 HTTPS 请求。

        再就是数据存储，这里采用了小米的统一 HBase 存储，同时还使用 MySQL 来保存一些量不大，但需要复杂过滤条件的数据（topic 等），并且为了降低对 HBase 的压力，中间还加了一层 Redis 作为缓存。

        最后看一下客户端架构。客户端 SDK 主要包含两个层次：SDK 层和 PushService 层。前者提供了面向 App 接入的接口、回调方法以及对 Thrift 的数据进行反序列化的处理逻辑；后者用于维护 XMPP 长连接和收发消息。两层之间使用 Intent 方式来传输数据。值得一提的是，在 MIUI 系统上，PushService 层是系统共用的，即 MIUI 系统提供了一个统一的 PushService 管理模块，不需要每个应用单独启动自己的 PushService。

 

        功能实现

        小米推送服务支持单发和群发消息两种推送方式。单发消息支持针对 regID 和别名两种方式，regID 是小米推送服务后台根据设备标识 +appID+ 时间戳生成，为了减少设备碰撞概率，设备标识我们采用的依据是 imei+AndroidID+build 序列号。别名是 App 在客户端设置上报的，便于应用将自己的设备/用户标识符同我们的 regID 作关联，这样 App 就不需要在后台维护 regID 跟设备/用户的对应关系了。群发消息采用打标签的方式来区分，客户端和服务端都可以给指定设备设置标签，发消息的时候，只需选取指定标签发送即可，小米推 送后台会将标签所对应的设备展开。一个标签支持的设备数无上限。

        那小米推送服务的稳定性是如何保证的呢？小米推送服务采用多机房方案，平时流量均摊，一旦某个机房出现故障，流量无缝切换到其它机房，并且单个机房的容量能保证提供无损服务。目前是双机房部署，预计明年会扩展第三个机房。

        安全性也是小米推送服务重点考虑的一个因素。数据传输过程中，得益于推送服务采用的双层协议方案，消息会采 取双重加密，第一重是 XMPP 传输层，保证数据在网络传输的过程中不会被篡改、监听。第二重是在 Thrift 二进制层，用以保证消息到达 Service 之后，通过 broadcast 发送给 App 进程的过程中不会被截获和伪造。第二重加密往往会被其它第三方推送服务忽略，但其风险同样很大。

        性能指标

        11. 11 大促，所面对的请求量是在小米推送服务的设计容量之内的，目前设计和机器规模可以支持峰值每分钟 1000 万条消息；平时业务量至少每分钟 40 万，峰值每分钟 600 万条消息。

        推送消息量平时波动很大，所以开发团队准备着流量随时可能忽增 200% 的情况，并在线下做好压力测试和优化；如果流量特别大，还有以下应对措施    

1. 异步排队处理，此时消息送达时间可能会比平时稍慢，但不会对整个系统有太大冲击；
2. 消息有优先级，广播消息会以低优先级处理；
3. 限流，控制开发者发送消息的频率；
4. 扩容，如果机器负载过高或者某个服务有瓶颈，可以很快速地增加机器，部署服务，增强系统处理能力。

        小米推送服务所经历的重构

        软件系统在开发和演进过程中，经常会经历较大规模的重构。小米推送服务有两次比较大的重构。

        一是开发语言从 Erlang 转为 Java。 小米原来的消息系统是使用 Erlang 开发的，所以推送系统的第一版也是基于 Erlang；但是 Erlang 的社区不够活跃，开发人员很难找，学习曲线陡，支持工具和类库少，所以后来开发团队选择了使用 Java 重新开发；迁移到 Java 后，对开发人员的要求降低，各种工具和类库较多，大大提高了开发效率。

        二是无处不在的 Cache。客户端使用小米推送服务的 SDK，开发者使用 API 的情况千变万化，很多场景是意料之外的；需要对调用频繁的业务添加 Cache，尽可能在本地进程内处理；例如，对于客户端调用 API 设置别名和订阅 topic，先检查 Cache 是否已经设置过，只有没有设置才往后端服务发送；优化后，后台服务的业务压力大大减少。

        在开发小米推送过程中的一些感悟        

1. 服务要支持水平扩展，尽可能实现为无状态，或者使用一致性哈希进行划分；方便扩容，可以保证即使系统暂时有性能瓶颈也能通过加机器解决。
2. 监控先行，能够很方便地采集、分析服务器的负载和业务的请求量、percentile、slow log，能够清楚了解到系统的瓶颈，有针对性地改进。
3. 不要过早优化，先实现功能并尽快上线，根据监控数据对关键地方进行优化。
4. 敏捷开发，快速迭代，日拱一卒，每天都有简短的站立会议，能够迅速响应变化，持续改进系统。