云端下行指令的超时与幂等设计
支持四象限运行、采用 FOC 驱动方式的 AQMD6008BLS-TE/2 这类机型会被云端下发启停、复位、参数写入等指令。下行链路最危险的不是发不出去，而是"超时了但其实执行成功"，重试之后设备被反复启停。
一、超时窗口与真实执行时间不匹配
阿里云物联网平台的 RRpc 接口用于服务端请求设备并同步获取响应：调用后若设备未在设置的 Timeout 内反馈，即使设备收到了消息，云端也视为发送失败；Timeout 取值范围为 1000~8000 毫秒；单个账号调用该接口的 QPS 上限为 1000。
算例：一条"参数写入并落盘"的指令。
| 环节 | 耗时 | 说明 |
|---|---|---|
| 云端下发到设备 | 50~300 ms | 移动网络抖动大 |
| 设备执行（写 Flash） | 2000 ms | 擦写与校验 |
| 设备回复上行 | 50~300 ms | 与下发同量级 |
| 总耗时 | 约 2.1~2.6 s | 与 Timeout 比较 |
若 Timeout 设 1000ms，则必然超时，但设备已执行成功。此时云端重试，设备就会二次写入。判据很清晰：Timeout ≥ 设备最坏执行时间 + 2×网络往返，本例应设 4000~5000ms，而不是用默认短超时。
二、幂等：用 nonce 去重
所有下行指令带唯一 ID，设备侧维护去重窗口：
```c
/ 指令幂等：同一 nonce 只执行一次，重复下发返回上次结果 /
define DEDUP_SLOTS 16
typedef struct { uint32_t nonce; uint8_t done; uint8_t result; } dedup_t;
static dedup_t g_dedup[DEDUP_SLOTS];
int cmd_execute(uint32_t nonce, const uint8_t payload, uint32_t len)
{
for (int i = 0; i < DEDUP_SLOTS; i++) {
if (g_dedup[i].done && g_dedup[i].nonce == nonce)
return g_dedup[i].result; / 重复指令，直接回上次结果 /
}
int r = do_cmd(payload, len); / 真正执行 */
uint32_t idx = nonce % DEDUP_SLOTS;
g_dedup[idx] = (dedup_t){ nonce, 1, (uint8_t)r };
return r;
}
配合两点：设备回复必须携带原 nonce，云端据此对账；对"启停"这类不可重复动作，除幂等外还要做状态前置校验（已在运行则不再启动）。
|##三、下行侧的其他约束
除 RRpc 外，若用服务端订阅回传结果，AMQP 侧的限制要一起算：一个连接限流 1000 TPS，可通过增加连接数扩容（最多 128 个连接）；堆积消息推送限流 200 TPS；消息保存时长 1 天，超过则丢弃。设备侧下行能力也有上限：单设备下行接收限制为 50 条/秒，若网络 TCP 写缓冲拥堵会直接返回错误，因此批量下发必须限速。
四、验证方法
一是延迟注入：用网络仿真给设备侧加 2~4s 延迟，确认云端不再误判失败、且不产生重复执行；二是重复下发：同一 nonce 连发 5 次，核对设备只执行一次并返回一致结果；三是断电对账：指令执行后立刻断电，重启后确认状态与云端记录一致（必要时补一次状态上报）。
五、小结
下行指令的三个必做项：Timeout 按"最坏执行时间+2×往返"设定（RRpc 允许 1~8s），指令带 nonce 做幂等去重，批量下发按 50 条/秒限速。超时不等于失败，必须用 nonce 对账而不是盲目重试，并用延迟注入与重复下发测试闭环。
