什么是 TBMQ
1、一句话定义
TBMQ = ThingsBoard 团队开源的 MQTT 消息代理（MQTT Broker）。
它面向大规模 IoT：高并发连接、高吞吐、低延迟，并在集群模式下进一步扩展。原稿与早期宣传口径常提到约 4M+ 并发、单节点约 3M msg/s；集群可支撑约 1 亿级 并发连接——具体以官方压测与你使用的版本说明为准。
2、为何要做 TBMQ（ThingsBoard 团队视角）
ThingsBoard 在服务各类物联网方案时，归纳出两类典型流量形态：
| 模式 | 含义 | 例子 |
|---|---|---|
| 扇入（Fan-in） | 大量设备产生海量消息，被少数应用消费 | 百万传感器 → 少量后端/流处理 |
| 扇出（Fan-out） | 少量发布、大量订阅；入小出大 | 配置下发、广播通知 |
TBMQ 按这两种场景做了针对性设计，而不是「通用 Broker 随便跑跑」。
技术栈上用 Java 实现，并依赖成熟开源组件（尤其是 Kafka）保证低延迟、持久化与水平扩展。发展脉络（原稿）：2018 起持续研发 → 2021 进入商业应用 → 2023 年初公开社区版。
3、MQTT 能力清单（原稿 + 官方）
- 干净会话 / 持久会话
- QoS 0 / 1 / 2
- Retained、Last Will and Testament
- Keep Alive、客户端接管
- TCP / SSL（MQTTS）、MQTT over WebSocket
- 用户名密码认证；X.509 证书链；后续版本还支持 JWT、SCRAM、HTTP 等（见官方 Security）
- 通配符订阅；QoS1/2 的有序主题保证
- 会话与消息过期间隔
- 多节点集群
- 基于 ClientId / 用户名 / 证书的 ACL
- 会话与订阅的 REST 查询
- 客户端入向速率限制
- MQTT 5（辅：2.x 起强化）
管理控制台可看：会话、订阅、凭证、未授权客户端、监控、WebSocket 客户端等（文档导航）。
4、设计目标
原稿归纳四点：
- 可扩展：水平扩展，基于主流开源组件
- 容错：无单点；集群节点对等，高可用
- 健壮高效：单节点即可扛大量连接与消息
- 持久：消息与状态可持久化，降低丢失风险
官方压测方向（辅）：点对点约 100 万 msg/s、扇出约 300 万 msg/s、扇入约 1 亿连接量级——用于理解上限，不是本地笔记本承诺。
5、架构怎么拆（辅，强烈建议理解）
一张逻辑图（概念级）：
text
MQTT 客户端
│
▼
Netty 接入 ──► Actor / 消息分发 ──► 订阅 Trie 匹配
│
┌───────────┼───────────┐
▼ ▼ ▼
Kafka Redis/Valkey PostgreSQL
（消息与状态 （持久 DEVICE （用户、凭证、
骨干、节点协调） 离线队列） 元数据、统计）要点：
| 组件 | 职责 |
|---|---|
| Kafka | 已发布未处理完的消息、会话/订阅等状态；节点间唯一协调通道（无自研注册中心/选主） |
| Redis / Valkey | 持久 DEVICE 客户端的离线消息队列（TBMQ 2.0 起从 PG 迁到 Redis，吞吐更好） |
| PostgreSQL | 用户、MQTT 凭证、集成定义、统计等；不存 MQTT 消息载荷 |
| APPLICATION 客户端 | 高吞吐后端消费者：常为每个客户端独立 Kafka Topic，与 DEVICE 路径不同 |
发布确认时机：对持久 DEVICE 场景，官方强调 Kafka 落稳后即可 ACK 发布端，再异步写入 Redis——耐久性靠 Kafka，不靠 Redis 在关键路径上。
更多细节见：Architecture Overview、Persistent DEVICE client。
6、和 ThingsBoard 怎么配合
- 只做消息总线：设备 ↔ TBMQ ↔ 自有微服务
- 对接 ThingsBoard：TBMQ 收设备消息，再经 MQTT/HTTP/Kafka 集成或自定义规则节点写入 TB
- 规模演进：小项目可用 TB 内置 MQTT；连接与吞吐上去后再拆 TBMQ
7、小结
TBMQ 不是「又一个玩具 Broker」，而是按 扇入/扇出 + Kafka 骨干 做出来的 IoT 向 MQTT 服务。下一篇：编译 TBMQ；想直接上服务器见 安装部署。