MQTT基础——Part 2. 发布/订阅模式

114次阅读

共计 2927 个字符，预计需要花费 8 分钟才能阅读完成。

本节主要讲述发布 / 订阅模式。首先关注发布 / 订阅的基本特征，然后再聚焦到 MQTT 本身，着重讲述 MQTT 协议与传统消息队列协议的不同。

MQTT 基础——Part 1. 认识 MQTT http://www.linuxidc.com/Linux/2016-10/136408.htm

一、发布 / 订阅模式

发布 / 订阅模式即 Pub/Sub，是传统客户端 / 服务器模型（客户端直接连接服务器）的替代。传统的客户端 / 服务器模型是客户端直接连接到服务端（Endpoint），而发布 / 订阅模式实现了客户端的解耦。客户端（Publisher，消息发布者）发送特定的消息到另一个客户端（Subscriber，消息接收者）。这意味着发布者和订阅者都无需关心对方的存在与否。它们之间还有第三个组件，即消息经纪人（Broker），所有的发布者和接收者都要连接到消息经纪人，消息经纪人会过滤所有到来的消息，并根据需要分发这些消息。

发布 / 订阅模式实现了发布者和订阅者之间的解耦，可以从多维度进行区分：
1）空间解耦：发布者和订阅者均无需知道彼此的存在（比如对方的 IP 地址和端口）
2）时间解耦：发布者和订阅者无需同时运行
3）同步解耦：在发布或接收期间，双方组件的操作不会暂停
总的来说，发布 / 订阅模式从消息上对发布者和订阅者进行了解耦，并且通过对消息的过滤实现了只有某些客户端才能受到相应的消息。解耦包含了三个维度：空间、时间、同步。

可扩展性

发布 / 订阅模式还提供了比传统的客户端 - 服务器模式更好的可扩展性。这是因为，在经纪人 Broker 上的操作，是可以高度并行和基于事件驱动进行处理的。而且还可以对消息进行缓存和对消息进行智能路由，以进一步改善可扩展性。但是，要把发布 / 订阅模式扩展到支持数百万的连接，在技术上仍然是一个挑战。这一点可以通过对经纪人 Broker 节点进行集群来实现，以便通过负载平衡器把负载分配到更多的服务器节点来实现。

消息过滤

经纪人 Broker 怎样过滤所有的消息，以及怎样让每个订阅者只获得他感兴趣的消息。

选项 1：基于主题的过滤

过滤是根据标题（Subject）或主题（Topic）的，而标题或主题是每一个消息的组成部分之一。正在接收的客户端订阅了它感兴趣的主题 Topic，就可以从经纪人 Broker 那里得到它基于订阅主题 Topic 的所有消息。主题 Topic 通常是一个具有分层结构的字符串，可以基于有限数量的表达式进行过滤。

选项 2：基于内容的过滤

基于内容的过滤正如名字的暗示，是指经纪人 Broker 过滤基于特定内容、特定过滤器语言的消息。因此客户端订阅他们感兴趣的消息的过滤查询。这种过滤方法有一个较大的缺点，即消息的内容必须事先已知，并且消息不容易进行加密或修改。

选项 3：基于类型的过滤

在使用面向对象的编程语言时，有一种常见的做法，基于消息或事件的类型 / 类别进行过滤。在这种情况下，订阅者可以监听所有的消息，并从类型异常或子类型中获取消息。
当然，发布 / 订阅模式并不能解决一切，在使用此模式之前需要考虑一些事情。发布者和订阅者之间的解耦是发布 / 订阅模式的关键，这给使用它带来了一些挑战。你必须事先知道发布的数据的结构。在基于主题的过滤的场景，无论是发布者还是订阅者，都需要理解怎样正确的使用主题。另一方面是消息的交付，发布者不能想当然地认为有人会监听他发送的消息。因为在一些情况下，发布的消息可能没有任何一位订阅者。

MQTT

现在我们对发布 / 订阅模式已经有了一定的了解，但对于 MQTT 还不够。MQTT 体现了前面所有提及的方面，这取决于你想达到什么目标。MQTT 从空间上对发布者和订阅者进行了解耦。因此，客户端只需知道 Broker 的主机名（或 IP）和端口，以实现发布 / 订阅消息。MQTT 还从时间上对发布者和订阅者进行了解耦，但这往往是倒退的行为，因为大多数使用场景都是以近实时的方式传递消息。当然，Broker 还要能够存储信息，方便那些不在线的客户端（订阅者）。（这需要满足两个条件：客户端已连接一次，它的会话是持久的；并且客户端订阅了服务质量 QoS 大于 0 的主题，关于 QoS 在后续会讲到）。
MQTT 还能够解耦同步，因为大多数客户端库是异步工作的，是基于回调或类似模型的实现。所以客户端在等待消息或发布消息时不会阻止其它任务的执行。但也有一些场景需要使用同步，而且这也是可以实现的。因此有些客户端库提供了同步 API，以等待某种消息。但通常的流程都是异步的。还应该特别强调一点，MQTT 在客户端特别容易使用。大多数的发布 / 订阅系统的实现逻辑通常都在 Broker 端，而且 MQTT 协议仅仅使用了发布 / 订阅模式的基础内容，这使得 MQTT 确实是轻量级协议，确实是为小型和受限的设备而设计的协议。

MQTT 使用了基于主题的过滤方式。因此，每一个消息都包含了一个主题 Topic，要判断订阅了主题的客户端是否能够接收消息，Broker 会使用主题 Topic 进行查找。后续会详细讨论主题 Topic，以及接收消息的各种可能性。也会介绍 MQTT Broker 的实现之一——HiveMQ 的基于内容的过滤以及它自定义的插件系统。
通常为了解决发布 / 订阅系统的挑战，MQTT 有服务质量 QoS 分级。QoS 能够很容易确定某一个消息是否成功从客户端交付给 Broker 或者从 Broker 交付给客户端。这里也存在一些偶然性的情况，有些特定主题没有订阅者。如果这是一个问题，它取决于 Broker 如何处理这样的情况。例如，HiveMQ 的 Broker 有一个插件系统，它能够识别这种情况，并采取行动或仅仅是输出相应的日志到数据库供后续分析。为了减轻 Topic 主题的不灵活性，认真设计主题树（Topic Tree）并留有扩展的余地，在未来是很重要的。如果你遵循这些策略，那么 MQTT 会越用越好。