一文读懂物联网 MQTT 协议之基础特性篇，java多线程常见面试题

pub/sub 最重要的方面是消息的发布者与接收者（订阅者）的解耦。这种解耦有几个维度：

• 空间解耦：发布者和订阅者不需要相互了解（例如，不交换 IP 地址和端口）。

• 时间解耦：发布者和订阅者不需要同时运行。

• 同步解耦：两个组件的操作在发布或接收时不需要中断。

总之，发布/订阅模式消除了传统客户端/服务器之间的直接通信，把通信这个操作交给了 broker 进行代理，并在空间、时间、同步三个维度上进行了解藕。

2.3 可扩展性

pub/sub 比传统的客户端/服务器模式有了更好的拓展，这是由于 broker 的高度并行化，并且是基于事件驱动的模式。可扩展性还体现在消息的缓存和消息的智能路由，还可以通过集群代理来实现数百万的连接，使用负载均衡器将负载分配到更多的单个服务器上，这就是 MQTT 的深度应用了。

2.4 消息过滤

很明显，broker 在 pub/sub 过程中起着举足轻重的作用。但是代理如何过滤所有消息，以便每个订阅者只接收感兴趣的消息？broker 有几个可以过滤的选项：

• 基于主题的过滤

此过滤基于属于每条消息的主题。接收客户端向代理订阅感兴趣的主题，订阅后，broker 就会确保客户端收到发布到 topic 中的消息。

• 基于内容的过滤

在基于内容的过滤中，broker 会根据特定的内容过滤消息，接受客户端会经过过滤他们感兴趣的内容。这种方法的一个显著的缺点就是必须事先知道消息的内容，不能加密或者轻易修改。

• 基于类型的过滤

当使用面向对象的语言时，基于消息（事件）的类型/类进行过滤是一种常见做法。例如，订阅者可以收听所有类型为 Exception 或任何子类型的消息。

2.5 MQTT 与消息队列的区别

这里你又会说了，既然 MQTT 与主流的消息的队列都采用发布/订阅模式，那他们就是一样的。这里老周得再提一嘴，确实和消息队列很多相似的地方，但还有有些差异的，下面就来说道说道：

• 消息队列存储消息直到消息被消费 使用消息队列时，每条传入消息都存储在队列中，直到被客户端（通常称为消费者）接收。如果没有客户端接收到消息，消息将保持在队列中并等待被消费。在消息队列中，不会存在消息没有客户端消费的情况，但是在 MQTT 中，却存在 topic 无 subscriber 订阅的情况。