无服务器函数（AWS/Azure）并发问题：队列重复消息去重方案咨询

你的问题核心是check-then-set操作的竞态条件——多实例部署时，两个进程可能同时通过check_in_progress检查，导致重复执行do_work。以下是几种实用的解决方案：

1. 用分布式锁实现原子性"检查+标记" #

把原来的两步操作（检查是否在处理、标记为处理中）替换成原子性的分布式锁操作，从根源上消除竞态。比如用Redis的SET命令实现：

# 伪代码示例：Redis原子锁
lock_key = f"processing:{uniqueId}"
# SET命令仅当key不存在时才设置成功，同时设置过期时间防止死锁
lock_acquired = redis_client.set(lock_key, "locked", nx=True, ex=30)

if not lock_acquired:
    raise Exception("任务已在处理中")  # 跳过重复任务
try:
    do_work()
finally:
    redis_client.delete(lock_key)  # 处理完成后释放锁

这种方式无需依赖业务数据库，锁操作是原子的，多实例下只会有一个进程能成功获取锁。注意设置合理的锁过期时间，要覆盖do_work的最长执行时间，避免锁提前过期导致重复处理。

2. 利用队列服务本身的特性 #

很多成熟队列服务自带防重复处理机制，无需额外开发：

• 消息可见性超时：比如AWS SQS、阿里云MQ等，实例获取消息后，消息会被标记为"不可见"状态（持续一段时间），这段时间内其他实例无法获取该消息。处理完成后调用API删除消息；若处理失败/超时，消息会自动恢复可见性，重新进入队列。
• 哈希路由分配：部分队列支持按消息ID哈希路由，将同一uniqueId的消息固定分配给同一个消费者实例，避免多实例同时处理同一条消息。
  这种方式直接利用队列原生能力，降低系统复杂度。

3. 原子化数据库更新（无需唯一约束） #

如果倾向用数据库但不想修改现有表结构，可以单独建一张处理状态表（比如processing_status），仅存uniqueId和status字段，用带条件的UPDATE语句实现原子检查和标记：

UPDATE processing_status 
SET status = 'in_progress' 
WHERE uniqueId = ? AND status != 'in_progress';

执行后查看影响行数：

• 影响行数为1：成功拿到处理权，继续执行do_work
• 影响行数为0：该ID已在处理中，直接跳过
  UPDATE是数据库级原子操作，多实例下不会出现竞态，且单独的状态表不会干扰业务表结构。

4. 幂等性兜底设计 #

即使前面的防重复机制失效，确保do_work本身是幂等操作，避免重复执行的副作用：

• 写操作：用INSERT ... ON DUPLICATE KEY UPDATE替代普通INSERT，或更新时基于唯一条件（比如UPDATE table SET count = count +1 WHERE uniqueId = ?）
• 外部调用：记录已调用的uniqueId，调用前先检查；或给外部接口添加幂等标识，让对方重复调用也不会产生重复结果
  这是最后一道防线，配合前面的锁/队列机制使用，能最大化降低重复处理的影响。

内容的提问来源于stack exchange，提问作者Tadija Bagarić