Paho MQTT 客户端：订阅多个主题的最佳实践 [关闭]答案

【问题标题】：Paho MQTT Client: Best Practice for subscribing to multiple Topics [closed]Paho MQTT 客户端：订阅多个主题的最佳实践 [关闭]
【发布时间】：2020-11-18 19:19:49
【问题描述】：

我们的用例是多个资产向 MQTT 代理发送不同类型的数据（比如 status、temp 和 data）。因为消息代理非常擅长路由、处理主题等，资产将每种类型的数据发布到一个专门的主题：

status messages   >   status topic   >   e.g. /asset/123/status
temp messages     >   temp topic     >   e.g. /asset/123/temp
data messages     >   data topic     >   e.g. /asset/123/data

现在我们的问题出现了，订阅者应该如何处理不同的主题。因此，我们通过 SpringIntegration 使用默认的 Paho 客户端。在我们看来，有两种可能的解决方案：

解决方案 1

一个 Paho 客户订阅所有相应的主题。现在实际的路由（哪种数据类型的回调）必须在后端自己完成。

解决方案 2

每个主题都有一个 Paho 客户端。因此，实际的路由是在消息代理处完成的，不再需要在后端完成路由逻辑。客户端只需调用他们的回调，后端只关注其领域逻辑（而不是主题的路由）。

最佳实践？

现在我们的问题是，有没有关于这个问题的最佳实践？从我们的角度来看，路由是消息代理的工作，因为这就是设计的目的。所以路由逻辑不应该在后端。这很好，因为后端现在可以专注于自己的域逻辑。但是为此，我们需要有n 客户端，n 是不同数据类型的数量。当在某个时间点拥有越来越多的消息类型和因此越来越多的主题时，这可能会让连接爆炸。

是否有任何涵盖该主题的最佳实践、基准或（反）模式？

【问题讨论】：

第一个最佳实践，不要以 / 开头，这只会导致问题（例如，当您开始使用共享订阅时）
哦，那只是图表中的一个“错字”。不过还是谢谢你的通知。当然主题是asset/#/status等。

标签： spring spring-integration mqtt messaging paho

【解决方案1】：

在类似情况下，我实施的解决方案 2 比解决方案 1 多。正如您正确指出的那样，后端可以只专注于它们的单一用例，而不必担心其他用例......如果真的是这样的话。如果在某个时候，您需要/status 和/data，那么这将成为解决方案 1 不会遇到的问题。解决方案 2 需要更多的计算资源，但通常更快（取决于您的 MQTT 代理和您的解决方案正在运行什么。）解决方案 2 也更适用于故障排除和导致崩溃的错误 - 崩溃只影响一个域，而不是所有域。

【讨论】：