谈谈秒杀系统的落地方案

作者: ForestXie | 来源:发表于2017-07-12 23:25 被阅读155次

    昨天的文章给秒杀系列开了一个头,今天会集中讲一下实现一个秒杀系统的思路和方案,不代表这就是最好的方案或者最佳实践,而是希望通过这篇文章,能起到抛砖引玉的作用,希望有更佳的思路提供出来。

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

    1.短时间内的超高访问量对后台服务的冲击。秒杀期间,来自外部请求产生的QPS会是平时的10~100倍。

    2.数据库的读写压力陡增。大量的并发写,会造成数据库的行锁处于无法释放的状态,大量的线程排队进而造成服务请求超时失败。

    3.网络带宽资源会因为秒杀被大量占据掉。假设秒杀页面的大小为150K,如果最大并发连接数为20000,那么应用服务器至少需要支持的带宽>3G。

    秒杀系统开发前的准备

    1.所有页面的静态资源走CDN,CSS, JS和图片放入CDN后,利用遍布全国的CDN节点,降低带宽和静态服务器的压力,避免网络带宽成为业务瓶颈。

    2.准备独立的服务器,秒杀系统单独部署,包括使用单独域名,避免秒杀业务对正常业务的系统的冲击和影响。

    3.建立性能测试的环境,上线前根据本次秒杀的业务目标和流量预估,制定性能测试计划,只有通过性能测试后,才能真正上线。

    秒杀系统的架构设计

    1.  前端的设计

    在整个活动过程中,前端页面应该是如下状态:

    秒杀开始前,秒杀按钮灰掉为“未开始”,不可点击。

    秒杀进行中,秒杀按钮可以点击下单。

    秒杀结束后,秒杀按钮灰掉为“已结束”,不可点击。

    所以我们需要做以下几件事:

    1.  秒杀产品的介绍,详情,参数等等,全部静态化,切勿通过后台API查询更新,减轻后端的压力。

    2.  用户点击“下单”后,按钮置灰,禁止用户重复提交请求,限制用户在60秒之内只能提交一次请求。

    3.“下单”的URL在活动开始前不可露出或者生效,否则容易被使用工具绕过浏览器提前下单。导致活动还未开始,已经开始下单这个大黑洞。正确的做法是活动开始前,通过更新JS文件露出下单的URL。

    4. 下单过程中,涉及到订单参数的修改全部关掉,比如,购买的金额,产品的份额等等,降低订单服务的压力。

    2. 服务层的设计

    服务层的设计,如下图所示:

    确保所有服务的缓存是独立分开,相互不影响。

    按照昨天文章写到的那样,检查用户的身份和条件,将无效的用户请求阻止在业务层之前。

    所有读请求全部走缓存,Redis or MemCached,  也可以考虑走读库,请注意流量的分配。

    秒杀开始前,所有产品的属性和库存预加载到缓存中,秒杀过程中不主动更新数据库,库存数据延迟异步更新。

    对于订单的写请求,加缓存,并做请求队列,每次只透过有限的写请求去数据层,扣除库存成功均成功再进行下一批订单数据的更新,如果库存不够则队列里的写请求全部直接返回,尽可能阻止无效的请求穿透到数据层;

    当瞬间秒杀产品库存太大,造成的Redis写暴增,可能造成线程阻塞最后写超时对于如上的异常,添加一个秒杀开关,大量异常时开关关闭停止一切秒杀活动,以免造成更大的损失。

    建立秒杀系统的监

    为了应对秒杀过程中的各种突发情况,我们还需要建立有效的监控手段来保障秒杀的过程。

    监控Redis调用性能,主要是看读和写的性能两个指标。

    监控各个关键接口的运行情况,特别是下单接口的状态,看是否有大量请求timeout或者异常的情况出现,关注失败的订单数,设置预警阈值。如果超过阈值,报警并采取紧急处理措施,例如关闭秒杀,进行服务降级。

    监控数据库的性能,密切关注订单写库的执行状态和读库的同步情况。

    扫描二维码或手动搜索微信公众号【架构栈】: ForestNotes

    欢迎转载,带上以下二维码即可

    相关文章

      网友评论

        本文标题:谈谈秒杀系统的落地方案

        本文链接:https://www.haomeiwen.com/subject/supihxtx.html