小米海量数据推送服务技术讲解
11.11大促在即，随着移动端业务量的急剧提升，像小米推送这样的基础服务也经受了巨大的考验。去年的11月12日，小米的项目总监汪轩然在微博上宣布，“小米推送服务共发出9.65亿条消息，平均每分钟发送67万条。更值得一提的是，后台监控显示，推送服务后台系统在全天运作非常平稳，没有任何卡顿拥堵现象，让各种促销、返利、订单更新消息第一时间触达用户。”
基础技术架构
协议是推送服务的核心。小米推送服务所采用的协议是由之前的米聊演变过来的，而米聊从一开始就选择使用XMPP协议，之后开发团队对XMPP协议做过几轮精简和重构。现在XMPP部分只是作为一个数据的传输层，之上跑着各种独立的业务，每个业务称为一个“channel”；每个channel上跑的数据格式可以是不一样的。消息推送服务是其中一个channel，这个channel上传输的数据是通过Thrift进行二进制化的协议格式。
再来看一下小米推送服务的服务端架构。整个服务端包含如下几层：
XMPP前端：用于维护跟客户端之间的长连接，使用EJabberd项目来处理来自客户端的XMPP请求，同时通过XMQ模块来处理推送服务特有的XMPP消息协议。
中间层：业务逻辑层，主要用于将消息请求异步化、创建和维护消息队列、以及处理客户端的一些命令请求（注册、设置别名、设置topic等）。
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%的情况，并在线下做好压力测试和优化；如果流量特别大，还有以下应对措施：
异步排队处理，此时消息送达时间可能会比平时稍慢，但不会对整个系统有太大冲击；
消息有优先级，广播消息会以低优先级处理；
限流，控制开发者发送消息的频率；
扩容，如果机器负载过高或者某个服务有瓶颈，可以很快速地增加机器，部署服务，增强系统处理能力。
小米推送服务所经历的重构
软件系统在开发和演进过程中，经常会经历较大规模的重构。小米推送服务有两次比较大的重构。
一是开发语言从Erlang 转为Java。 小米原来的消息系统是使用Erlang开发的，所以推送系统的第一版也是基于Erlang；但是Erlang的社区不够活跃，开发人员很难找，学习曲线陡，支持工具和类库少，所以后来开发团队选择了使用Java重新开发；迁移到Java后，对开发人员的要求降低，各种工具和类库较多，大大提高了开发效率。
二是无处不在的Cache。客户端使用小米推送服务的SDK，开发者使用API的情况千变万化，很多场景是意料之外的；需要对调用频繁的业务添加Cache，尽可能在本地进程内处理；例如，对于客户端调用API设置别名和订阅topic，先检查Cache是否已经设置过，只有没有设置才往后端服务发送；优化后，后台服务的业务压力大大减少。
总结
1.服务要支持水平扩展，尽可能实现为无状态，或者使用一致性哈希进行划分；方便扩容，可以保证即使系统暂时有性能瓶颈也能通过加机器解决。
2.监控先行，能够很方便地采集、分析服务器的负载和业务的请求量、percentile、slow log，能够清楚了解到系统的瓶颈，有针对性地改进。
3.不要过早优化，先实现功能并尽快上线，根据监控数据对关键地方进行优化。
4.敏捷开发，快速迭代，日拱一卒，每天都有简短的站立会议，能够迅速响应变化，持续改进系统。
今日推荐学习技术
在这里部落告诉大家一个小秘密
今晚8：30
动脑学院 Mark老师
将在腾讯课堂 动脑学院 免费Java公开课中
给大家详细讲解
《股票、实时新闻、弹幕-服务器推送技术》
你只需要在今晚8：30的时候
点击文章最末 阅读原文
即可进行观看学习
推荐阅读
▼
高并发与分布式系统的基石--数据库读写分离实战
这就是学编程的下场...
论程序员与产品经理是怎么互掐起来的
如何假装成为一名好的程序员
来自部落的邀请
Java框架 Spring 核心机制
至程序员的情书
Java高级部落送你ofo小黄车60天免费骑行，还不来？
Facebook研发的Cassandra你用过吗？
给 Java开发者的10个大数据工具和框架
推荐程序员必备微信号
▼