TBMQ-Professional Edition
TBMQ是ThingsBoard开发的高性能MQTT broker，可在MQTT客户端与IoT应用之间实现高效、可靠、可扩展的通信。TBMQ支持 MQTT3.x 和 MQTT5.0，可与多种设备和行业用例兼容。
Broker提供两个版本：社区版 (CE) 和 专业版 (PE)。
专业版 (PE) 为企业级版本，面向商业IoT部署和大规模生产环境。除社区版全部能力外，还包含：
- 白标品牌及UI定制
- 高级安全与访问控制
- 增强监控、分析与报表
- 专业支持与维护
PE面向需要高吞吐、运行可靠性和高级管理能力以支撑关键IoT基础设施的组织。
可使用 Docker、Kubernetes脚本或 Helm 在本地或云上安装TBMQ。安装指南中有详细步骤说明，包括Kafka、Redis和PostgreSQL等依赖的配置。
使用 Docker 时，运行提供的Docker Compose文件，可一键启动所有必需服务（Kafka、Redis、PostgreSQL和MQTT broker）。 使用 Kubernetes 时，使用官方Helm chart将TBMQ部署为可扩展、高可用的集群。Helm chart支持配置持久化、资源限制和监控等参数。 无论测试还是生产，两种方式均可在数分钟内让TBMQ运行起来。
TBMQ可在一般硬件上运行，适用于测试或小规模评估。最低要求为：
- CPU：1核
- 内存：2 GB RAM
在典型环境中为获得稳定、顺畅的运行，推荐配置为：
- CPU：4核
- 内存：8 GB RAM
- 存储：50 GB可用磁盘空间
- 操作系统：Linux（x86-64架构）
集群或生产环境下的硬件需求取决于客户端数量和消息吞吐量。
高负载部署应为 Kafka、Redis 和 PostgreSQL 分配独立节点，以保障最佳可扩展性与可靠性。
TBMQ升级流程简单。升级指南提供各版本的升级说明，以及兼容性变更和配置更新说明。
生产环境中，TBMQ应针对性能、安全和容错进行配置。建议：
- 为MQTT和WebSocket连接启用 SSL/TLS 加密。
- 配置 认证提供方以安全验证客户端。
- 为各topic配置合适的 Kafka分区数量，调整生产者和消费者参数，并调整 Redis有状态连接以获得最佳吞吐量。
- 根据系统资源调整JVM内存和线程池设置。
可以。TBMQ通过官方 Helm chart 或k8s清单全面支持 Kubernetes部署，可实现轻松扩缩容、自动恢复和滚动更新。可通过Helm values直接配置节点角色、持久卷和监控集成，适用于云或混合环境。
TBMQ通过集群支持横向扩展。集群中各节点分担MQTT客户端和消息流量，保证可靠性和负载均衡。集群协调通过 Kafka 实现消息路由。
要启用集群，需部署多个连接到相同Kafka、Redis和PostgreSQL服务的TBMQ实例，并为每个节点在环境变量中配置唯一的broker ID（TB_SERVICE_ID）。
默认情况下，TBMQ监听以下端口：
- 1883 – MQTT（明文TCP）
- 8883 – MQTT over SSL/TLS
- 8084 – MQTT over WebSocket
- 8085 – MQTT over安全WebSocket (WSS)
- 8083-HTTP Web UI访问
这些端口可在TBMQ配置文件中或通过环境变量修改，需在启动前完成。请确保防火墙或Kubernetes Ingress规则允许访问所选端口。
在TBMQ配置中提供有效的 服务器证书和私钥即可启用SSL/TLS。TBMQ支持仅服务端加密，以及更安全的 客户端证书认证 (X.509)。证书可由受信任CA签发或内部生成用于测试。配置完成后重启broker以生效。
TBMQ采用可插拔认证模型，可自定义客户端认证方式。可选：
- 基本认证（client ID、用户名和密码）
- 基于SSL的认证（X.509证书链）
- JWT认证（JSON Web Token）
- 增强认证（MQTT5.0）
认证规则在数据库中定义，在每次连接尝试时评估。
TBMQ与 Kafka、Redis 和 PostgreSQL 集成，实现可靠、高性能的数据存储：
- Kafka – 处理未处理的PUBLISH消息、Application客户端的持久消息，并存储客户端会话和订阅。
- Redis – 存储Device持久消息，用于快速访问和恢复。
- PostgreSQL – 存储用户凭据、MQTT客户端凭据、系统统计等元数据。
该混合架构确保数据持久性、高可用性和分布式系统内的高效投递。
TBMQ完整支持 MQTT3.1.1 和 MQTT5.0，兼容主流MQTT客户端和库。MQTT5.0支持包括 共享订阅、用户属性、主题别名、增强认证和原因码等高级特性，为开发者提供更大的灵活性和控制。
支持。TBMQ支持 MQTT over WebSocket 和 Secure WebSocket (WSS)，使基于浏览器的应用和Web仪表盘能实时发布和订阅主题。默认WebSocket端点为：
- 8084 – MQTT over WebSocket
- 8085 – MQTT over Secure WebSocket (WSS)
WebSocket支持便于将MQTT通信集成到现代Web应用和IoT门户中。
TBMQ按MQTT规范支持 Keep Alive 和 Clean Start。
- Keep Alive 定义客户端消息之间的最大空闲时间。 若在此间隔内无数据包发送，broker将视为连接已断开。
- Clean Start（MQTT5.0）或 Clean Session（MQTT3.1.1）决定broker是否在断开后保留客户端会话状态。
这些选项可在客户端配置。TBMQ会根据所选设置自动处理会话持久化和消息队列，保证可靠的重连行为。
TBMQ在MQTT客户端之间支持无缝通信，确保安全高效的消息交换。它支持高级MQTT5.0功能，如共享订阅、增强认证、主题别名和流量控制，为任何规模的IoT应用提供灵活性。TBMQ为性能和可扩展性而设计——无论您运行单个实例进行测试，还是运行为数千个客户端提供服务的集群设置。
可在云环境、本地部署或本地 PC上托管TBMQ。为快速搭建，推荐使用 Docker安装指南。若计划在生产或集群环境中部署TBMQ，请参考 集群部署指南 获取基于Docker Compose的多节点部署步骤。
Yes. In the Professional Edition, all branding and visual identity settings can be configured directly from the White Label page in the user interface — no code changes required. You can fully adapt the platform to your company’s look and feel with just a few clicks:
- 替换默认TBMQ logo和favicon为您自己的企业视觉元素。
- 定制登录页、仪表板和系统页，从首次交互起即展示您的品牌。
- 调整配色、强调色、logo尺寸及样式（包括CSS微调）以匹配企业形象。
- 预览所有更改后再发布。
- 配置自定义域名——映射您自己的URL（例如
portal.company.com），使用户通过您的品牌域名访问TBMQ。
These tools make it easy to deliver a fully branded experience that aligns with your organization’s visual standards.
TBMQ通过 MQTT over SSL/TLS加密保障消息交换安全，防止未授权访问和数据篡改。支持创建自定义 认证提供方验证客户端凭据，并支持 增强认证（MQTT5.0）以实现更灵活的安全模型。可与现有证书机构集成或使用用户名/密码认证。这些特性为建设安全可靠的IoT通信网络提供坚实基础。
TBMQ支持多种认证机制，以保障安全、灵活的客户端验证。可用方式包括：
- 基本认证——验证数据库中存储的client ID、用户名和密码。
- X.509证书链认证——使用SSL/TLS证书验证客户端。
- 增强认证（MQTT5.0）——支持MQTT5.0规范的SCRAM认证流程。
- JWT认证——通过TBMQ认证API实现基于令牌的认证及与外部身份系统集成。
可根据部署和安全需求选择最适合的方式。
TBMQ支持 SSL/TLS加密和客户端证书认证（X.509证书链）。启用该功能需：
- 在配置文件中提供有效的服务器证书和私钥。
- 启用安全MQTT端口（默认
8883）。 - 配置TBMQ使用X.509证书链凭据验证客户端证书，实现双向认证。
这确保了客户端和服务器在建立连接前相互验证身份，为IoT和企业部署增添了强大的安全层。
支持。TBMQ通过认证提供方支持基于 JWT（JSON Web Token） 的认证，客户端可使用签名令牌而非静态凭据安全连接。JWT适合由外部身份服务签发凭据的动态或短期会话。
TBMQ自动检测并记录未授权连接尝试。客户端认证失败时，broker会记录 client ID、IP地址、用户名和TLS状态等详情。可在 未授权客户端 仪表盘中查看，或通过API查询做进一步分析。
TBMQ提供通过Web界面或REST API直接监控未授权客户端的工具。管理员可筛选、查看和删除记录。还可配置阻止规则，拒绝来自已知恶意IP或多次违规者的后续连接尝试。该功能有助于保持系统完整性并监控潜在安全风险。
TBMQ使用基于Trie的数据结构管理客户端订阅，实现快速且内存高效的topic查找。所有客户端订阅从Kafka主题消费并存入内存中的Trie，每个节点代表topic过滤器层级的一级。
Trie结构支持基于前缀的匹配，使TBMQ能快速识别与已发布消息匹配的topic的订阅客户端。从Kafka读取 PUBLISH 消息时，TBMQ使用Trie确定有相关订阅的客户端集，并将消息转发给每个客户端。
该方式确保高性能消息路由，查找时间取决于topic长度而非订阅总数，即便在有数百万活跃订阅的大规模环境中仍能高效扩展。虽然Trie的内存存储会略微增加内存占用，但能提供可预测且低延迟的消息投递。
支持。TBMQ支持MQTT5.0规范定义的共享订阅。共享订阅允许多个客户端以负载均衡方式从同一topic组消费消息。该特性特别有利于消息处理的水平扩展，例如在多个后端服务间分发遥测数据处理。
TBMQ支持保留消息，确保新连接的订阅者立即收到该topic上最新发布的消息。客户端发布保留消息时，TBMQ存储该消息并在新订阅者订阅时自动投递。若收到空payload的保留消息，TBMQ按MQTT规范清除该topic的保留消息。
A persistent session stores the client’s subscriptions and undelivered QoS 1/2 messages, allowing message delivery to resume after reconnecting. A non-persistent session (Clean Start = true) is temporary — all subscriptions and queued messages are discarded when the client disconnects. TBMQ fully supports both modes and automatically handles session recovery for persistent clients after reconnecting.
TBMQ遵循MQTT标准处理遗嘱消息（LWT）。客户端连接时可指定LWT消息，若客户端意外断开，broker将自动发布该消息。该特性有助于通知其他客户端或监控系统异常断开情况，提升IoT系统的可见性与可靠性。
TBMQ提供消息吞吐量的详细指标，包括已发布、已接收和已丢弃消息数量。这些统计数据可通过内置监控仪表板查看。管理员可利用这些洞察追踪broker性能并优化系统配置。
TBMQ提供水平可扩展性，意味着它可以随着您的工作负载无缝增长。集群中的每个broker节点负责处理一部分负载，确保消息处理均衡和性能不中断。实际吞吐量取决于硬件、配置和消息特性（大小、QoS级别、持久化）。优化配置可处理数百万并发客户端连接和每秒数百万条消息。有关详细指标和基准测试，请访问性能测试页面。
TBMQ通过其监控仪表板和 Prometheus端点暴露详细的性能指标。您可以跟踪以下关键指标：
- 已连接客户端数量
- 消息发布与接收速率
- 队列大小与处理延迟
- Redis与Kafka性能
这些指标可在 Grafana 或其他可观测性平台中可视化，以实时洞察系统健康与吞吐趋势。
TBMQ实现了一种内部背压管理机制，在客户端无法快速消费消息时维持稳定的性能。当客户端的网络通道变为不可写时，TBMQ暂时暂停该客户端的消息交付。一旦通道再次变为可写，待传递的消息将按正确顺序传送。这种设计防止慢速消费者影响其他客户端，确保集群内的一致吞吐。