1. 秒杀场景下抢购流程分析
      假设每天晚上8:30都有一个秒杀活动，那么在8:30之前，实际上大量的用户 (几十万上百万) 会集中登录到APP上，同时访问这个秒杀活动的商品页面。
      8:30一到，页面上会让一个不能点击的灰色的立即抢购按钮变成可以点击的状态。瞬间可能几十万上百万人会同时点击这个按钮。
      在这个过程中，大家要做的是跟之前一样购买商品的操作，下单、支付、减库存。
      如果按照之前的策略，让所有请求都访问到订单系统以及订单数据库，不可避免地会导致订单系统和数据库压力过大。

    2. 用答题的方法避免作弊抢购以及延缓下单
      肯定会有人写作弊的脚本或软件疯狂的发送请求去抢购商品，所以一般来说参与抢购，再点击按钮之后先进行答题，然后再发起抢购的请求。
      这个办法可以避免一些作弊软件发送抢购请求，不同的人答题速度也是不一样的，可以让发送请求的时间错开。

    3. 为秒杀独立出来一套订单系统
      如果秒杀订单请求和普通下单请求都由一套订单系统来承载，可能会导致订单系统不稳定。
      一般会对订单系统部署两个集群，一个秒杀订单集群，一个普通订单集群。

    4. 基于Redis实现下单时精准减扣库存
      秒杀商品一般是有数量限制的，大量请求到达后台系统之后，首先第一步就可以先去减库存。
      如果直接由订单系统调用库存系统的接口，访问库存数据库去扣减，必然导致瞬时压力过大。
      通常在秒杀场景下，会将商品库存提前写入Redis，请求到来之后直接对Redis的库存进行扣减。
      Redis可以轻松单机抗每秒几万并发。

    5. 抢购完毕后过滤掉无效请求
      Redis库存被扣减完之后，后续请求就没有必要发送到秒杀系统中了。
      此时可以让Nginx在接收到后续请求的时候将请求过滤掉。
      大幅度减少对后端秒杀系统的请求压力。

    6. 瞬时高并发下单请求进入RocketMQ进行削峰
      秒杀成功后需要生成一个订单，此时直接发送一个消息到MQ中即可。
      然后让普通订单系统从MQ消费秒杀成功的消息进行常规性流程处理即可。

    架构优化的核心：避免高并发请求落在Mysql上。