1.判断库存大于 0 可不是乐观锁。实现超卖的原理：判断库存大于 0 和加锁。一条 SQL 已经能完成这个功能，避免超卖了。任何一条「写 SQL」MySQL 都会加锁的，所以不存在纯粹的乐观锁。 用 Redis 来扣减库存，主要是从性能上考虑。但是用了 Redis 就不能假设数据一定不会丢，因为它不能保证像 MySQL 一样的 ACID。虽然通过 lua 脚本保证了执行的串行化，但假设宕机了，lua 脚本没执行完或者数据丢了，很可能会有超卖问题。 要分清楚 lua 脚本的原子性和 MySQL 原子性要求是不同的。lua 的原子性保证多条命令连续地串行化执行，但是当执行失败的时候，不会回滚。MySQL 的原子性可以保证全部执行成功和全部执行失败 2.订单超时这块。其实从面试官的问题来看，他对监听 Redis key 过期这种实现是不满意的。因为也引导你 Redis 过期超时的底层原理。主要通过「惰性删除+定期删除」实现的。定期删除是通过采样的方式找到过期 key，而订单又这么多，很多订单没法及时地超时。还要考虑 Redis 被打挂的问题，虽然有 AOF + RDB，但是数据依然会丢一部分的，因为 Redis 的「持久性」没有像 MySQL 一样这么高的要求。 时间不准+数据会丢。使用 Redis 不是合适的选择。所以考虑其他过期删除方案，比如 MQ 实现订单超时（面试官可能认为这个更加合理，后面也问到你这个） 3.异步处理订单，还是得看看具体的业务场景。这项目好像是关于飞机买票的？用户肯定希望点击买票后，立即弹出一个订单。如果异步去创建，那无法立即返回，该用什么方式通知用户创建订单了呢？发短信？用户还得回过头打开 app 来支付。而且创建订单本身并不耗时，直接同步返回就好了，然后让用户付钱。 可以采用同步创建订单，异步扣减库存。因为扣减库存可能需要花点时间，这部分就可以做异步。扣减成功，发个短信通知；扣减失败，发短信+退款。