高并发秒杀系统优化

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/DoUUnderstand/article/details/78484729

首先我们要清楚,高并发发生在哪些部分,然后正对不同的模块来进行优化
红色为高并发对性能影响较大的部分。
这里写图片描述


1.详情页部署到CDN节点上

用户在秒杀开始之前,会对详情页做大量的刷新操作。
所以我们将详情页部署到CDN上,CDN将详情页做静态化处理。
这样其实用户访问的静态页的html已经不在秒杀系统上了,而在CDN节点上。
这里写图片描述
其实访问静态资源和静态页面是不用访问我们的系统服务器的,所以我们要单独做一个请求来获取服务器的时间,这样保证CDN和秒杀系统服务器的秒杀开始时间同步。

PS:什么是CDN?
这里写图片描述

(1)CDN本质用于加速用户获取数据,这个数据可以是静态资源,也可以是动态资源,取决于我们的推用策略。甚至大部分视频加速依赖于CDN。
(2)一般运营商的CDN部署都是在离用户最近的网络节点上。
(3)命中CDN之后不需要访问后端服务器。

所以秒杀系统访问详情页的HTML CSS JS信息是不用访问服务器的。


2.秒杀地址接口使用服务器端缓存,Redis

随着时间推移,开始秒杀,到秒杀关闭,这都是秒杀地址给我们的数据。这部分适合使用服务器端缓存,Redis或者早期的Memcache。
这样他就可以抗很高的QPS,官方数据10W/s的QPS。 Redis集群化之后可以抗更高的QPS.
这里写图片描述
这里写图片描述


3.秒杀操作优化

难点分析:
1.大部分写的操作和核心操作无法使用CDN
2.不可能在缓存中减库存,你在redis中减库存,那么其他用户也可能通过缓存来减库存,这样库存会不一致,所以要通过mysql的事务来保证一致性
3.比如一个商品所有人都在抢,那么会在同一时间对数据表中的一行数据进行大量的update set操作。
这里写图片描述
解决方案:
目前常用的一个方案架构:
这里写图片描述
(1)用redis或者NoSQL实现一个原子的计数器,这个原子计数器就用来记录这个商品的库存,当你秒杀到一个商品时,原子计数器就减一。可以保证原子性。
(2)减库存成功后,就会记录其行为,也就是谁减了库存。记录下来之后,作为一个消息放到一个分布式的MQ(消息队列)之中。比如RabbitMQ ,RocketMQ,ActiveMQ,Kafka.
(3)消息放到MQ中之后,后端的服务会去消费这个消息并落地,存放到MySQL中。

这就是服务层拦截(反正就是不要让请求落到数据库上去)

服务层怎么拦截?大哥,我是服务层,我清楚的知道小米只有1万部手机,我清楚的知道一列火车只有2000张车票,我透10w个请求去数据库有什么意义呢?没错,请求队列!
对于写请求,做请求队列,每次只透有限的写请求去数据层(下订单,支付这样的写业务) 1w部手机,只透1w个下单请求去db
3k张火车票,只透3k个下单请求去db 如果均成功再放下一批,如果库存不够则队列里的写请求全部返回“已售完”。

缺点:
(1)NoSQL没有MySQL稳定,分布式组件需要运维保持其稳定性。
(2)幂等性难以保证,一般还要维护一个分布式NoSQL来记录哪些用户已经秒杀过了


MySQL真的低效吗?

当我们执行update操作之后,然后insert购买明细信息,之后才commit,这才是一个事物的完整流程,如果在commit之前其他用户想要操作这行数据,只能等待行锁的释放。
这样就造成了阻塞。
这里写图片描述

Java和数据库交互也需要一定的时间。
mysql本身可抗4w的QPS,但因为网络延迟,或者GC的原因,造成没秒500次左右。
这里写图片描述


总结

1.尽量将请求拦截在系统上游(越上游越好);(不要让锁冲突落到数据库上去)。传统秒杀系统之所以挂,请求都压倒了后端数据层,数据读写锁冲突严重,并发高响应慢,几乎所有请求都超时,流量虽大,下单成功的有效流量甚小。以12306为例,一趟火车其实只有2000张票,200w个人来买,基本没有人能买成功,请求有效率为0。
2.读多写少的常用多使用缓存(缓存抗读压力);秒杀买票,这是一个典型的读多些少的应用场景,大部分请求是车次查询,票查询,下单和支付才是写请求。一趟火车其实只有2000张票,200w个人来买,最多2000个人下单成功,其他人都是查询库存,写比例只有0.1%,读比例占99.9%,非常适合使用缓存来优化。

这里写图片描述

按钮防重复
回顾我们下单抢票的场景,点击了“查询”按钮之后,系统那个卡呀,进度条涨的慢呀,作为用户,我会不自觉的再去点击“查询”,对么?继续点,继续点,点点点。。。有用么?平白无故的增加了系统负载,一个用户点5次,80%的请求是这么多出来的,怎么整?

产品层面,用户点击“查询”或者“购票”后,按钮置灰,禁止用户重复提交请求;
JS层面,限制用户在x秒之内只能提交一次请求;

展开阅读全文

没有更多推荐了,返回首页