嵌入式轻量MQTT Broker订阅主题的合理组织方案咨询

Great question—especially for an embedded-focused lightweight MQTT broker, where every byte of memory and CPU cycle counts. Let’s break down both approaches and their tradeoffs, then zero in on what makes sense for your use case:

方案1：主题为中心的存储（主题 → 订阅客户端ID集合） #

This approach uses a global structure (like a hash map or topic tree) where each key is a subscribed topic, and the value is a collection of client IDs that have subscribed to that topic.

优点 #

• 消息分发效率高: When a publish message arrives, you directly look up the target topic (and any matching wildcard topics) to get all subscribed clients. No need to iterate through every connected client—critical if you have frequent message traffic or many clients.
• 内存利用更高效（针对共享订阅）: 如果多个客户端订阅同一个主题，主题字符串只会存储一次，不会在每个客户端的列表中重复存储。对于长主题或大量共享订阅的场景，能节省不少内存。

缺点 #

• 客户端清理操作繁琐: 当客户端断开连接时，你需要从所有它订阅过的主题的客户端集合中移除其ID。如果没有额外的反向映射结构，就不得不遍历所有主题进行检查——如果主题数量多，这会非常耗时且占用资源。
• 通配符处理增加复杂度: MQTT的+和#通配符意味着不能只做简单的精确匹配。哈希表适合精确主题查找，但通配符匹配要么需要遍历所有主题（速度慢），要么需要更复杂的主题树结构（用层级节点表示主题层级，让通配符查找更高效）。主题树效果更好，但会增加一点代码复杂度。

方案2：客户端为中心的存储（客户端 → 订阅主题列表） #

这种方式下，每个客户端实例维护自己的订阅主题列表（或集合）。 broker 没有全局的主题-客户端映射，只跟踪所有在线客户端，每个客户端自带订阅数据。

优点 #

• 客户端生命周期管理简单: 客户端断开连接时，直接丢弃它的订阅列表即可。不需要跨结构引用或全局清理操作——非常适合客户端频繁连接/断开的嵌入式场景。
• 实现复杂度低: 不需要哈希表、主题树这类复杂的全局数据结构。可以用简单的链表或静态数组（如果限制每个客户端的最大订阅数）存储主题，代码更易编写，在资源受限的硬件上开销更低。
• 订阅/取消订阅操作快: 添加或移除主题只需要修改客户端的本地列表——不需要锁定或更新全局状态（对于避免线程同步开销很重要）。

缺点 #

• 消息分发速度慢: 每条发布消息到来时，你必须遍历所有在线客户端，检查它们的订阅主题是否匹配发布主题（还要处理通配符逻辑）。如果客户端数量较多或消息吞吐量高，这会消耗大量CPU周期——而嵌入式芯片的CPU资源十分宝贵。
• 主题重复存储浪费内存: 如果10个客户端都订阅sensor/temp，这个字符串会被存储10次（每个客户端的列表中存一份）。对于长主题或大量共享订阅的场景，会占用不少RAM。

最佳选择取决于你的具体约束，但可以按以下优先级判断：

1. 如果客户端数量<20且消息量小: 优先选客户端为中心的方案。它实现简单，初始内存开销低，避免了主题树或反向映射的复杂度。在小型嵌入式场景中，较慢的消息分发不会成为明显问题。

2. 如果需要支持更多客户端或频繁消息: 使用混合方案：

   • 核心结构: 用轻量级主题树实现支持通配符的快速消息查找（将主题映射到客户端ID集合）。
   • 反向映射: 每个客户端维护自己的订阅主题列表。当客户端断开时，遍历它的本地主题列表，从主题树的对应条目中移除其ID。这种方式结合了主题中心方案的分发效率和客户端中心方案的清理便捷性。

让两种方案更轻量化的嵌入式专属优化 #

• 用ID替代字符串: 给客户端和主题分配唯一的整数ID，存储ID而非完整字符串。这能减少内存占用，加快查找速度。
• 使用静态内存: 避免为订阅列表或主题结构使用动态分配（比如malloc）。预分配固定大小的数组或使用内存池，防止内存碎片化，简化内存管理。
• 限制最大订阅数: 强制限制每个客户端的最大订阅数（比如5-10个）。这样可以用静态数组替代链表，速度更快且开销更低。

内容的提问来源于stack exchange，提问作者Tomasz Pluta