如何检查DELETE API是否被调用？类Amazon SQS分布式队列实现问询

嘿，这个问题正好戳中了分布式队列消息确认机制的核心痛点，我来分享几个生产环境中常用的实现思路，都是类似SQS这类成熟队列的设计思路：

1. 给消息分配唯一ID，用状态存储追踪生命周期 #

• 每条消息生成一个全局唯一的message_id，同时维护一个状态存储（可以用Redis、MySQL或者分布式KV存储），记录消息的当前状态：
  • IN_MAIN_QUEUE：在主队列待投递
  • IN_INVISIBLE_QUEUE：已投递到用户，暂存不可见队列等待确认
  • DELETED：已通过DELETE API确认删除
• 当你把消息从主队列投递给用户并放入不可见队列时，原子性地更新状态为IN_INVISIBLE_QUEUE，同时记录当前的投递次数、可见性超时时间。
• 收到DELETE请求时，要求用户传入message_id（或者更安全的receipt_handle，后面会说），系统根据这个标识找到对应消息，把状态更新为DELETED，并清理不可见队列中的该消息。
• 重投任务定期扫描不可见队列时，先查状态表：如果状态是DELETED，直接忽略；如果还是IN_INVISIBLE_QUEUE且超时，就累加重投计数，达到阈值就丢弃，否则放回主队列。
• 注意：状态更新一定要用原子操作，比如Redis的HMSET结合WATCH，或者数据库的事务，避免并发导致的状态不一致。

2. 使用绑定投递会话的receipt_handle（SQS同款思路） #

• 每次将消息从主队列投递到用户时，生成一个唯一的receipt_handle，这个handle是和当前这次投递会话绑定的，里面可以包含message_id、投递次数、过期时间等信息（可以加密防止伪造，比如用HMAC签名）。
• 用户调用DELETE API时必须携带这个receipt_handle，系统收到请求后：
  1. 先验证handle的合法性（比如检查签名是否有效、是否过期、是否对应当前处于不可见状态的消息）
  2. 验证通过后，标记该消息的这次投递已确认，直接从不可见队列中删除该消息，同时更新状态为DELETED。
• 这种方式比直接用message_id更安全，因为同一个消息的不同投递会话会生成不同的receipt_handle，避免用户误删其他投递的消息，也能防止恶意伪造请求。

3. 延迟任务+超时触发验证 #

• 当消息放入不可见队列时，同时创建一个延迟任务，延迟时间就是你设定的「可见性超时时间」。
• 如果在延迟任务触发前收到了DELETE请求，就取消这个延迟任务，并清理不可见队列中的消息。
• 如果延迟任务按时触发了，就先检查该消息是否已经被删除（通过状态表或receipt_handle验证）：
  • 若已删除：直接结束任务
  • 若未删除：执行重投逻辑（累加计数，放回主队列或丢弃）
• 这种方式可以利用现有延迟队列组件（比如Redis ZSet、RocketMQ延迟消息）来实现，不需要额外的定时扫描任务，性能更优。

• 幂等性：DELETE API要支持幂等，同一个receipt_handle多次调用不能重复删除或导致状态异常，可以通过记录已处理的handle来实现。
• 分布式一致性：如果用数据库做状态存储，要保证状态更新和队列操作的原子性，比如用本地事务或者分布式事务（如果跨多个组件的话）。
• 性能优化：状态存储尽量用内存型数据库（比如Redis），减少磁盘IO，提高重投任务的扫描效率。

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