略难的题，因为你要掌握两个东西：状态流转和对应的补偿任务。

那么很多人在听到这个问题的时候，第一个念头就是我执行一条 INSERT 语句不就好了？这样回答就肯定寄了，因为在微服务架构下，你要考虑到订单是一个服务，库存是另外一个服务，你得保证创建订单-锁定库存一起成功或者一起失败。

略难的题，这个地方非常适合装逼。

常规的方案无非就是使用双 Kafka 集群，勿论哪个发成功了都可以。但是要装逼就要讨论两个奇诡的做法，一个是将秒杀看做是一个类似于抽奖的过程，随机拒绝掉一部分人；另外一个就是直接去掉 Kafka，也不是不可以。

简单题，你从消息队列里面都能猜到这个就是为了削峰的。

但是如果你想在这里刷亮点，那么就要讨论深入揭示消息队列甚至不能看做是必须的，进而讨论到消息队列崩溃之后的容错问题。

简单题，但是是一个陷阱题。

那如果你要是秒杀系统是捏出来的项目经验，或者是面试官凭空考察你秒杀系统，你就容易被这个问题问倒。

简单题。面试官的意思是在秒杀架构里面，你都已经用了 Kafka 等消息队列了，消费者的消费过程都是异步的，用户怎么知道消费者最终有没有创建订单成功呢？

其实说白了两个字：轮询。不过你要想刷亮点，就还要进一步回答轮询也不会引发什么性能问题。

简单题，一句话就能说清楚：想 P 吃。

想象一个最简单的例子，如果秒杀活动根本没人来，你卖给谁？卖给鬼么？

那么当然面试官可能会进一步追问，要是一直有人来参加秒杀呢？很显然，这还用怀疑吗？一直有人买东西你还卖不完吗？

难题，至少对于很多人来说是一个难题，不过实际上这是一个送分题。

你几乎可以预料到但凡是讨论交易流程，那么超卖就是一个大概率要问到的问题。回答这个问题，你要记得总结出来一个规律：绝大多数情况下，所有的超卖问题几乎都依赖于数据库维护正确的库存信息，Redis 只是用作一个缓存，是一个可以容忍短时间不一致的东西。

中等难度的题，一个典型的部分失败场景题。

一句话总结就是失败了就当做是秒杀失败。大部分人在这个问题下会提到引入重试机制，但是这没有抓住重点，因为面试官会进一步追问你，如果要是重试都失败了，怎么办？

所以你在面试中可以回答重试，但是不能只回答重试，要进一步回答重试都失败了，该如何处理。

难题，一方面是在正常的系统设计中，其实很少考虑 Redis 崩溃之后应该如何解决，基本都是假设 Redis 是一个高可用的，几乎不会崩溃。另外一方面则是 Redis 是秒杀中的一个比较重要的环节，很多人从来没思考过万一 Redis 崩溃了怎么办。

这个问题的装逼方式有两个：一个是揭示出 Redis 承担的预扣库存这个步骤并不是必不可少的；另外一个则是揭示在秒杀的时候，可以引入随机过程来直接返回秒杀失败的响应。

简单题，主打一个出其不意。

正常来说，在接触秒杀系统的时候我们都会认为 Redis 预扣库存是一个天经地义的事情，所以没有怎么思考为什么要有这个步骤，遇到这个问题就有点不知道怎么回答了。