MQTT(使用mosquitto作broker)作Android推送部分总结

“读万卷书，行万里路”。我以为这句话用在程序员的工做中就是：在网络中找一万篇资料，在实践中作一万种尝试。

<hr> **2014-09-17：** **在本文中，因为做者事先不了解，设计不合理，使每一个设备采用prefix+CLIENT_ID的方式做为topic，致使须要给每一个设备的topic单独推送，才产生了一些问题，特别是推送的时间上的问题，是PHP循环往每一个topic写入消息的时间。但愿读者不要被我误导。** **给每一个设备一个topic，实际上只在作点对点的推送的时候须要，若是没有这个需求，好比全局的推送，或者是几个大类的推送，彻底能够设计一个更合理的topic规则，把主要的精力放在client和broker的维护上。** <hr>

###1. 基础建设： 纸上得来终觉浅 绝知此事要躬行

1. 理论支撑 ：使用MQTT做为Android实现方案的缘由源于一篇四年前的文章：How to Implement Push Notifications for Android；
2. 与Web管理的对接 ： 文章的做者同时也提供了PHP端的Client方案：PhpMQTTClient。
3. 服务端 ： 固然，这只是Web端的实现方案，至于后端须要使用的Broker，咱们找到了mosquitto。
4. 客户端 ： 在客户端中，咱们使用的是来自IBM的wmqtt.jar的包：wmqtt

以上四个基本条件是咱们具有了部署基于MQTT协议的Android的推送服务的基本条件。在最初的测试中，也没有遇到过太大的问题，测试顺利，因而咱们在咱们的应用和服务器之间部署了这套解决方案。

###2. 从0到1的变化： 千里之行，始于足下

因为事先并无作推送的经验，在实际实施的过程当中咱们明白的几个基础的概念：

1. MQTT协议是一个即时通信协议，推送实际上用到的只是它能够publish内容给topic的功能。
2. 为了保证客户端可以实时的收到推送消息，即便是程序退出，客户端用于接收消息的service也须要处于保持状态。
3. 客户端与Broker、Broker和Web端的都是socket通讯，推送的过程是用于Web端的client发布一个消息到Broker，Broker再将消息发送给当前其它链接到Broker的Client。因此能及时收到消息的只是如今和Broker保持链接状态的设备。
4. 服务端须要维护一个设备id列表，这个列表中的id必须都是惟一的（在前期，咱们选择使用Android ID，这也带来了不少麻烦）。

基于以上几点，咱们也能够发现如下的问题：

1. 不是全部的设备都可以及时的获取到推送的内容。
2. 客户端的service随时会有被各类安全软件干掉的风险。

经过前期的调研咱们也发现，这些问题也是其它的第三方推送服务也都会遇到的问题。只要迈出第一步，让服务先work起来，其它的问题后续来优化。

###3. 从1到1万： 不积硅步，无以至千里

这个阶段主要是丰富推送的功能，解决一些前表面上的问题，咱们作了如下的调整：

1. 在设备量到10000的时候，遇到了一个问题：推送10000个设备时间过长。这个问题很快获得了解决：这是因为没发送一个设备，都新建了一个从Web端到Broker的socket链接，这其实是没有必要的，只要socket不断开全部Publish的工做均可以经过一个socket进行（这和APNS有些不同的地方，在苹果的推送服务中，若是有一个设备id是无效的，整个推送都会断开），在前文提到过的Web端的库中，是有指定重连的操做的。

2. 丰富推送的内容。虽然推送的内容都是文本，可是文本的解析倒是客户端维持的service来进行的，因此经过推送json的方式，实现了分别推送新闻、天气等富文本信息，并能够经过点击跳转到不一样的页面。

3. 分地区推送的需求，这个实现方式通过一些迭代，最先是经过用户注册地来实现的，后来改成了用户安装应用时上报的地区的方式。

###4. 从1万到10万，必须作出的改变： 行百里者半于九十

数据量到达10万的时候，一些问题也逐渐凸显。

1. Android ID重复的问题 ：
   从网上查询来的资料，大部分都是使用Android的系统参数ANDROID_ID来作推送的。然而实践代表，这个参数并非可靠的。生产环境中使用这个参数有极大的概率重复。因为一个相同的设备id链接到Broker的时候，以前的链接就会断开，这就会致使相同设备ID的设备只有一个会收到推送的消息。
   在续的改造过程当中，咱们将设备ID换成了本身生成的一套惟一随机的ID。

2. 错误的id字符 ：
   在查看MQTT的文档中，咱们只注意到了设备ID须要在1~23位之间，却并无注意到字符的限制。最初生成的id是base64的编码。在后面的测试中 ，老是发现推送到某些设备以后推送就断开了。通过检查发现，这是因为一些设备id中存在+符号致使的。
   在Topic中，+和#会被看成通配符处理，致使出现 Socket error 的错误。
   通过咨询，获得了如下的答案：

Roger Light (roger.light) said :
Are you saying that clients that have a client id with '+' in are rejected? This shouldn't happen. If you mean that clients are publishing to a topic with '+' in, then you are correct that this is not allowed.

3. 从Broker中获取有用的信息 ：
   生产环境中须要经过从Broker中获取一些有用的信息用于监控推送的状态。在Mosquitto的配置中，能够把log_type设定为all来记录所有的log。
   经过订阅Mosquitto的一个特定的Topic，能够获取到一些推送的统计信息：

mosquitto_sub -h 192.168.0.1 -p 1883 -t $SYS/broker/# -v

4. 对于不在线的设备的处理（消息持久化） ：
   IOS和Windows Phone的设备的推送服务因为是系统提供的服务，只要设备网络在线，都是能够及时收到消息的，对于Android的自建推送服务来讲，显然没法保证这一点。然而经过消息持久化的配置，也能够实现如下策略：
   • 应用处于打开状态，设备在线的时候，能够及时的收到消息
   • 应用退出、推送的Service在线的时候，能够收到推送消息
   • 应用和Service都被关闭，下次应用启动的时候，能够收到一天内的推送消息

<br>

基于以上的策略，能够在客户端和Broker之间配置消息持久化和订阅的持久化。配置过程当中须要在如下几个地方注意：  
1. Web端发送消息的时候，QoS设定为1  
2. Mosquitto的配置文件中，设定`persistence`为`true`  
3. 客户端`MQTT_CLEAN_START`(Clean session)为`false`，即不在服务启动时清理session，`MQTT_QUALITIES_OF_SERVICE`(QoS)与Web端保持一致;

5. 安全策略的控制 ：
   在Mosquitto的后端配置中，可使用限定客户端前缀，使用ACL权限控制，配置SSL链接的方式进行安全控制。

###5. 从10万到more，更多要作的事情... 路遥知马力

1. 推送时间的优化调整 ：
   实际环境中，一台4G内存，4核CPU的服务器，发送20万台设备的消息大概须要4分钟左右，推送服务器并无什么压力，这个时间取决于Web端将全部的消息Publish到Broker服务器的时间。能够经过多线程的方式进行优化。

2. 及时清理失效的设备id ：
   因为技术上的改造和迭代，一些设备ID在更新以后就不会再使用，服务端设定必定的策略来清理无效的设备ID能够减轻推送的压力。好比经过记录设备最后一次链接到Broker的时间，若是这个时间超出某个限制（一个月），就清理掉这个设备id。下次设备从新连入的时候还会再发送设备ID，这样即不会给服务器形成压力，也不会漏掉某些设备的推送。

3. 集群部署 ：
   Mosquitto支持集群部署的配置（Bridges），其原理也是将一个消息Puhlish到集群中的其它服务器，而后由其它服务器来发送。

A bridge is a way of connecting multiple MQTT brokers together.

5. 如何让客户端的service始终在线 ：
   参考：

在android中，service被杀死后在没有被系统/安全软件禁止的条件下是可以自启动的，具体可自行网上搜索“android service onstartcommand START_STICKY”

###6. Mosquitto的配置优化
部分配置：

<!-- lang: shell -->
allow_zero_length_clientid false
persistent_client_expiration 1d
max_connections -1
persistence true
log_type all
connection_messages false
allow_anonymous false

###7. 资源/资料收集

1. Apache的open source messaging and Integration Patterns server，ActiceMQ，使用java编写，使用与管理很方便，目前发现的问题是内存使用量较大：Apache ActiveMQ
2. Eclipse的客户端库：Eclipse Paho
3. MQTT v3.1协议规范：MQTT V3.1 Protocol Specification
4. Mosquitto文档：Mosquitto Documentation

###8. 附上一篇iOS推送部署总结 详情：http://xiaoler.github.io/blog/mobile/ios-push-apns-php-zendframework.html