QiWe开放平台 · 个人名片
API驱动企微自动化，让开发更高效
核心能力：为开发者提供标准化接口、快速集成工具，助力产品高效拓展功能场景
官方站点：https://www.qiweapi.com
团队定位：专注企微API生态的技术服务团队
对接通道：搜「QiWe 开放平台」联系客服
核心理念：合规赋能，让企微开发更简单、更高效
在自动化触达系统中，重复发送比不发送更严重。想象一下，原本智能的“服务提醒”因为网络抖动在 1 秒内连发三条，瞬间就会被用户标记为垃圾信息。
如何构建一个具备强幂等性的推送引擎？分享我们在大规模并发场景下的防御策略。
1. 业务侧的“幂等指纹（Idempotent Key）”生成
智能化推送的源头通常是业务事件。
策略：每一条推送请求在进入网关前，必须根据“业务场景+目标ID+时间窗口+内容特征”生成一个全局唯一的指纹（Fingerprint）。
技术实现：例如：
hash(scene_order_pay + group_id_001 + order_id_123)。这个 Key 将贯穿整个推送链路，成为该条消息的唯一身份证。
2. 基于 Redis 的“预检-占位”模式 (Set-NX)
在 API 调用层，我们引入分布式锁来拦截重复请求。
逻辑流程：
接收推送任务，提取幂等指纹 Key。
执行
SET key value NX EX [timeout]。如果返回成功：继续调用企微 API 发送消息。
如果返回失败：说明该任务已在处理中或已处理完成，直接丢弃当前请求。
关键点：超时时间（EX）需根据业务特性设定。对于瞬时防重，通常设为 5-10 秒；对于周期性任务（如日更），可设为更长。
3. API 响应状态的“持久化对照表”
API 调用结果的返回可能存在延迟，甚至请求发出了但没收到响应（Read Timeout）。
防重策略：建立一张
push_log表，记录每个幂等指纹的最终状态（Sending, Success, Fail）。对策：当重试机制（Retryer）启动时，首先查询该指纹的状态。如果数据库显示已发送成功，则跳过重试；如果状态未知，则通过企微提供的消息状态查询接口（如果可用）进行预检，而非直接二次重发。
结语
幂等性是高阶 API 开发的“必修课”。在智能化推送的语境下，“克制”比“触达”更难实现。通过指纹校验和分布式锁，我们可以确保系统在最复杂的网络环境下，依然能保持逻辑的优雅与精准。
