设备上报限流与容量规划的算例
额定 25A（峰值 40A）、采用 FOC 驱动方式的 AQMD6030BLS-E2 这类机型，接入云后往往想多报几个量：母线电压、相电流、结温、故障码。上报频率一上去，最先撞到的不是存储，而是限流。
一、三层限流要分开算
阿里云物联网平台的使用限制里，与上报直接相关的是三个层级：单设备上报上限 QoS0 为 30 条/秒、QoS1 为 10 条/秒；单设备下行接收限制 50 条/秒；单账号每秒最大 MQTT 连接请求数 500、每秒设备端向平台发送请求数 10000。实例侧还有规格限制，新版公共实例默认固定规格为同时在线设备数 50 个、最多创建设备数 500 个、消息通信 TPS 5 条/秒、消息转发 TPS 5 条/秒、OTA 升级次数 10 次/自然月。
算例：500 台驱动器，每台每 10s 上报一次（QoS1）。
| 项目 | 数值 | 判据 |
|---|---|---|
| 单设备频率 | 0.1 条/秒 | 远低于 QoS1 的 10 条/秒 |
| 集群总上行 | 50 条/秒 | 远低于账号 10000/秒 |
| 公共实例 TPS 需求 | 50 TPS | 远超 5 TPS，必须企业版 |
| 若改为每台 1s 上报 | 500 条/秒 | 单设备仍合规，实例规格需 500+ TPS |
结论很直接：单设备怎么都合规，实例规格却差 10 倍。上线前必须按"设备数×频率"算实例 TPS，而不是只盯单设备限制。
二、用合并与变化上报压掉数量
同一时刻的多个量应合并成一条属性上报，而不是每个属性一条消息。取 8 个属性：
- 逐条上报：8 条/次 → 500 台×0.1Hz×8 = 400 条/秒
- 合并上报：1 条/次 → 50 条/秒，降到 1/8
再加变化量上报（超过死区才报），稳态工况可再降一半以上。注意物模型属性上报会按时间戳形成历史数据，且上报数据的时间戳必须在未来 24 小时范围内，超出则上报失败，所以缓存补报要校验时间戳有效性，别把过期数据塞进队列。
```c
/ 死区 + 合并：仅变化超阈值的属性进入本次上报 /
typedef struct { float last, deadband; uint8_t dirty; } prop_t;
void prop_update(prop_t *p, float v)
{
if (fabsf(v - p->last) >= p->deadband) { p->last = v; p->dirty = 1; }
}
/ 组装一条批量属性消息，避免每属性一条 /
int prop_batch_post(void dm, const char json)
{
return aiot_dm_send_property_post(dm, json); / 一次发送多个属性 /
}
三、存储侧的 IOPS 预算
若开启时序数据存储，写入行数也要预算：实例的时序数据存储 IOPS 为每秒写入与读取的所有数据行数之和，默认按 90% 写、10% 读划分。取 500 台×1 行/10s = 50 行/秒写入，需要 IOPS 约 56（按 90% 写比例反推），量级不大；但若改成 1s 粒度且不合并，写入行数升到 4000 行/秒，IOPS 需求随之放大近 80 倍，成本会突然抬头。
四、验证方法
用压测工具按目标设备数与频率模拟上行，观察是否触发限流并核对云监控告警（平台对每秒连接请求、发布请求、规则引擎请求等都有系统事件报警）；对比合并前后的消息条数与账单；检查补报数据的时间戳是否被拒。
五、小结
限流要分三层算：单设备（QoS1 10 条/秒）、账号（10000 请求/秒）、实例规格（TPS 与 IOPS）。多数项目死在实例规格而非单设备限制。手段是合并上报、死区变化上报与合理粒度，并用压测与云监控闭环。
