ThingsBoard API限流终极指南：从令牌桶到漏桶算法快速掌握

ThingsBoard作为开源IoT平台，其API限流机制是保障设备管理、数据采集与处理稳定性的核心组件。本文将深入解析令牌桶与漏桶算法在ThingsBoard中的实现，帮助开发者快速配置和优化API限流策略。## 为什么API限流对IoT平台至关重要？在物联网场景中，成百上千台设备同时向平台发送数据是常态。若无合理的限流机制，可能导致：- 服务器资源耗尽，影响整体稳定性- 数据处理延

林菁琚

991人浏览 · 2026-03-02 02:54:38

林菁琚 · 2026-03-02 02:54:38 发布

ThingsBoard API限流终极指南：从令牌桶到漏桶算法快速掌握

【免费下载链接】thingsboard Open-source IoT Platform - Device management, data collection, processing and visualization. 项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard

ThingsBoard作为开源IoT平台，其API限流机制是保障设备管理、数据采集与处理稳定性的核心组件。本文将深入解析令牌桶与漏桶算法在ThingsBoard中的实现，帮助开发者快速配置和优化API限流策略。

为什么API限流对IoT平台至关重要？

在物联网场景中，成百上千台设备同时向平台发送数据是常态。若无合理的限流机制，可能导致：

服务器资源耗尽，影响整体稳定性
数据处理延迟，影响实时监控功能
恶意设备攻击导致服务不可用

ThingsBoard通过多层次限流策略解决这些问题，核心配置位于application/src/main/resources/thingsboard.yml文件中。

令牌桶算法：灵活应对突发流量

令牌桶算法是ThingsBoard主要采用的限流方式，其核心思想是系统以恒定速率生成令牌存入桶中，请求需要获取令牌才能被处理。

配置示例与参数解析

在ThingsBoard配置文件中，令牌桶通过capacity:duration对定义：

# 设备状态规则节点限流配置
rateLimit: "${DEVICE_STATE_NODE_RATE_LIMIT_CONFIGURATION:1:1,30:60,60:3600}"

这个配置表示：

每秒最多处理1个请求
每分钟最多处理30个请求
每小时最多处理60个请求

这种多维度限制允许短期突发流量，同时保证长期稳定性。

实际应用场景

在设备状态监控中，系统通过org.thingsboard.rule.engine.action.TbDeviceStateNode类实现令牌桶限流，防止监控请求过度占用资源：

String deviceStateNodeRateLimitConfig = ctx.getDeviceStateNodeRateLimitConfig();
rateLimitConfig = new TbRateLimits(deviceStateNodeRateLimitConfig).getConfiguration();

漏桶算法：平滑流量输出

漏桶算法则像一个有固定容量的桶，请求像水一样注入桶中，以固定速率流出。当请求量超过桶容量时，多余请求会被丢弃。

配置位置与使用场景

ThingsBoard在MQTT传输层实现了漏桶机制，防止大量连接请求冲击系统：

# MQTT传输层通用限流配置
rate_limits:
  # 启用IP级限流
  ip_limits_enabled: "${TB_TRANSPORT_IP_RATE_LIMITS_ENABLED:false}"
  # 最大无效凭证连接尝试次数
  max_wrong_credentials_per_ip: "${TB_TRANSPORT_MAX_WRONG_CREDENTIALS_PER_IP:10}"
  # IP封锁超时时间(毫秒)
  ip_block_timeout: "${TB_TRANSPORT_IP_BLOCK_TIMEOUT:60000}"

与令牌桶的区别与适用场景

算法	优势	适用场景
令牌桶	允许突发流量，灵活性高	API调用、设备状态更新
漏桶	流量输出稳定，可预测性强	MQTT连接、数据传输

多层次限流策略配置

ThingsBoard实现了从全局到租户级别的多层次限流：

1. 全局级别

在application/src/main/resources/thingsboard.yml中配置：

# WebSocket订阅限流
ws:
  rate_limits:
    # 每租户订阅限流
    subscriptions_per_tenant: "${TB_SERVER_WS_SUBSCRIPTIONS_PER_TENANT_RATE_LIMIT:}"
    # 每用户订阅限流
    subscriptions_per_user: "${TB_SERVER_WS_SUBSCRIPTIONS_PER_USER_RATE_LIMIT:}"

2. 租户级别

通过租户配置实现差异化限流：

// 租户级限流通知配置
.name("Exceeded per-tenant rate limits notification for tenant")
.name("Per-tenant rate limits exceeded")
.description("Send notification to tenant admins when some per-tenant rate limit is exceeded")

3. 设备级别

针对特定设备类型设置限流：

# 设备状态规则节点限流
deviceState:
  rateLimit: "${DEVICE_STATE_NODE_RATE_LIMIT_CONFIGURATION:1:1,30:60,60:3600}"

实战：配置与监控限流规则

步骤1：修改配置文件

编辑application/src/main/resources/thingsboard.yml，设置合适的限流参数：

# 邮件发送限流
mail:
  per_tenant_rate_limits: "${MAIL_PER_TENANT_RATE_LIMITS:1000:60,10000:3600}"

步骤2：通过UI监控限流状态

ThingsBoard提供直观的监控界面，可查看限流触发情况：

图：用于监控和控制设备通信的ThingsBoard widget界面，可集成限流状态显示

步骤3：处理限流事件

系统会自动记录限流事件，可通过以下日志查看：

// 日志记录示例
log.trace("[{}] Ignore alarm fetch due to rate limit: [{}] of maximum [{}]", 
          cmdId, alarmInvocationAttempts, maxAlarmQueriesPerRefreshInterval);

常见问题与解决方案

Q: 如何判断限流策略是否合理？

A: 监控关键指标如rate_limit_exceeded事件频率，调整参数使限流触发频率控制在0.1%以下。

Q: 令牌桶参数如何设置？

A: 遵循"80/20原则"，即80%的正常流量应低于限流阈值，为突发流量预留20%缓冲空间。

Q: 如何处理分布式环境下的限流？

A: 对于多节点部署，建议使用Redis等分布式缓存实现全局令牌桶，配置位于：

# Redis分布式缓存配置
cache:
  type: "${CACHE_TYPE:caffeine}"  # 改为redis启用分布式缓存
  rateLimits:
    timeToLiveInMinutes: "${CACHE_SPECS_RATE_LIMITS_TTL:120}"
    maxSize: "${CACHE_SPECS_RATE_LIMITS_MAX_SIZE:200000}"