销售网站RDS数据库升级期间如何解决并发下单写入冲突问题

• 改用SQS FIFO队列按商品维度做消息保序
  将现有普通SQS替换为FIFO队列，发送下单请求时把商品ID作为MessageGroupId参数传入。AWS SQS会保证同一个分组ID下的消息严格按发送顺序消费，不会出现用户B的同商品下单请求比队列中更早的用户A请求先处理的情况，FIFO队列相比普通队列仅增加极少量成本，不需要引入额外组件。
• 数据库层增加乐观锁校验逻辑
  修改库存扣减的SQL语句为带条件判断的原子操作：

UPDATE goods SET stock = stock - 1 WHERE goods_id = #{商品ID} AND stock > 0

执行后根据影响行数判断是否扣减成功，即使出现消费顺序异常的场景，也能从底层避免超卖，完全无额外成本。

• 调整流量拦截逻辑，避免双路径请求
  你当前的逻辑是数据库无法连接时才把请求写入SQS，这就导致升级过程中存在部分请求走正常数据库路径、部分请求走队列的情况。可以调整CloudWatch触发Lambda的逻辑：触发RDS升级操作的同时，临时把API网关的所有下单请求全部切入SQS排队，直到Lambda检测到RDS恢复正常再切回正常处理路径，所有下单请求统一按顺序消费，从根源消除并发冲突。
• 异常兜底补偿逻辑
  在消费SQS消息扣减库存失败时，保留请求的原始下单时间戳，对比当前商品最后一次库存扣减的时间，如果当前排队的请求下单时间更早，可以给用户发送补偿通知（如优先补货资格、无门槛优惠券等），优化用户体验。

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