我正在设计一个包含许多使用MQTT连接到中央代理的设备的系统。
有些主机可以将请求发送到作为从机的某些设备。来自一个主机的请求通常被定向到一个从机。
请求的主题可以是：mysystem/slaveId/req，因此从服务器可以订阅该主题，而主服务器可以发布到同一主题。只有寻址的从站将接收请求，如应如此。
我的问题是如何确定答复主题。我对此感到疑惑：mysystem/slaveId/res/masterId或只是mysystem/slaveId/res。
在第一种情况下，我应该在请求的有效负载中将masterId发送到从属服务器，以便从属服务器能够构造响应主题名称。答案将仅由发送请求的主机接收。
在第二种情况下，所有活动的主控机将收到响应，因为该主题不包含masterId。发送请求的主服务器应通过查看有效负载中的requestId（也已在请求有效负载中发送）来检测其响应。
我认为第一种选择更好，但是AWS的Device Shadow服务使用与第二种选择相似的主题名称。例如，回复获取请求的设备将消息发布到$aws/things/myLightBulb/shadow/get/accepted。因此，每个设备都会收到消息，而不仅仅是请求的消息。
我认为AWS做出了不错的选择，因此我很想遵循它……但是我不确定我是否了解它们的作用。
答案 0 :(得分：0)
“好的选择”取决于上下文，这里的上下文有所不同。设备阴影旨在跟踪并准确反映设备状态。您链接的页面没有讨论在一个设备上存在多个阴影，并且在编写时可能没有考虑多个接收者。尽管如此，它的简单主题体系结构仍将在每个设备具有多个阴影的系统中工作，因为 shadow 应该会收到其设备的所有响应。这些响应中的任何一个都可能揭示设备状态的变化，并且客户端未收到响应的任何影子都将过时，并且与其他影子不同步。
您的母带听起来不像是影子。也许他们独立地将结果报告给充当影子的数据存储。响应中可能没有任何内容表示状态更改值得在请求之外进行跟踪。无论哪种方式，文档听起来都不符合您的目标。
我支持您首选的偏爱，尤其是随着节点数量的增长。主要缺点是需要额外的工作来跟踪请求的主ID。对于母版而言，这很容易（每个人都只能订阅mySystem/+/res/masterId，并且在具有主题访问控制的系统中，您甚至可以隔离他们）。如果请求正文很简单（尚不可以解析多个属性），则可以考虑将主控方发布到mysystem/slaveId/req/masterId（从属方可以订阅mysystem/slaveId/req/+）。
从AWS上获取的最大示例可能是主题中清晰的层次感。如果您最关心的不是在主题末尾使用masterId的解析方便性，则将其排序为：mysystem/masterId/slaveId/req（或res）可能更有意义。非常取决于您的系统和目标。