3.3 抢卷业务通过lua脚本+RabbitMq实现抢卷逻辑

在实现lua脚步的时候本质上是有风险的，因为redis并不是完全可靠的比如生成的订单和扣减的库存都往里面丢，假如redis出问题了数据是有可能会丢失掉的，那么这个怎么解决呢？我们在redis判断库存同时异步的修改数据库。
当客户端大量的抢卷请求，请求抢卷服务去扣减redis的优惠券库存，在写到mq中，由优惠券服务去监听mq，然后修改数据库优惠券的库存，生成优惠券的领取记录。
疑问：那最后不还是操作了数据库嘛？
这个操作数据库和上层mq进行了解耦，mq在这里有两个作用：1.请求销锋-- 通过redis的方式来进行库存的判定横跨，假设请求量很大的时候redis都有很好的性能，就算单个redis运行不过来，也可以集群的。但是下游优惠券服务是实打实的录数据库的，性能肯定是赶不上抢卷服务的。这也导致上游处理请求块，下游处理请求慢。因此我们通过mq来请求销锋来做到缓冲的作用。如果想要上下游处理请求的速度都一样的话，就可以用请求销锋。请求销锋所带来的代价是拉长用户请求的时间，其实也就是用时间换性能。如果不用请求销锋的话只能集群但是这个集群是按什么频率搭建，是按平时请求的搭建双11就抗不住了，如果是按平时搭建就会浪费资源。
第二个作用保证数据的一致性：
这个时候我们生成的领券记录也就是订单不玩redis存，redis只管库存，假设抢卷成功了，扣减了一个库存，这个消息往mq里面丢，假设redis崩溃了，领取记录丢失了，也不会产生什么影响，因为这个消息已经通过mq发到了下游改了数据库，只要保证mq这个消息是安全可靠就好了，