秒杀系统的设计

一,秒杀系统要解决的技术挑战

1,短时间内的超高访问量对后台服务的冲击。秒杀期间,来自外部请求产生的QPS会是平时的10~100倍。
2,数据库的读写压力陡增。大量的并发写,会造成数据库的行锁处于无法释放的状态,大量的线程排队进而造成服务请求超时失败。
3,网络带宽资源会因为秒杀被大量占据掉。假设秒杀页面的大小为150K,如果最大并发连接数为20000,那么应用服务器至少需要支持的带宽>3G。


二,秒杀系统开发前的准备

1,将活动页面上的所有可以静态的元素全部静态化,并尽量减少动态元素,所有页面的静态资源走CDN,CSS, JS和图片放入CDN后,利用遍布全国的CDN节点,降低带宽和静态服务器的压力,避免网络带宽成为业务瓶颈。
2,准备独立的服务器,秒杀系统单独部署,包括使用单独域名,避免秒杀业务对正常业务的系统的冲击和影响。
3,建立性能测试的环境,上线前根据本次秒杀的业务目标和流量预估,制定性能测试计划,只有通过性能测试后,才能真正上线。


三,秒杀系统的架构设计

1,前端的设计

在整个活动过程中,前端页面应该是如下状态:
1,秒杀开始前,秒杀按钮灰掉为“未开始”,不可点击。
2,秒杀进行中,秒杀按钮可以点击下单。
3,秒杀结束后,秒杀按钮灰掉为“已结束”,不可点击。

所以我们需要做以下几件事:
1,秒杀产品的介绍,详情,参数等等,全部静态化,切勿通过后台API查询更新,减轻后端的压力。
2,用户点击“下单”后,按钮置灰,禁止用户重复提交请求,限制用户在60秒之内只能提交一次请求。
3,“下单”的URL在活动开始前不可露出或者生效,否则容易被使用工具绕过浏览器提前下单。导致活动还未开始,已经开始下单这个大黑洞。正确的做法是活动开始前,通过更新JS文件露出下单的URL。
4,下单过程中,涉及到订单参数的修改全部关掉,比如,购买的金额,产品的份额等等,降低订单服务的压力。

2,服务层的设计

服务层的设计,如下图所示:
这里写图片描述

1,确保所有服务的缓存是独立分开,相互不影响,通过nginx负载均衡+集群部署,提高整体系统的承受能力。
2,检查用户的身份和条件,将无效的用户请求阻止在业务层之前,即限流。
3,所有读请求全部走缓存Redis, 并发量很大的时候一般不建议直接读数据库。
4,秒杀开始前,所有产品的属性和库存预加载到缓存中,即数据预热,秒杀过程中不主动更新数据库,库存数据延迟异步更新,例如12306的余票,有时候显示有票,但实际上是没有票的,这是缓存没有及时更新而已,但是这是在能接受的范围内。
5,削峰和异步处理:对于订单的写请求,加缓存,并做请求队列,加入请求队列后返回操作成功,不让用户一直等待,每次只透过有限的写请求去数据层,扣除库存成功均成功再进行下一批订单数据的更新,如果库存不够则队列里的写请求全部直接返回,尽可能阻止无效的请求穿透到数据层;
6,当瞬间秒杀产品库存太大,造成的Redis写暴增,可能造成线程阻塞最后写超时对于如上的异常,添加一个秒杀开关,大量异常时开关关闭停止一切秒杀活动,以免造成更大的损失。


四,建立秒杀系统的监控

为了应对秒杀过程中的各种突发情况,我们还需要建立有效的监控手段来保障秒杀的过程。
1,监控Redis调用性能,主要是看读和写的性能两个指标。
2,监控各个关键接口的运行情况,特别是下单接口的状态,看是否有大量请求timeout或者异常的情况出现,关注失败的订单数,设置预警阈值。如果超过阈值,报警并采取紧急处理措施,例如关闭秒杀,进行服务降级。
3,监控数据库的性能,密切关注订单写库的执行状态和读库的同步情况。
4,监控消息队列的情况。


五,参考资料

https://mp.weixin.qq.com/s?__biz=MzI3OTUwMjM4MA==&mid=2247483818&idx=1&sn=47b79c7c976981c660cbaad32322435a&chksm=eb478ae9dc3003ff82c2a92946f9815e9b300869129320d8810051507de70f72089f364643ec&scene=21#wechat_redirect

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值