秒杀的那些事"/>
关于秒杀的那些事
关于秒杀的那些事
- 前言
- 秒杀的本质
- 秒杀的流程
- 秒杀的技术难点
- 秒杀的解决方案
- 思考
前言
今天要分享的内容是关于秒杀的那些事,一些我所了解的秒杀设计的架构,希望对你有所帮助,另外,我会尽可能的精简语言,使你不需要花太多时间,就能读完这篇文章。
秒杀的本质
相信做过后台系统的朋友都知道,秒杀有很多不同业务场景,如电商平台的超低价秒杀,12306的放票秒杀等业务场景,电商类业务的本质,是为了吸引用户,促进业务发展,而12306的秒杀的本质,是为了让我们每个人买上出行的火车票,方便出乘。
秒杀的流程
- 秒杀开始之前,用户打开客户端,可能是网页或是APP
- 客户端会请求一次服务端,获取商品秒杀倒计时
- 客户端轮询服务端,不停的问,开没开始,开没开始…
- 每次轮询服务端都会返回一个时间,以用来校准客户端展示时间
- 秒杀开始时,服务端返回Url
- 客户端加载Url,让用户点击
- 用户点击Url,请求服务端
我画了个图,帮助你更好理解
你可能会问,客户端请求一次不就行了吗,以第一次获取的时间为准,但你要知道,在服务端响应客户端时,可能会有网络延迟,或是服务不可用等情况导致获取的时间不准确或是失败,如果有时差,对用户体验不好放一边不说,这种设计严格来说已经不是秒杀了。
秒杀的技术难点
秒杀是用户所需,也是后端同学提升自己能力必须要去了解的一块技术领域,其主要技术挑战难点有以下几个方面
- 实时在线用户规模是平时的几十倍甚至几百倍,TPS/QPS很高,对网络带宽、服务器性能带来成倍压力
- 瞬时并发高,数据库会有被打挂的风险,可能会导致数据丢失、数据不一致、服务不可用等问题
- 数据的修改是单条的,单点数据,无论怎么分库分表、读写分离、分布式数据库、表结构水平拆分、垂直拆分都无济于事
拿淘宝的秒杀来说,如果有100万用户同时秒杀200件商品,这100万的QPS轮询问服务端开没开始…理论上100万的QPS可以让带宽瞬间打爆,100万TPS可以让数据库瞬瞬间宕机…这简直是一场灾难,看起来无解了
秒杀的解决方案
结合上面的难点,我们大概会有以下思路
- 分摊用户开始前的倒计时查询请求,让用户的查询请求分摊在不同的CDN上,并用负载均衡+服务集群+分布式缓存的模式
- 使用CDN+边缘计算能力,在CDN上部署子服务,这些子服务提供计算在线用户量功能,并给出一个通过率,满足公式:用户数量*通过率=商品数量,比如淘宝100万用户在线抢200件商品,那通过率就是0.02%
- 用户限流+单机限流,可以采用目前比较成熟的一些限流算法,如令牌桶算法、漏斗算法、计数算法
- 客户端验证码,过滤掉机器或是脚本的请求
通过以上的一些策略,可以大幅度降低用户的请求,对于200的TPS,数据库怎么也能抗得住了
思考
秒杀场景是一个业务特例,商品数量有限制,所以需要对用户做过滤和限流。如果像双11那种,要卖出更多的商品的业务场景,就不需要对用户做限流了。而且是需要提升自身架构的吞吐量了,要对系统做大量的高并发测试和压测,找出系统的性能瓶颈,并改进。
在很多场景,我们应该跳出固有的传统的客户端+服务端+数据端的思维,站在不同的技术维度看待问题,像秒杀,就可以利用CDN做边缘计算,在外卖,打车,附近的人,等地域相关功能上,都有边缘计算的身影。
对于秒杀系统,如果你有其他的解决方案,欢迎给我留言~
本文参考陈皓老师的专栏:《61 | 性能设计篇之“秒杀”》
更多推荐
关于秒杀的那些事
发布评论