定时任务延迟引发订单发货请求重复，如何实现精准去重？

核心问题很明确：定时任务60秒执行一次，但部分任务耗时70秒，导致前序任务没跑完新任务就启动，同一订单被重复发请求。下面逐个拆解你提出的方案，再给你最优组合建议：

各方案优缺点拆解 #

1. DynamoDB加处理标记 #

• 逻辑：处理订单前先查标记，有标记就跳过；开始处理时写入标记，完成后更新状态
• 好处：DynamoDB是持久化存储，标记不会因为重启或缓存故障丢失；支持强一致性读，能准确判断订单是否处于处理中
• 注意点：必须用原子操作，比如通过ConditionExpression确保只有当标记不存在（或状态为待处理）时才写入，避免并发场景下的重复标记；处理失败时要记得清理或重置标记，比如加TTL自动过期，或失败重试时改回待处理状态

2. 缓存临时存处理结果（10分钟过期） #

• 逻辑：处理完成后把订单ID存入缓存，下次任务先查缓存，命中则直接跳过
• 好处：读写速度远高于数据库，实现简单；TTL自动清理过期数据，无需手动维护
• 短板：缓存是临时存储，服务重启或缓存集群故障会丢失数据，可能引发重复处理；且只能判断「已处理完成」，无法识别「正在处理中」的订单，并发场景下仍可能出现重复请求

3. 用SQS/SNS存已处理订单（去重可行性） #

直接说结论：完全不合适。
SQS/SNS的核心定位是消息传递，而非状态存储。虽然SQS有消息去重功能，但仅用于过滤重复投递的消息，不是用来查询「订单是否已处理」的。每次判断都去查询队列，效率极低，且队列的设计逻辑不支持这类状态查询场景，性能和易用性远不如缓存或数据库。别用消息队列做状态存储和去重判断。

4. 把任务间隔改成2分钟 #

• 逻辑：让执行间隔（120秒）大于当前最大任务耗时（90秒），避免并发执行
• 好处：零开发成本，无需修改业务逻辑
• 短板：治标不治本，未来若任务耗时超过2分钟（比如第三方接口超时、系统负载飙升），仍会出现重复请求；且拉长间隔会增加发货请求的延迟，影响用户体验

最优组合：DynamoDB原子标记 + 缓存辅助 #

要兼顾易实现、高性能和可靠性，推荐这个组合方案：

1. 核心逻辑依赖DynamoDB：
   • 创建一张订单处理状态表，字段至少包含order_id（主键）、status（枚举：待处理/处理中/已完成）、ttl（设置24小时自动过期）
   • 处理订单前，用原子更新操作尝试将status从「待处理」改为「处理中」，仅当更新成功时才执行发货请求（通过DynamoDB的UpdateItem配合ConditionExpression实现）
   • 处理完成后将status改为「已完成」；若处理失败，可重置为「待处理」重试，或保留「处理中」并触发告警人工介入
2. 缓存做性能优化：
   • 处理完成后，将已处理的order_id写入缓存，TTL设为10分钟
   • 下次任务执行时先查缓存，命中则直接跳过；未命中再查询DynamoDB
   • 缓存作为快速过滤层，减少DynamoDB的查询压力，提升整体处理性能

额外优化建议 #

• 如果使用分布式定时任务框架（如Quartz、Airflow），直接开启任务互斥或分布式锁，确保同一时间只有一个实例执行该任务，从根源避免并发执行
• 发货请求本身要做幂等处理：就算极端场景下（比如DynamoDB故障）出现重复请求，第三方接口也要能识别同一订单的重复请求并拒绝处理，这是最后一道防重保险

内容的提问来源于stack exchange，提问作者cunning_of_desires