[{"createTime":1735734952000,"id":1,"img":"hwy_ms_500_252.jpeg","link":"https://activity.huaweicloud.com/cps.html?fromacct=261f35b6-af54-4511-a2ca-910fa15905d1&utm_source=V1g3MDY4NTY=&utm_medium=cps&utm_campaign=201905","name":"华为云秒杀","status":9,"txt":"华为云38元秒杀","type":1,"updateTime":1735747411000,"userId":3},{"createTime":1736173885000,"id":2,"img":"txy_480_300.png","link":"https://cloud.tencent.com/act/cps/redirect?redirect=1077&cps_key=edb15096bfff75effaaa8c8bb66138bd&from=console","name":"腾讯云秒杀","status":9,"txt":"腾讯云限量秒杀","type":1,"updateTime":1736173885000,"userId":3},{"createTime":1736177492000,"id":3,"img":"aly_251_140.png","link":"https://www.aliyun.com/minisite/goods?userCode=pwp8kmv3","memo":"","name":"阿里云","status":9,"txt":"阿里云2折起","type":1,"updateTime":1736177492000,"userId":3},{"createTime":1735660800000,"id":4,"img":"vultr_560_300.png","link":"https://www.vultr.com/?ref=9603742-8H","name":"Vultr","status":9,"txt":"Vultr送$100","type":1,"updateTime":1735660800000,"userId":3},{"createTime":1735660800000,"id":5,"img":"jdy_663_320.jpg","link":"https://3.cn/2ay1-e5t","name":"京东云","status":9,"txt":"京东云特惠专区","type":1,"updateTime":1735660800000,"userId":3},{"createTime":1735660800000,"id":6,"img":"new_ads.png","link":"https://www.iodraw.com/ads","name":"发布广告","status":9,"txt":"发布广告","type":1,"updateTime":1735660800000,"userId":3},{"createTime":1735660800000,"id":7,"img":"yun_910_50.png","link":"https://activity.huaweicloud.com/discount_area_v5/index.html?fromacct=261f35b6-af54-4511-a2ca-910fa15905d1&utm_source=aXhpYW95YW5nOA===&utm_medium=cps&utm_campaign=201905","name":"底部","status":9,"txt":"高性能云服务器2折起","type":2,"updateTime":1735660800000,"userId":3}]
之前完成了一个秒杀下单系统的开发,现在总结一下,
<>起因
业务场景是社区电商,
疫情期间,社区准备了一批口罩,打算分批让用户抢购。那时我们还在过年,客户也没通知我们,然后我们这个小电商系统,在当晚就挂掉了。下面是我们当时的架构:类似下面
稍微思考到这个架构的问题,用户下单时,redisson进行加锁时,会让其他线程等待。所以在并发大时,会导致tomcat连接数超限。后面查询日志也证明了如此,所以当时临时的解决方案是,重启+增加应用容器。总算勉强度过。
后面我们紧急改造了我们的业务j流程,变成了下面这样:
主要做了两点改变:
1.将查询库存放到了redis中
2.将实际的下单功能放到了,MQ应用中。
这样极大的提高了前端应用的承载能力,经实战测试 2万的口罩,3分钟内全部卖空,系统平稳运行。
首先先看一下我们现在具体的秒杀流程。
<>秒杀流程概览:
文字表述如下:
* 客户提交订单,包含多个商品
* 后台应用
* 对商品id加锁,
* 循环判断商品库存是否在redis中存在
* redis没有库存,从数据库查询库存,减去本次构购买数,放入到redis中
(如果库存不够此次贩卖,将数据库库存放入到redis中)
* redis中有库存,减去本次购买数,重新放到redis中。
* 解锁生成订单号,将本次订单信息发送到mq,异步消费
* 返回订单号,
* 客户端获取订单号,轮询查询订单状态。
* MQ消费应用
* 对商品,促销商品,优惠券,积分进行加锁
* 扣减优惠券,积分,生成订单,扣减库存,保存订单信息
* 将订单结果存入redis。解锁
* 完成实际下单
* 前端轮询查询订单是否下单成功
<>问题
看完整个详细流程,已经解决了主要的高并发问题,现在讲讲实际遇到的一些问题:
<>1.如果redis缓存被清空了怎么办?
因为我们公司目前将redis的作用就是缓存,所以当redis快满了时,运维会将redis进行清空。(虽然有做redis
内存淘汰侧率,但是主要是总有人使用redis时没设置redis的过期时间),所以redis缓存失效的情况,需要考虑,所以我们mq消费时,会重新加锁,如果发现库存不足,会将结果存入redis。前端通过oderNo轮询就知道订单失败。
<>2.库存不足
情景一 :提交两个商品,一个redis 库存够,另一个redis库存不够如何处理?
情景二:提交两个商品,一个在redis中有库存,但库存不足,另一个redis没有库存,需要从数据库查询,但库存足够本次购买:
答:这个我们处理思路是,判断是否超卖 循环中判断,但是所有redis存库存的操作,解锁前统一保存到redis。(我们是 redis
cluster,分片了不支持事务);
<>3.秒杀开始后能否修改库存?
这个当时我们是考虑到库存存到redis了,并设置过期时间,所以无论商家改大或者该小,都不会导致错误。但是,由于MQ消费消息,是有并发锁的,这个时候去看的库存,是不真实的,因为有许多订单是已经提交,但是没有落库。所以我们禁止了秒杀开始后修改库存