如何处理多EC2实例与Cron作业下的重复账单收费问题

核心解决方案 #

1. 合理配置SQS可见性超时 #

• 当EC2消费者从队列获取消息后，SQS会将该消息设为不可见状态，这段时间即为可见性超时。需将超时时间设置为长于单次收费操作的最大耗时（比如收费最长需10分钟，就设为15分钟），确保操作完成前其他消费者无法获取该消息。
• 如果收费操作可能超时，可在执行过程中调用ChangeMessageVisibility API动态延长可见性时间，避免消息提前重回队列被重复消费。

2. 实现收费操作的幂等性（兜底关键） #

即使消息被重复投递，也要保证同一发票不会被重复收费，这是必须的兜底方案：

• 为每个发票的收费操作生成唯一幂等键（例如：发票ID_charge的哈希值，或直接用发票ID+操作类型）
• 执行收费前，先检查数据库中是否存在该幂等键的执行记录，或检查发票的收费状态是否已标记为完成
• 若已存在记录/状态完成，直接跳过收费逻辑；若不存在，执行收费后立即记录幂等键和更新发票状态
• 可通过数据库唯一约束强化：创建charge_executions表，将idempotency_key设为唯一索引，插入成功再执行收费，插入失败则判定为重复操作。

3. 切换到SQS FIFO队列或使用消息组ID #

• FIFO队列：如果业务允许严格的顺序处理，直接改用SQS FIFO队列。FIFO队列保证消息按顺序交付，且同一时间同一消息只会被一个消费者获取，从根源上减少重复并发处理的可能（注意FIFO队列仍可能有至少一次投递，所以幂等性还是需要）。
• 标准队列+消息组ID：若无法切换FIFO，给同一发票的消息设置相同的MessageGroupId，SQS会保证同一组的消息被顺序处理，同一时间只有一个消费者处理该组消息，降低重复消费概率。

4. 优化消息确认逻辑 #

• 仅当收费操作完全成功（包括数据库状态更新、第三方支付接口调用成功等所有步骤完成）后，再调用DeleteMessage API删除队列中的消息。
• 若操作失败，不要删除消息，让其重新回到队列等待重试；同时可配置死信队列，将多次重试失败的消息移入死信队列，避免阻塞正常消息。

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