MQTT使用了基于主题的过滤方式。因此，每一个消息都包含了一个主题Topic，要判断订阅了主题的客户端是否能够接收消息，Broker会使用主题Topic进行查找。后续会详细讨论主题Topic，以及接收消息的各种可能性。也会介绍MQTT Broker的实现之一——HiveMQ的基于内容的过滤以及它自定义的插件系统。
通常为了解决发布/订阅系统的挑战，MQTT有服务质量QoS分级。QoS能够很容易确定某一个消息是否成功从客户端交付给Broker或者从Broker交付给客户端。这里也存在一些偶然性的情况，有些特定主题没有订阅者。如果这是一个问题，它取决于Broker如何处理这样的情况。例如，HiveMQ的Broker有一个插件系统，它能够识别这种情况，并采取行动或仅仅是输出相应的日志到数据库供后续分析。为了减轻Topic主题的不灵活性，认真设计主题树（Topic Tree）并留有扩展的余地，在未来是很重要的。如果你遵循这些策略，那么MQTT会越用越好。
对于MQTT，存在一些混淆的地方，它的名字使得它容易被当作消息队列来实现。这里要再次强调，MQTT不是消息队列，在IBM的产品中，提供的消息队列被称为MQserie。那么，MQTT与传统的消息队列到底有什么区别？
1）消息队列会一直保存消息，直到消息被消费（Consume）在使用消息队列时，每一条即将到来的消息都会被存放到消息队列中，直到消息被任何客户端取走（通常称为消费。否则，消息会一直存放在队列中，等待被消费。如果某条消息一直不被任何客户端所消费，这是不可能的，就好像MQTT的主题Topic没有任何客户端订阅的情况。
2）一条消息只能由一个客户端消费这是一个很大的区别，在传统的消息队列中，一条消息仅能由一个消费者进行处理。因此，所有消费者之间的负载可以被分发到某个特定的队列上。而在MQTT上则完全相反，对于每一个订阅者，只要他们订阅了某个主题，那么他们都可以得到该主题的消息。
3）队列被命名，且必须以明确的方式创建队列远远不及主题那么灵活。在使用队列之前，必须先使用一个单独的命令明确地创建队列。只有在队列创建之后，才可以在该队列上发布消息或消费消息。而MQTT的主题Topic是非常灵活的，可以动态地创建主题。