MQTT Part 5 主题和最佳实践

本文翻译自http://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices

未经允许，不得转载

主题

主题是一个UTF-8字符串，代理用它来过滤每个连接的客户端的消息。 主题由一个或多个主题级别组成。 每个主题级别之间由正斜杠（主题级别分隔符）分隔。

与消息队列相比，主题非常轻量级。 客户端不需要在发布或订阅之前创建所需的主题，因为代理接受每个有效主题时不需要进行任何预初始化。
以下是几个示例主题：

myhome/groundfloor/livingroom/temperature
USA/California/San Francisco/Silicon Valley
5ff4a2ce-e485-40f4-826c-b1a5d81be9b6/status
Germany/Bavaria/car/2382340923453/latitude

值得注意的是，每个主题必须包含至少一个字节，并且它还可以包含空格。 另外，主题是区分大小写的，这使得myhome/temperature和MyHome/Temperature是两个单独的主题。除此之外，单独的正斜线也是有效的主题。

通配符

当客户端订阅主题时，它可以使用消息发布到的确切主题，或者可以使用通配符同时订阅更多的主题。 通配符只能在订阅主题时使用，并且在发布消息时不允许使用。 下面我们将逐一介绍两种不同的类型：单级和多级通配符。

单级: +
正如名称已经表明的，单个级别的通配符代替一个主题级别。 加号表示主题中的单个级别通配符。

除了通配符以外的任意字符串所构成的主题级别，可以与由单级通配符构成的主题级别相匹配。 例如，对于 myhome/groundfloor/+/temperature的订阅将匹配或不匹配以下主题：

多级: #
单级通配符仅涵盖一个主题级别，而多级通配符可以涵盖任意数量的主题级别。 为了确定匹配的主题，需要多级通配符总为主题中的最后一个字符，并且确保它前面是正斜杠。

订阅具有多级通配符的主题的客户端将接收所有的消息，这些消息以通配符之前的模式开始，无论多长或多深的主题都将被获取到。 如果仅将多级通配符指定为主题（ ＃），则意味着您将获得的所有通过MQTT代理发送的消息。 如果你期望这种反面模式具有高吞吐量，请参见下面的最佳实践。

以$开始的主题

通常，对主题进行命名是完全自由的，但是也有一个例外。以$号开始的每个主题都会被特殊对待，比如，当订阅#时，这些以$开头的主题并不包含在订阅的内容中。这些主题被保留为MQTT代理服务器的内部特性。因此，客户端是不能向这些主题发布消息的。目前，broker所发布的主题格式还没有明确的的官方标准。一般的做法是用***$SYS/ ***打头，后面跟不同的格式。在MQTT GitHub wiki中可以找到有关$SYS主题的一个建议， 这里有一些例子：

$SYS/broker/clients/connected
$SYS/broker/clients/disconnected
$SYS/broker/clients/total
$SYS/broker/messages/sent
$SYS/broker/uptime

概要

这些是关于MQTT消息主题的基础。正如你所看到的，MQTT主题是动态的，并且给开发者提供了很大的灵活性。但是你应该注意的是当你把这些知识应用到真实的程序中还是有一些挑战的。我们收集了我们的最佳的实践，我们是从去年开始学习MQTT，并把它频繁的用在了很多项目中。我们欢迎大家在评论中提供建议或者讨论，如果你不认同我们最好的实践方法的话，请让我们知道您的最佳做法。

不要用正斜杠开头
在MQTT中以正斜杠开始是被允许的，例如/myhome/groundfloor/livingroom。但是这将会在开头产生一个不必要的零字节的主题级别。这种情况应该被避免，因为它并没有任何好处，还会带来一些不必要的困惑。

不要在主题中是用空格
空格是所有程序员的天敌，在出现异常时，阅读和调试含有空格的主题会显得异常困难。所以和第一点一样，被允许的事情并不代表建议我们去做。UTF-8 中有很多空格类型，很明显，我们应该避免使用这种特殊字符。

保持主题简洁明了
每条信息都包含了它所使用的主题，所以我们应该想方设法让主题简明。尤其是在小型设备上，每个字节数都显得格外重要。

只用ASCII字符，避免使用不可打印的字符
使用非ASCII的UTF-8字符会使我们很难找出错别字或者找到因字符导致的错误，因为这些字符常常不能被正确显示。除非必要情况，我们都不建议在主题中使用非ASCII字符。

在主题中嵌入唯一标识符或者是客户端ID
在主题中嵌入发布消息的客户端的唯一标识符会显得非常有用，这样可以便于识别是谁发布的消息。另一个比较有用的方面是身份验证，以便于让客户端只能发布与自身ID相关联的主题。所以，一个id为client1的客户端只被允许发布client1/status，但不能发布client2/status。

不要订阅#
某些情况下，我们需要订阅所有broker上传输的消息，例如需要把数据持久化到数据库时。我们不应该使用MQTT客户端订阅多级通配符的方式来实现此功能。因为客户端不能处理积攒的消息，尤其是当系统有较大吞吐量时。我们建议在MQTT broker上实现扩展功能，例如使用HiveMQ的插件系统，其允许你钩住HiveMQ的动作，并添加一个异步程序来处理每一条收到的信息，并将其存入数据库。

不要忘记可扩展性
主题是一个灵活的概念，不需要预先为其分配空间，但发布者和订阅者双方都应该知晓主题。所以，思考如何能在添加新功能时仍可以很好地扩展当前主题就显得尤为重要。例如，当你的智能家居系统需要增加一些新的传感器时，应该可以在不改变主题架构的前提下将其添加进去。

使用具体的主题，而不是通用的主题
命名主题的重要一点就是要避免以队列的形式使用它们，例如，所有消息
都使用同一个主题就是一个错误的模式。你应该尽可能让主题具体化。所以如果你的客厅（living room）里有三个传感器，你应该使用这样的主题：myhome/livingroom/temperature，myhome/livingroom/brightness 以及 myhome/livingroom/humidity，而不是通过myhome/livingroom发送所有的值。这样也便于你使用其他的MQTT功能，例如留存信息，这些我们会在下一章提到。