Azure Storage Queue实现及重复创建用户问题解决方案咨询

这个场景在分布式系统里太常见了——竞态条件导致重复发消息，加上Azure Storage Queue本身没有内置的消息去重机制，还没法直接查看队列内容，确实有点头疼。不过结合队列特性和业务逻辑，咱们可以从发送端、消费端两个层面来解决：

1. 消费端（Second Service）实现幂等性处理（最核心的方案） #

不管收到多少条同一用户的创建消息，确保用户只会被创建一次，这是最稳妥的底线：

• 双重检查+数据库唯一约束：处理消息时，先查询数据库是否已存在目标用户。如果存在，直接标记消息处理完成；如果不存在，执行创建操作。同时给用户表的唯一标识字段（比如邮箱、用户ID）加上数据库唯一约束，哪怕并发执行创建，数据库会抛出唯一键冲突异常，捕获这个异常后就可以直接结束处理，不用重试。
• 记录处理过的用户标识：可以在Redis或者数据库里维护一个“已处理用户”的集合，处理消息前先检查该用户是否在集合里，在的话直接跳过；处理完成后再把用户标识存入集合，设置和消息TTL一致的过期时间，避免冗余存储。

2. 发送端（First Service）减少重复消息的产生 #

从源头降低重复发送的概率，避免不必要的消息进入队列：

• 分布式锁+双重检查：First Service检查到用户不存在后，先获取一个针对该用户标识的分布式锁（比如用Azure Blob Lease、Redis锁），拿到锁后再次检查用户是否存在（防止在等待锁的过程中，用户已经被创建），确认不存在再发送消息，最后释放锁。这样同一时间只有一个服务实例能发送该用户的创建消息。
• 直接尝试创建用户：如果业务允许，First Service可以跳过“检查-发消息”的流程，直接尝试执行用户创建操作。如果创建成功（说明之前确实不存在），就不用发消息；如果失败（抛出唯一键冲突），说明用户已经被创建，也不用发消息。这种方式省去了队列的中间环节，从根源避免重复。

3. 利用Azure Storage Queue的消息特性辅助去重 #

虽然队列没法查看内容，但可以利用消息本身的属性来做标识：

• 自定义MessageId：发送消息时，把用户的唯一标识（比如用户ID）作为MessageId传入。Second Service处理消息时，记录已经处理过的MessageId（存入Redis或数据库），如果该ID已存在，直接跳过处理。注意要给记录设置过期时间，和消息的TimeToLive保持一致，避免存储无效数据。

最后补充一句：这些方案里，消费端的幂等性是基础，哪怕发送端没做好，消费端也能兜底；如果能结合发送端的锁机制，基本就能杜绝重复消息的问题了。

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