通过这些内容，读者将能够加深对 ">WebSphere MQ 与 MQTT 的理解，从而可以在实际客户应用场景中进行使用。消息推送作为移动开发的重要技术，应用开发者可以通过它对用户发送推送通知、活动提示，对用户进行提醒，
改善用户体验。消息推送可以是一对一的，比如银行向客户发送还款通知，应用发送业务提醒；消息推送也可以是一对多的，比如商家可以通过它向订阅的用户发布广告消息，或新闻机构向它的读者发送调查问卷等。
WebSphere MQ Telemetry 支持轻量级的 MQTT 协议，该协议支持发布／预定的消息传送方式，通过它可以很容易实现上面提到两种消息应用场景。具体实现时，订阅者只需要关注特定的主题，当有发送者向服务器的该主题发送消息，订阅者可以收到该消息，这里的订阅者可以是一个或者多个。这种通信方式有很大的应用价值，也是 MQTT 的其中一个关键的价值：快速轻量及时的完成消息的一对多发送。
根据 WebSphere MQ Telemetry 的部署经验，为了支持更多的终端设备连接和在发布／预定中表现出更好的性能，需要对 WebSphere MQ 进行一定的参数配置。本文参考了官方的性能报告配置建议结合使用经验，给出一些调节心得，然后使用两个场景，即订阅场景（“少发布者，多订阅者”）和发布场景（“多发布者，少订阅者”）进行测试和监控，得出一种调整方法，供大家对 WebSphere MQ Telemetry 配置时参考。
MQTT 简介
WebSphere MQ Telemetry Transport (MQTT，消息队列遥测传输 ) 是 IBM 为物联网而设计开发的一个即时通讯协议，它是一种开放、精简、轻量级和容易实现的协议，并有可能成为物联网的重要组成部分。
在物联网中，MQTT 协议与相关产品负责把数据由传感器有效的传送到服务器，完成在受限、不稳定网络到因特网或企业网络的连接，实现两者互联互通。在此基础上，互通的物品不仅能通过设备采集信息、实现智能的感知，更能结合先进的信息处理、数据挖掘、人工智能等技术手段，与业务应用整合，实现从后台到前端设备的智能监控，完成进一步的信息化工作。
归根结底，MQTT 协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性：
非常小的通信开销（最小的消息
大小为 2 字节）； 支持各种流行编程语言（包括 C，Java，Ruby，Python 等等）且易于使用的客户端； 支持“发布 / 预定”模型，简化应用程序的开发； 提供三种不同消息发布服务质量，让消息能按需到达目的地，适应在不稳定网络情况下的传输需求。 “至多一次”，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。如环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。 “至少一次”，确保消息到达，但消息重复可能会发生。 “只有一次”，确保消息到达且只到达一次。如在计费系统中，消息重复或丢失会导致不正确的结果。
测试场景概述
在本文中，我们对 MQTT 的两个应用场景进行了性能测试与调优，即订阅场景（“少发布者，多订阅者”）和发布场景（“多发布者，少订阅者”）。订阅场景与发布场景是用户在实际使用 MQTT 时经常用到的经典场景。有些用户也在此场景下进行改进以适应不同的现实需求，例如构建集群进行分流，增加高可靠性支持等。图 1 与图 2 具体描述了这两个场景。
图 1. 订阅场景：“少发布者，多订阅者”
在订阅场景中，多个 subscriber 同时订阅了主题“TestTopic”，当 Publisher 向主题“TestTopic”发布一条消息时，所有的 subscriber 都将收到这条消息。
图 2. 发布场景：“多发布者，少订阅者”
在发布场景中，多个 publisher 同时向主题“TestTopic”发送消息，subscriber 将收到所有 publisher 发送到该主题上的所有消息并进行后续处理，例如将消息打印出来或者存储到本地文件用于统计计算。
测试用例
为了使 WebSphere MQ 及 MQTT 达到最大的性能，我们需要考虑以下几个对性能产生重大影响的方面：消息大小，消息发布服务质量，消息总数，网络带宽和 MQTT 客户端数量。
消息大小
MQTT 只需要非常小的通信开销（固定长度的头部是 2 字节），所以在传输比较小的消息时 MQTT 是非常具有优势性的。消息的大小对性能有很大的影响，通常我们建议用户传输小于 4MB 的消息。在消息大小很大的情况下，如果网络环境不稳定，经常发生断线重传，则会引起网络拥塞，影响性能。
消息发布服务质量（QoS）
有三种消息发布服务质量，即 QoS 为 0,1 或 2：
QoS=0：“至多一次”，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。
QoS=1：“至少一次”，确保消息到达，但消息重复可能会发生。
QoS=2：“只有一次”，确保消息到达且只到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。
消息总数
短时间内消息总数越大对网络的压力就越大。通过增大消息总数，可以观察在网络条件一定的情况下，消息总数和 MQTT 吞吐量之间的关系。
网络带宽
网络带宽在 MQ 及 MQTT 进行消息传递时对性能的影响显而易见，在此就不再赘述。本文阐述的是 MQ 及 MQTT 的性能测试及调优方法，测试中的数据仅供参考，官方数据请见 MQTT 性能测试报告。
MQTT 客户端数量
在实际应用中，MQTT 客户端的数量通常是巨大的。在横向增加客户端数量的同时，观察 MQTT 服务吞吐量及响应时间的变化是必要的。由于 MQTT 使用的是发布订阅方式，在订阅场景中，增加 MQTT 客户端的数量会使吞吐量相应的线性增长，而响应时间变化不大。在发布场景中，随着发布者的增多，吞吐量会线性增加，而响应时间则被订阅者处理消息的速度所限制。
根据以上的参数变化，我们得到以下需要测试的用例。
表 1. 性能测试用例
测试场景 消息大小 QoS 消息总数 网络带宽 MQTT 客户端数量 订阅场景 32 bytes 2 10000 10G 500 订阅场景 256 bytes 2 10000 10G 500 订阅场景 256 bytes 1 5000 10G 500 订阅场景 256 bytes 0 20000 10G 1000 发布场景 32 bytes 2 10000 10G 500 发布场景 256 bytes 2 10000 10G 500 发布场景 256 bytes 1 5000 10G 500 发布场景 256 bytes 0 20000 10G 1000
测试环境准备
准备测试机器
我们在测试中使用 3 台机器，分别用来运行 WebSphere MQ，发布消息的应用程序和订阅消息的应用程序。三台机器之间通过万兆网相连。需要注意的是，在机器配置，网络环境，操作系统不同的情况下，性能测试的结果会有不同，同类环境才具有可比性。
图 3. 测试环境部署