4、消息中间件选型：Kafka vs RabbitMQ vs Pulsar，在ThingsBoard中的实际应用
消息中间件，说白了就是整个微服务架构的「血管」。
ThingsBoard 里所有设备数据、规则链事件、RPC 指令，全都要靠它来流转。选错了，后面改起来会非常痛苦。我见过不少团队，前期图省事随便选一个，等到日均百万级消息量时，整个系统直接瘫痪。
今天咱们就聊聊 Kafka、RabbitMQ、Pulsar 这三兄弟，在 ThingsBoard 里到底该怎么选。
4.1 为什么 ThingsBoard 离不开消息中间件？
先看一张简化架构图，你就能明白消息队列的位置有多关键：
设备 → 网关 → 消息队列 → 规则引擎 → 数据存储
↓
微服务A → 微服务B → 微服务C没有消息队列，所有服务就得直接通信。你想想看，几十个微服务互相调用，耦合度会高到什么程度？
ThingsBoard 里消息队列承担了三个核心职责：
- 削峰填谷：设备上报数据是突发的，规则引擎处理是平稳的。队列能缓冲这个差异。
- 解耦服务：Transport 层只管收数据，Rule Engine 只管处理数据，谁也不依赖谁。
- 保证顺序：同一个设备的数据，必须按时间顺序处理。乱序会导致状态错乱。
核心要点：ThingsBoard 对消息队列的要求，排第一的是「顺序性」，排第二的是「吞吐量」。别搞反了。
4.2 三款中间件的核心差异
我直接给结论，然后咱们再细聊：
| 特性 | Kafka | RabbitMQ | Pulsar |
|---|---|---|---|
| 设计定位 | 分布式日志流 | 消息代理 | 下一代消息平台 |
| 吞吐量 | 极高（百万级/秒） | 中等（万级/秒） | 极高（百万级/秒） |
| 消息顺序 | 分区内有序 | 队列内有序 | 分区内有序 |
| 消息回溯 | 支持（基于offset） | 不支持 | 支持（基于游标） |
| 运维复杂度 | 中等 | 低 | 高 |
| ThingsBoard 支持 | 原生支持 | 原生支持 | 社区插件 |
4.3 Kafka：ThingsBoard 的默认选择
ThingsBoard 官方默认集成的就是 Kafka。为什么？
我个人习惯用 Kafka 来处理设备数据流。原因很简单：它天生就是为「流式数据」设计的。
设备上报数据，本质上就是一个持续不断的日志流。Kafka 的「分区 + 偏移量」机制，完美匹配这个场景。
我的经验：在 ThingsBoard 里，每个设备类型对应一个 Kafka Topic。比如温度传感器用 tb.temperature，湿度传感器用 tb.humidity。这样规则引擎可以根据 Topic 直接分流，不用额外做过滤。
Kafka 在 ThingsBoard 中的典型配置：
# thingsboard.yml 中的 Kafka 配置
transport:
kafka:
enabled: true
bootstrap.servers: "localhost:9092"
# 每个分区对应一个消费者线程
partitions: 10
replication.factor: 3
# 消息保留7天，方便回溯
retention.ms: 604800000嗯，这里要注意：分区数不是越多越好。分区太多会导致 Kafka 的元数据膨胀，反而降低性能。我一般建议分区数 = 消费者线程数 × 2。
4.4 RabbitMQ：适合轻量级场景
RabbitMQ 在 ThingsBoard 里也能用，但场景有限。
我曾经在一个小项目里用过 RabbitMQ。当时设备量只有几百台，每天消息量不到十万条。用 RabbitMQ 完全够用，而且部署简单，一个 docker-compose 就搞定了。
但一旦设备量上来，问题就来了：
- RabbitMQ 的消息堆积能力弱。内存一满，就开始往磁盘刷，性能断崖式下跌。
- 消息回溯基本没有。消费过的消息就丢了，想重新处理？没门。
- 集群扩容麻烦。加节点要重新配置，不像 Kafka 那样平滑。
避坑指南：我曾经见过一个团队，用 RabbitMQ 扛日均 500 万条消息。结果每两周就要手动清理一次堆积，运维苦不堪言。如果你预估设备量会快速增长，直接上 Kafka，别犹豫。
RabbitMQ 在 ThingsBoard 中的配置相对简单：
# RabbitMQ 配置
transport:
rabbitmq:
enabled: true
host: "localhost"
port: 5672
virtual-host: "thingsboard"
# 使用 topic 交换机，支持路由匹配
exchange: "tb.exchange"4.5 Pulsar：未来的潜力股
Pulsar 是这三者里最年轻的，但潜力最大。
它把「存储」和「计算」分离了。说白了，Broker 只管转发消息，数据存在 BookKeeper 里。这意味着你可以独立扩容计算层和存储层。
Pulsar 在 ThingsBoard 里的优势：
- 原生多租户：一个 Pulsar 实例可以服务多个 ThingsBoard 租户，数据完全隔离。
- 消息 TTL 灵活：可以针对不同 Topic 设置不同的保留策略。
- 延迟队列：规则链里的「延迟节点」可以直接用 Pulsar 的延迟消息实现，不用额外写代码。
但 Pulsar 也有短板：
- ThingsBoard 官方没有原生集成，需要自己写插件。
- 运维复杂度高。BookKeeper、ZooKeeper、Broker 三个组件都要管。
- 社区资源少，遇到问题不好查。
我的建议：如果你是新项目，团队有运维能力，可以试试 Pulsar。如果是现有 ThingsBoard 集群迁移，老老实实用 Kafka。别为了追新技术给自己挖坑。
4.6 实际选型决策树
说了这么多，到底怎么选？我整理了一个简单的决策逻辑：
- 日均消息量 < 10 万：RabbitMQ 够用，部署简单，运维成本低。
- 日均消息量 10 万 ~ 1000 万：Kafka 是标准答案。ThingsBoard 官方支持最好。
- 日均消息量 > 1000 万：考虑 Pulsar。它的存储计算分离架构，能扛住这个量级。
- 需要消息回溯：排除 RabbitMQ。Kafka 和 Pulsar 都支持。
- 运维团队 < 2 人：别碰 Pulsar。Kafka 或 RabbitMQ 更稳妥。
你想想看，选消息中间件其实就是在「性能」和「运维成本」之间找平衡。没有银弹，只有最适合你当前场景的方案。
最后说一句：不管选哪个，一定要在测试环境压测。我见过太多人，看文档觉得 Kafka 吞吐量高，结果上线后发现配置不对，性能还不如 RabbitMQ。理论归理论，实践出真知。