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