微信牛牛机器人 ThingsBoard 集群架构的核心逻辑建立在微服务化
ThingsBoard 集群架构的核心逻辑建立在微服务化（Microservices）与事件驱动（Event-Driven）的设计之上，旨在解决物联网场景下海量设备连接、高并发数据摄入以及水平扩展的需求。其核心源码逻辑主要围绕 消息队列解耦、无状态服务节点、分布式缓存同步 以及 规则引擎分片处理 展开。
1. 总体架构：微服务与消息总线
ThingsBoard 集群并非单体应用的简单多实例部署，而是将核心功能拆分为独立的微服务模块，通过消息中间件（通常为 Kafka 或 RabbitMQ）进行通信。
TB Node (Application Service)：负责 REST API 请求处理、RPC 调用、规则引擎执行以及 WebSocket 会话管理。它是无状态的，可以横向无限扩展。
TB Transport (Transport Service)：专门负责设备协议接入（MQTT, HTTP, CoAP, SNMP, LwM2M）。它将接收到的原始消息转换为内部标准格式后发布到消息队列，自身不处理业务逻辑，从而保证接入层的高吞吐。
Rule Engine (规则引擎)：在集群模式下，规则引擎的处理逻辑被分布到各个 TB Node 上。通过分区策略，确保同一设备的消息顺序性。
2. 核心通信机制：Kafka 主题分区与路由
集群内部的数据流转高度依赖 Kafka 的主题（Topic）分区机制，这是保证数据一致性和顺序性的关键源码逻辑。
设备级分区键（Partition Key）：
在源码中，所有与特定设备相关的消息（遥测数据、属性更新、RPC 请求）在发送到 Kafka 时，都会使用 deviceId 或 tenantId 作为 Partition Key。
java
// 伪代码逻辑示例
producer.send(new ProducerRecord<>(topic, deviceId.toString(), message));
这确保了来自同一设备的所有消息始终落入 Kafka 的同一个分区。由于 Kafka 保证单个分区内的消息有序，且 ThingsBoard 规定单个分区由唯一的 Consumer Group 成员消费，从而实现了单设备消息处理的严格顺序性，避免了并发冲突。
核心 Topic 划分：
tb_rule_engine.*：用于规则引擎处理的消息。
tb_transport.api.requests / responses：用于 Transport 服务与 Rule Engine 之间的 RPC 通信（如设备发起的服务端 RPC 调用）。
tb_core.notifications：用于集群节点间的系统通知和状态同步。
3. 分布式缓存与状态同步
为了在无状态的服务节点间共享设备状态、租户配置和会话信息，ThingsBoard 引入了分布式缓存层（通常基于 Redis 或 Caffeine + 广播机制）。
Cache Manager 逻辑：
源码中的 CacheManager 负责管理本地缓存（Caffeine）与分布式缓存（Redis）的一致性。当某个节点更新了设备属性或租户配置时，它会先更新数据库和分布式缓存，然后向 Kafka 发送一个“失效通知”或“更新事件”。
事件广播：
其他节点订阅该通知 Topic，收到消息后清除本地缓存中的对应条目。下次访问时，会从分布式缓存或数据库中重新加载最新数据。这种“写通过/失效”策略保证了集群数据最终一致性。
4. 规则引擎的集群调度
规则引擎是 ThingsBoard 最复杂的组件之一，在集群环境下的调度逻辑如下：
分区消费者模型：
每个 TB Node 启动时，会作为 Kafka Consumer Group 的一员订阅规则引擎相关的 Topic。Kafka 的 Rebalance 机制会自动将不同的分区分配给不同的节点。
异步处理链：
消息被消费后，进入规则链（Rule Chain）。源码中使用响应式编程模型（Reactor）或线程池来处理复杂的规则节点（Script, Filter, Transform）。如果某个节点负载过高，Kafka 的消费者滞后（Lag）会增加，此时可以通过增加 TB Node 实例来触发 Rebalance，将部分分区迁移到新节点，实现自动负载均衡。
5. 会话管理与 WebSocket 集群
对于前端 Dashboard 实时展示设备数据，ThingsBoard 需要处理 WebSocket 连接的集群问题。
会话注册中心：
当用户通过 WebSocket 订阅某个设备数据时，当前的 TB Node 会在分布式缓存（Redis）中注册该订阅关系：{userId_deviceId -> nodeId}。
消息路由：
当后端规则引擎处理完遥测数据并需要推送给前端时，它会检查缓存中的订阅关系。如果当前节点不是持有该 WebSocket 连接的节点，它会将推送请求通过内部消息总线转发到目标节点，由目标节点通过其本地的 WebSocket Session 发送数据给前端。
6. 集群发现与健康检查
Zookeeper/K8s Service Discovery：
在传统部署中，ThingsBoard 依赖 Zookeeper 进行集群成员管理和领导选举（Leader Election），特别是在处理定时任务（如清理旧数据、生成报告）时，确保同一时刻只有一个节点执行特定任务，避免重复执行。
健康探针：
每个微服务暴露 /health 端点，Kubernetes 或负载均衡器定期探测。如果节点失败，负载均衡器将其剔除，Kafka 消费者组触发 Rebalance，将故障节点的分区分配给存活节点，实现高可用。
总结
ThingsBoard 集群的核心逻辑在于“状态外置”与“消息有序”。通过将设备状态存储在 Redis/DB，将会话信息存储在分布式缓存，将业务逻辑无状态化，并利用 Kafka 的分区机制保证单设备消息的顺序处理，从而实现了高可用、高吞吐且易于水平扩展的物联网平台架构。
牛牛机器人 / 牛牛算账机器人版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！