答案：订单支付与库存同步需通过事务控制、锁机制和系统协调防止超卖。1. 用数据库事务保证扣库存与创订单原子性；2. 结合乐观锁（版本号）或悲观锁（FOR UPDATE）应对并发；3. 下单时冻结库存，支付成功后异步更新状态，可用消息队列解耦；4. 跨服务场景采用Seata、TCC或本地消息表+MQ实现分布式事务。中小系统用事务+乐观锁，大型系统结合消息队列与分布式事务框架保障一致性。
在Java开发中，订单支付与库存同步是一个典型的高并发场景，涉及订单系统、支付系统和库存系统的协同工作。如果处理不当，容易出现超卖、数据不一致等问题。要实现可靠的支付与库存同步，关键在于事务控制、锁机制以及系统间的协调。
1. 使用数据库事务保证一致性
最基本的保障是利用数据库的事务机制，在同一个事务中完成扣减库存和创建订单的操作。
示例流程：
- 用户提交订单时，开启一个数据库事务
- 查询商品库存是否充足
- 库存足够则扣减库存（update table set stock = stock - 1 where product_id = ? and stock > 0）
- 插入订单记录
- 提交事务；若任一步失败则回滚
注意：SQL中的where条件必须包含stock > 0，防止并发下负库存。
立即学习“Java免费学习笔记（深入）”；
2. 引入乐观锁或悲观锁应对并发
在高并发下单场景下，仅靠基础事务可能仍会超卖，需结合锁机制。
悲观锁：在查询库存时使用SELECT ... FOR UPDATE锁定记录，直到事务结束。适合写多读少场景，但性能较低。 乐观锁：通过版本号或CAS机制实现，如更新库存时判断原库存值是否未变：update product set stock = stock - 1, version = version + 1 where id = ? and version = ? and stock > 0。失败则重试，适合冲突较少的场景。3. 支付成功后异步更新库存状态
订单创建时已预占库存，支付成功后再真正扣减或释放。
典型流程：
- 下单时冻结库存（可用库存-1，冻结库存+1）
- 用户去支付，系统监听支付结果（可通过回调或轮询）
- 支付成功，调用服务解冻并确认扣减库存
- 支付失败或超时，触发库存回补
可借助消息队列（如RocketMQ、Kafka）解耦支付与库存服务，确保最终一致性。
4. 利用分布式事务框架保障跨服务一致性
当订单、库存、支付分布在不同微服务中时，需引入分布式事务方案。
- Seata：支持AT模式，对业务侵入小，可实现跨库事务回滚
- TCC模式：分为Try、Confirm、Cancel三个阶段，灵活但开发成本高
- 本地消息表 + MQ：将事务操作和消息发送放在同一本地事务中，由消费者保证后续操作执行
例如：下单服务在插入订单的同时写入一条待处理的“扣库存”消息，由消息系统保证库存服务最终执行扣减。
基本上就这些核心方法。关键是根据业务规模选择合适方案：中小项目用数据库事务+乐观锁即可，大型系统建议结合消息队列与分布式事务框架，确保高并发下的数据准确与系统可用性。
