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 订阅的情况。