钉钉机器人消息幂等性怎么实现？如何防止重复通知？

钉钉机器人消息幂等性主要通过服务端记录唯一事件ID（event_id）并结合 Redis 或数据库唯一索引实现，防止因网络抖动或回调超时导致的重复处理。对于单用户定向推送，平台无自动去重保护，必须自行实现业务幂等逻辑。

先说结论：钉钉机器人消息去重需依赖业务服务端实现，平台仅在部分群发场景提供有限去重保护。

快速处理思路

若发现机器人重复响应或发送消息，优先检查回调接口的响应时间和去重逻辑。业务服务端需在接收到回调后 1500ms 内返回 HTTP 200 状态，避免触发钉钉服务端重试机制。对于耗时业务逻辑，采用异步队列处理，确保主线程快速释放。

消息重复主要源于网络波动、服务端重试机制及客户端展示缓存。钉钉为保证消息可达，在主回调失败或超时会进行重试，默认存在 3 次重试机制。若业务接口处理耗时超过 1 分钟未返回，或 POST 请求超过 1500ms 未响应，钉钉服务端会判定为失败并重新推送相同消息。

第一步：提取唯一标识。从钉钉回调请求中获取 event_id 字段，该字段在一次事件推送中全局唯一。

第二步：建立去重锁。使用 Redis 原子操作设置键值，建议采用三层复合键结构（事件 ID+ 用户 ID+ 参数哈希），设置过期时间为 24 小时。

def check_idempotent(key: str) -> bool:
    return redis.setnx(key, "processing", ex=86400)

第三步：异步执行业务。若 Redis 设置成功，立即返回成功响应给钉钉，将耗时操作（如调用大模型、写库）放入后台队列。

第四步：异常降级处理。当 Redis 不可用时，自动降级为本地内存缓存，有效期设为 5 分钟，防止服务完全不可用。

查看服务端应用日志，搜索同一 event_id 是否出现多次处理记录。若实现生效，同一 event_id 仅在首次出现时执行业务逻辑，后续重复请求应直接返回成功且不执行业务。监控消息发送频率，确认单用户在短时间内未收到重复内容。

单人定向推送无平台去重保护。使用 dep_id_list 或 is_to_all 群发时，同一天同一用户只会收到一条相同内容，但单人定向推送（只填一个 userid）没有此保护机制，需格外注意避免重复调用接口。

超时阈值需严格把控。钉钉 POST 请求有严格超时机制，必须在 1500ms 内返回 HTTP 200 响应，否则触发重试。部分场景下 execute 方法超过一分钟未返回也会重试，需确保主流程快速结束。

缓存过期时间设置不当。去重缓存过期时间过短可能导致误判新消息，过长则浪费内存。建议根据业务消息最大重复窗口设置，通常为 24 小时。

是正常机制。钉钉为保证消息可达，会在主回调后短时间内发送一次定时回调，以防网络失败漏传，需在业务代码中实现去重逻辑。

部分场景会自动去重。多人推送情况下，同一天只会收到一条相同的内容，但单人定向推送没有此保护机制。

不代表立马收到。接口调用成功仅代表请求被接收，根据系统拥堵情况收到时间可能会有一定的延迟。

自动降级为本地内存缓存。当 Redis 不可用时，使用本地内存缓存作为临时方案，有效期设为 5 分钟，确保服务不中断。