[quote]
概述
所谓知已知彼,百战不殆,在开始详细介绍实战中的抢购秒杀系统时,我们了解一些抢购秒杀系统系统面临的尴尬与难点。另外需要说明一点,下面的内容都是在工作中慢慢总结得来,我们团队也是慢慢摸着石头过河,甚至最初的的架构设计并非是抢购秒杀系统。
评估系统处理能力
理论基础:LNMP的并发考虑与资源分配
虽然有基础去评估我们应用系统的处理能力,但是电商购买的业务流程挺复杂,从登录,商品详情,购物车,填写收货地址,选择支付方式,创建订单,完成支付,以及隐含的定时服务,限购策略,库存操作,排队机制等一系列的业务逻辑,每个请求的处理时间都不一样。那么根据木桶原理,一只水桶能将多少水取决于它最短的那块木板,分析整个业务流程中最耗系统资源的请求,以此为标准为评估系统处理能力。
场景
我们是一个做特卖秒杀抢购的电商平台,我们的商品异常火爆且价格低廉价,这就给网络黄牛带了巨大的利润空间。为了让真正的平台用户受益,改善用户体验,提高用户留存率,我们在产品业务、技术实现上尝试了很多方法,都没有完美解决黄牛刷单的问题。
目标
话说回来,让黄牛买不到商品,不是单纯技术能够解决的问题。我们要解决的问题是,由于黄牛大规模的请求登录接口、商品详情页接口、下单接口导致在抢购开始前后的流量峰值直接翻了上千倍,最终导致服务不可用。在不增加硬件成本的情况下,解决短时间内大流量导致的服务不可用。
产品特征
以H5应用为主站主要流量入口,支持QQ、微信、微博等平台用户登录购买,嵌入到某流行的资讯客户端。另外,也有单独的特卖安卓客户端、IOS客户端。
刷单特征
账号
黄牛每次抢购活动注册新用户,由于平台流量大部分来自某新闻客户端,客户端的账号体系为弱账号体系,可以绑定手机号也可以解除绑定,每次重新绑定都会生成新的用户ID。同时平台也允许非手机号注册的用户下单购买商品,用户的收货地址的联系电话可以和注册账号的手机号不一致。另一方面,黄牛在淘宝花钱可以购买大量的平台新注册账号,真是术业有专攻。
IP库
在云服务盛行的互联网时代,黄牛以很低的成本可以获得上万的IP及主机,IP分布在全球各地。
频次
黄牛刷单时访问频次不是很高,在拥有大量账号、IP的情况下,访问频次低也可以抢购到商品。
破解原生App
黄牛的技术很强,将混淆加密后的原生客户端破解,将其中的加密算法重写,升级抢购软件。
CC攻击
黄牛为了避免预约用户将商品提前抢光,联合全国的黄牛同时高频次的访问网站数据接口,导致网站由于大流量下不堪重负,从而服务不可用,在预约提前购买时间过去(黄牛的目的是堵住预约用户购买),全网用户均可购买时,慢慢的减少流量,任意下单购买商品。
产品与技术措施
产品业务角度
预约购买
全网用户提前预约,具有预约购买资格的用户可享受提前入场下单购买。预约需要绑定手机号,输入验证码(短信和图片)。
抢购排队
为了应对短时间内的大流量请求,采用排队购买机制,用户提交购买请求后立即返回,等待后端处理结果。
引流
在预知大流量不可控时,将H5主站流量引到原生的客户端APP内进行抢购。
技术防守角度
验证码
在抢购开始时,下单购买某商品必须输入验证码。在一定时间内,对于访问库存为0的用户请求,超过一定频次后要求输入验证码。打码云服务很多,理论上字符验证码均可识别,甚至人工打码,但是提高了刷单成本。
IP禁止策略
通过nginx的lua扩展,在单位时间内同用户相同IP请求同一URL进行计数,在nginx层面进行限流。IP级别下,控制不好,误杀太多或者起不了作用。
fastcgi请求计数
设定PHP可并发处理请求的最大值,nginx交给PHP的请求都进行计数+1,fastcgi完成后进行-1。由于nginx+php-fpm高并发情况下,做到原子的计数很难。
队列
引入消息队列和长连接服务,用户请求排队购买,后端进行流量控制,发放资格号,通过长连接通知用户的处理结果。
静态化
将商品详情页静态化,静态页面的请求直接由CDN返回。
建立黄牛账号库
经过几次大规模的抢购后,黄牛账号有限,将积累的黄牛账号入库,在下次抢购时,载入内存,降低购买优先级或者直接拒绝请求。
增加服务器
从原有的几台服务器,扩容到几十台服务器,每个服务都部署负载均衡、高可用。如多级缓存、nginx与php-fpm分离、长连接服务器集群等等。
可伸缩架构
抢购开始前准备上百倍的服务器数量,所有的服务均可横向扩展,提高处理能力。
上面交待了挺多的做抢购平台的一些场景、特征、措施,涉及的产品和技术的面广,我认为最重要的是解决网站服务不可用或者宕机的问题,我们在nginx层面做了很多努力与尝试,另外nginx在防CC攻击方面有一些成熟的方案,下面详述,下一阶段研究nginx源码。
nginx请求限制模块
ngx_http_limit_conn_module
限制连接数模块
通常用来限制同一IP地址的可并发连接数
指令说明:http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
需要注意的是$binary_remote_addr而不是$remote_addr,$remote_addr的长度为7到15个字节,它的会话信息的长度为32或64 bytes,$binary_remote_addr的长度为4字节,会话信息的长度为32字节,这样设置1M的一个zone时,用$binary_remote_addr方式,该zone将会存放32000个会话。
ngx_http_limit_req_module
限制请求数模块
通常用来限制同一IP地址单位时间可完成的请求数,限制的方法是采用漏桶算法(Leaky Bucket),每秒处理固定请求数量,推迟过多请求,超过桶的阀值,请求直接终止返回503。
指令说明:http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
基于nginx的Tengine分支ngx_http_limit_req_module
nginx类似,不过支持多个变量,并且支持多个limit_req_zone及forbid_action的设置。
指令说明:http://tengine.taobao.org/document_cn/http_limit_req_cn.html
基于nginx的Senginx分支的ngx_http_limit_req_module
指令说明:http://www.senginx.org/cn/index.php/%E5%9F%BA%E4%BA%8E%E6%9D%A1%E4%BB%B6%E7%9A%84%E9%99%90%E9%80%9F%E5%8A%9F%E8%83%BD
称之为基于条件的限速功能,在Tenginer的limit_req模块基础上,增加condition参数,在条件为真时执行限制动作。
基于nginx的Senginx分支的ngx_http_ip_behavior
指令说明:http://www.senginx.org/cn/index.php/%E8%AE%BF%E9%97%AE%E8%A1%8C%E4%B8%BA%E8%AF%86%E5%88%AB%E6%A8%A1%E5%9D%97
称之为行为识别模块,访问行为识别模块的作用是对用户访问网站的行为进行监控
基于nginx的Senginx分支的ngx_http_robot_mitigation
指令说明:http://www.senginx.org/cn/index.php/Robot_Mitigation%E6%A8%A1%E5%9D%97
称之为HTTP机器人缓解,Robot Mitigation模块采用了一种基于“挑战”的验证方法,即向客户端发送特定的、浏览器能解析的应答,如果客户端是真实的浏览器,则会重新触发请求, 并带有一个特定的Cookie值,Robot Mitigation模块会依据此Cookie的信息来决定是否放行此请求。
最后
基于上述的场景、特征、nginx限制模块的调研和分析,我们完全可以通过灵活的nginx配置来解决CC攻击威胁。使用了Senginx,灵活运用基于条件的限速功能,行为识别模块,机器人缓解模块。今天先聊到这儿,后续会总结出本文提到的很多技术细节[/quote]
[quote]
1、秒杀的场景
电商中为了吸引顾客、聚集人气,经常会策划一些秒杀活动。活动中售卖的商品,要么价格远低于市场价格,要么比较稀缺(如一些新发布的商品)。这些商品电商一般都会限量、限时销售。无疑这些商品对消费者的诱惑力是巨大的,消费者蜂拥而来,往往几秒钟就可以将商品抢购一空。而对于电商系统来说可能更多的是考验。
2、传统秒杀系统的痛点
首先,秒杀的场景决定了秒杀是一场速度的比拼,也就是俗话说的“手快有、手慢无”。大家都争着在活动开始后,第一时间将商品抢到,完成下单。因此秒杀活动开始的一瞬间会有大量的流量涌入,几倍、甚至于十几倍的流量对系统的冲击不可谓不大。如果系统没有足够的capacity或应对措施,很可能就被瞬时高流量给压垮了。
其次,突如其来的高流量,给系统各个模块都来了一连串的压力,系统可能会因此变慢,而且可能会彼此影响,影响可用性。比如:数据库更新同一个商品库存,需对同一行记录加锁,随着并发的压力逐渐增大,数据库更新的性能是逐渐下降的。从而引起提供库存service的应用服务性能下降,连锁的影响到下单service的性能,最终反馈到消费者的可能就是整个网站购物流程性能差、响应慢。而面对响应慢的系统,很多消费者可能采取反复刷新,多次尝试,这无疑又增大了对系统的压力。
还有,上述种种给消费者带来的往往是体验上的痛苦。如:网站响应慢,点击抢购按钮没反应。好不容易可以操作了,却发现秒杀活动已经结束,消费者的参与感比较差。久而久之,可能就对此类活动失去了兴趣。
3、1号店秒杀系统的设计理念
基于以上秒杀场景下的痛点,1号店的秒杀排队系统在设计时主要考虑以下几点:
[img]http://dl2.iteye.com/upload/attachment/0123/7192/bcaae625-8ce6-32d2-bb31-c039bf83b7c7.png[/img]
限流:当秒杀活动开始后,只有少部分消费者能抢购到秒杀商品,意味着其实大部分用户的流量传达到后台服务后都是无效。如果能引导这大部分的流量,不让这大部分的流量传达到后台服务,其实对我们系统的压力就很小了。因此设计思路之一就是,仅让能成功抢购到商品的流量(可以有一定余量)进入我们的系统。
削峰:进入系统的有效流量虽然总量不一定是很大的,但却是在很短的时间内涌入的,因此会存在很高的瞬时流量峰值。总量相同的流量在1秒钟进入系统,和在10分钟均匀地进入系统,对系统的冲击是相差很大的。高峰值的流量往往能将系统压垮。因此另一个设计思路是,如何将进入系统的瞬时高流量拉平,使得系统可以在自己处理能力范围内,将所有抢购的请求处理完毕。
异步处理:传统的系统对于请求是同步处理的,即收到请求后立即处理并把结果返回给用户。我们的系统有了削峰的设计后,请求不是被立刻处理的,因此就要求我们能将同步的服务改造成异步的。
可用性:我们设计时始终把系统的可用性放在重要的位置,针对系统可能出现的各种状况,都尽最大程度地保证高可用。
用户体验:系统设计一定要充分考虑用户体验。消费者点击抢购按钮后,无论是否能抢到商品,期望是能得到及时的反馈。系统上发生任何故障也要尽可能的保证用户体验的损害减到最小。
4、系统架构简介
现在来简单介绍下我们秒杀排队系统的架构,从大的方面来说分为三个主要模块:
排队模块:负责接收用户的抢购请求,将请求以先入先出的方式保存下来。每一个参加秒杀活动的商品保存一个队列,队列的大小可以根据参与秒杀的商品数量(或加点余量)自行定义。排队模块还负责提供一系列接口,如:给已进入队列的用户查询下单状态的接口,给调度模块拉取请求的接口,服务模块回写业务处理状态的接口等。
调度模块:负责排队模块到服务模块的动态调度,不断检查服务模块,一旦处理能力有空闲,就从排队队列头上把用户访问请求调入服务模块。并负责向服务模块分发请求。这里调度模块扮演一个中介的角色,但不只是传递请求而已。它还担负着调节系统处理能力的重任。我们可以根据服务模块的实际处理能力,动态调节向排队系统拉取请求的速度。作用有点类似水坝的闸门,当下游干旱时就打开闸门多放些水,当下游洪涝时,就放下闸门少放些水。
服务模块:是负责调用真正业务处理服务,并返回处理结果,并调用排队模块的接口回写业务处理结果。我们设计这个模块,是为了和后面真正的业务处理服务解耦。目前我们的系统不只支持秒杀抢购这种业务场景,后续有其他适用于排队系统的业务都可以接入,如:领取抵用券等等。同时我们也可以针对后面业务系统的处理能力,动态调节服务模块调用后面业务处理服务的速度。
5、容错处理
任何系统都不可能一帆风顺,但我们要能在出现错误时仍旧保证系统的高用性和良好的客户体验。举几个简单的例子,比如服务模块调用后面服务时,出现调用服务超时怎么办?对此我们设计了对于超时的请求,可以重试的机制。再比如,如果后面真正的业务处理系统宕机怎么办?如果是传统系统的话,可能就面临系统无法使用的尴尬。而我们的系统已经是异步的了,因此加入排队队列的用户请求,在业务处理系统恢复后都可以得到处理。只要我们在前端给用户以友好的交互、提示,系统还是能提供一定质量服务的。
6、用户交互
因为我们的系统设计成异步的,因此消费者不再是像以前一样同步地去等待反馈。消费者需要一个途径来获取抢购的状态和进度。我们的主体流程大体上分为几个阶段:
当等待人数大于500人,页面提示:排在您前面的人超过500位;
当等待人数小于等于500人,页面提示:您已挤进第***位;
当等待时间大于等于1分钟,页面提示:剩余时间约*分钟。每次以分钟倒计时。
当等待时间小于1分钟,页面提示:预计剩余*秒。
抢购成功,后续跳转到订单支付页面
下面仅挑选2个PC端页面交互的设计供大家参考,
当然我们还提供了一些分支流程的提示与处理,如果大家感兴趣,更详细的情况可以到1号店亲自参与秒杀活动来体验。
7、总结
目前我们的秒杀排队系统已经应用于1号店的历次大促,并取得了良好的效果,受到业务运营和消费者一致的好评。优秀的系统一定是建立在对业务透彻理解的基础上,针对业务的场景与痛点,结合现有的技术有针对性的提供解决方案。同时技术上成功的系统,往往也推动着业务的发展,给业务更好的支撑和推动。[/quote]
概述
所谓知已知彼,百战不殆,在开始详细介绍实战中的抢购秒杀系统时,我们了解一些抢购秒杀系统系统面临的尴尬与难点。另外需要说明一点,下面的内容都是在工作中慢慢总结得来,我们团队也是慢慢摸着石头过河,甚至最初的的架构设计并非是抢购秒杀系统。
评估系统处理能力
理论基础:LNMP的并发考虑与资源分配
虽然有基础去评估我们应用系统的处理能力,但是电商购买的业务流程挺复杂,从登录,商品详情,购物车,填写收货地址,选择支付方式,创建订单,完成支付,以及隐含的定时服务,限购策略,库存操作,排队机制等一系列的业务逻辑,每个请求的处理时间都不一样。那么根据木桶原理,一只水桶能将多少水取决于它最短的那块木板,分析整个业务流程中最耗系统资源的请求,以此为标准为评估系统处理能力。
场景
我们是一个做特卖秒杀抢购的电商平台,我们的商品异常火爆且价格低廉价,这就给网络黄牛带了巨大的利润空间。为了让真正的平台用户受益,改善用户体验,提高用户留存率,我们在产品业务、技术实现上尝试了很多方法,都没有完美解决黄牛刷单的问题。
目标
话说回来,让黄牛买不到商品,不是单纯技术能够解决的问题。我们要解决的问题是,由于黄牛大规模的请求登录接口、商品详情页接口、下单接口导致在抢购开始前后的流量峰值直接翻了上千倍,最终导致服务不可用。在不增加硬件成本的情况下,解决短时间内大流量导致的服务不可用。
产品特征
以H5应用为主站主要流量入口,支持QQ、微信、微博等平台用户登录购买,嵌入到某流行的资讯客户端。另外,也有单独的特卖安卓客户端、IOS客户端。
刷单特征
账号
黄牛每次抢购活动注册新用户,由于平台流量大部分来自某新闻客户端,客户端的账号体系为弱账号体系,可以绑定手机号也可以解除绑定,每次重新绑定都会生成新的用户ID。同时平台也允许非手机号注册的用户下单购买商品,用户的收货地址的联系电话可以和注册账号的手机号不一致。另一方面,黄牛在淘宝花钱可以购买大量的平台新注册账号,真是术业有专攻。
IP库
在云服务盛行的互联网时代,黄牛以很低的成本可以获得上万的IP及主机,IP分布在全球各地。
频次
黄牛刷单时访问频次不是很高,在拥有大量账号、IP的情况下,访问频次低也可以抢购到商品。
破解原生App
黄牛的技术很强,将混淆加密后的原生客户端破解,将其中的加密算法重写,升级抢购软件。
CC攻击
黄牛为了避免预约用户将商品提前抢光,联合全国的黄牛同时高频次的访问网站数据接口,导致网站由于大流量下不堪重负,从而服务不可用,在预约提前购买时间过去(黄牛的目的是堵住预约用户购买),全网用户均可购买时,慢慢的减少流量,任意下单购买商品。
产品与技术措施
产品业务角度
预约购买
全网用户提前预约,具有预约购买资格的用户可享受提前入场下单购买。预约需要绑定手机号,输入验证码(短信和图片)。
抢购排队
为了应对短时间内的大流量请求,采用排队购买机制,用户提交购买请求后立即返回,等待后端处理结果。
引流
在预知大流量不可控时,将H5主站流量引到原生的客户端APP内进行抢购。
技术防守角度
验证码
在抢购开始时,下单购买某商品必须输入验证码。在一定时间内,对于访问库存为0的用户请求,超过一定频次后要求输入验证码。打码云服务很多,理论上字符验证码均可识别,甚至人工打码,但是提高了刷单成本。
IP禁止策略
通过nginx的lua扩展,在单位时间内同用户相同IP请求同一URL进行计数,在nginx层面进行限流。IP级别下,控制不好,误杀太多或者起不了作用。
fastcgi请求计数
设定PHP可并发处理请求的最大值,nginx交给PHP的请求都进行计数+1,fastcgi完成后进行-1。由于nginx+php-fpm高并发情况下,做到原子的计数很难。
队列
引入消息队列和长连接服务,用户请求排队购买,后端进行流量控制,发放资格号,通过长连接通知用户的处理结果。
静态化
将商品详情页静态化,静态页面的请求直接由CDN返回。
建立黄牛账号库
经过几次大规模的抢购后,黄牛账号有限,将积累的黄牛账号入库,在下次抢购时,载入内存,降低购买优先级或者直接拒绝请求。
增加服务器
从原有的几台服务器,扩容到几十台服务器,每个服务都部署负载均衡、高可用。如多级缓存、nginx与php-fpm分离、长连接服务器集群等等。
可伸缩架构
抢购开始前准备上百倍的服务器数量,所有的服务均可横向扩展,提高处理能力。
上面交待了挺多的做抢购平台的一些场景、特征、措施,涉及的产品和技术的面广,我认为最重要的是解决网站服务不可用或者宕机的问题,我们在nginx层面做了很多努力与尝试,另外nginx在防CC攻击方面有一些成熟的方案,下面详述,下一阶段研究nginx源码。
nginx请求限制模块
ngx_http_limit_conn_module
限制连接数模块
通常用来限制同一IP地址的可并发连接数
指令说明:http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
需要注意的是$binary_remote_addr而不是$remote_addr,$remote_addr的长度为7到15个字节,它的会话信息的长度为32或64 bytes,$binary_remote_addr的长度为4字节,会话信息的长度为32字节,这样设置1M的一个zone时,用$binary_remote_addr方式,该zone将会存放32000个会话。
ngx_http_limit_req_module
限制请求数模块
通常用来限制同一IP地址单位时间可完成的请求数,限制的方法是采用漏桶算法(Leaky Bucket),每秒处理固定请求数量,推迟过多请求,超过桶的阀值,请求直接终止返回503。
指令说明:http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
基于nginx的Tengine分支ngx_http_limit_req_module
nginx类似,不过支持多个变量,并且支持多个limit_req_zone及forbid_action的设置。
指令说明:http://tengine.taobao.org/document_cn/http_limit_req_cn.html
基于nginx的Senginx分支的ngx_http_limit_req_module
指令说明:http://www.senginx.org/cn/index.php/%E5%9F%BA%E4%BA%8E%E6%9D%A1%E4%BB%B6%E7%9A%84%E9%99%90%E9%80%9F%E5%8A%9F%E8%83%BD
称之为基于条件的限速功能,在Tenginer的limit_req模块基础上,增加condition参数,在条件为真时执行限制动作。
基于nginx的Senginx分支的ngx_http_ip_behavior
指令说明:http://www.senginx.org/cn/index.php/%E8%AE%BF%E9%97%AE%E8%A1%8C%E4%B8%BA%E8%AF%86%E5%88%AB%E6%A8%A1%E5%9D%97
称之为行为识别模块,访问行为识别模块的作用是对用户访问网站的行为进行监控
基于nginx的Senginx分支的ngx_http_robot_mitigation
指令说明:http://www.senginx.org/cn/index.php/Robot_Mitigation%E6%A8%A1%E5%9D%97
称之为HTTP机器人缓解,Robot Mitigation模块采用了一种基于“挑战”的验证方法,即向客户端发送特定的、浏览器能解析的应答,如果客户端是真实的浏览器,则会重新触发请求, 并带有一个特定的Cookie值,Robot Mitigation模块会依据此Cookie的信息来决定是否放行此请求。
最后
基于上述的场景、特征、nginx限制模块的调研和分析,我们完全可以通过灵活的nginx配置来解决CC攻击威胁。使用了Senginx,灵活运用基于条件的限速功能,行为识别模块,机器人缓解模块。今天先聊到这儿,后续会总结出本文提到的很多技术细节[/quote]
[quote]
1、秒杀的场景
电商中为了吸引顾客、聚集人气,经常会策划一些秒杀活动。活动中售卖的商品,要么价格远低于市场价格,要么比较稀缺(如一些新发布的商品)。这些商品电商一般都会限量、限时销售。无疑这些商品对消费者的诱惑力是巨大的,消费者蜂拥而来,往往几秒钟就可以将商品抢购一空。而对于电商系统来说可能更多的是考验。
2、传统秒杀系统的痛点
首先,秒杀的场景决定了秒杀是一场速度的比拼,也就是俗话说的“手快有、手慢无”。大家都争着在活动开始后,第一时间将商品抢到,完成下单。因此秒杀活动开始的一瞬间会有大量的流量涌入,几倍、甚至于十几倍的流量对系统的冲击不可谓不大。如果系统没有足够的capacity或应对措施,很可能就被瞬时高流量给压垮了。
其次,突如其来的高流量,给系统各个模块都来了一连串的压力,系统可能会因此变慢,而且可能会彼此影响,影响可用性。比如:数据库更新同一个商品库存,需对同一行记录加锁,随着并发的压力逐渐增大,数据库更新的性能是逐渐下降的。从而引起提供库存service的应用服务性能下降,连锁的影响到下单service的性能,最终反馈到消费者的可能就是整个网站购物流程性能差、响应慢。而面对响应慢的系统,很多消费者可能采取反复刷新,多次尝试,这无疑又增大了对系统的压力。
还有,上述种种给消费者带来的往往是体验上的痛苦。如:网站响应慢,点击抢购按钮没反应。好不容易可以操作了,却发现秒杀活动已经结束,消费者的参与感比较差。久而久之,可能就对此类活动失去了兴趣。
3、1号店秒杀系统的设计理念
基于以上秒杀场景下的痛点,1号店的秒杀排队系统在设计时主要考虑以下几点:
[img]http://dl2.iteye.com/upload/attachment/0123/7192/bcaae625-8ce6-32d2-bb31-c039bf83b7c7.png[/img]
限流:当秒杀活动开始后,只有少部分消费者能抢购到秒杀商品,意味着其实大部分用户的流量传达到后台服务后都是无效。如果能引导这大部分的流量,不让这大部分的流量传达到后台服务,其实对我们系统的压力就很小了。因此设计思路之一就是,仅让能成功抢购到商品的流量(可以有一定余量)进入我们的系统。
削峰:进入系统的有效流量虽然总量不一定是很大的,但却是在很短的时间内涌入的,因此会存在很高的瞬时流量峰值。总量相同的流量在1秒钟进入系统,和在10分钟均匀地进入系统,对系统的冲击是相差很大的。高峰值的流量往往能将系统压垮。因此另一个设计思路是,如何将进入系统的瞬时高流量拉平,使得系统可以在自己处理能力范围内,将所有抢购的请求处理完毕。
异步处理:传统的系统对于请求是同步处理的,即收到请求后立即处理并把结果返回给用户。我们的系统有了削峰的设计后,请求不是被立刻处理的,因此就要求我们能将同步的服务改造成异步的。
可用性:我们设计时始终把系统的可用性放在重要的位置,针对系统可能出现的各种状况,都尽最大程度地保证高可用。
用户体验:系统设计一定要充分考虑用户体验。消费者点击抢购按钮后,无论是否能抢到商品,期望是能得到及时的反馈。系统上发生任何故障也要尽可能的保证用户体验的损害减到最小。
4、系统架构简介
现在来简单介绍下我们秒杀排队系统的架构,从大的方面来说分为三个主要模块:
排队模块:负责接收用户的抢购请求,将请求以先入先出的方式保存下来。每一个参加秒杀活动的商品保存一个队列,队列的大小可以根据参与秒杀的商品数量(或加点余量)自行定义。排队模块还负责提供一系列接口,如:给已进入队列的用户查询下单状态的接口,给调度模块拉取请求的接口,服务模块回写业务处理状态的接口等。
调度模块:负责排队模块到服务模块的动态调度,不断检查服务模块,一旦处理能力有空闲,就从排队队列头上把用户访问请求调入服务模块。并负责向服务模块分发请求。这里调度模块扮演一个中介的角色,但不只是传递请求而已。它还担负着调节系统处理能力的重任。我们可以根据服务模块的实际处理能力,动态调节向排队系统拉取请求的速度。作用有点类似水坝的闸门,当下游干旱时就打开闸门多放些水,当下游洪涝时,就放下闸门少放些水。
服务模块:是负责调用真正业务处理服务,并返回处理结果,并调用排队模块的接口回写业务处理结果。我们设计这个模块,是为了和后面真正的业务处理服务解耦。目前我们的系统不只支持秒杀抢购这种业务场景,后续有其他适用于排队系统的业务都可以接入,如:领取抵用券等等。同时我们也可以针对后面业务系统的处理能力,动态调节服务模块调用后面业务处理服务的速度。
5、容错处理
任何系统都不可能一帆风顺,但我们要能在出现错误时仍旧保证系统的高用性和良好的客户体验。举几个简单的例子,比如服务模块调用后面服务时,出现调用服务超时怎么办?对此我们设计了对于超时的请求,可以重试的机制。再比如,如果后面真正的业务处理系统宕机怎么办?如果是传统系统的话,可能就面临系统无法使用的尴尬。而我们的系统已经是异步的了,因此加入排队队列的用户请求,在业务处理系统恢复后都可以得到处理。只要我们在前端给用户以友好的交互、提示,系统还是能提供一定质量服务的。
6、用户交互
因为我们的系统设计成异步的,因此消费者不再是像以前一样同步地去等待反馈。消费者需要一个途径来获取抢购的状态和进度。我们的主体流程大体上分为几个阶段:
当等待人数大于500人,页面提示:排在您前面的人超过500位;
当等待人数小于等于500人,页面提示:您已挤进第***位;
当等待时间大于等于1分钟,页面提示:剩余时间约*分钟。每次以分钟倒计时。
当等待时间小于1分钟,页面提示:预计剩余*秒。
抢购成功,后续跳转到订单支付页面
下面仅挑选2个PC端页面交互的设计供大家参考,
当然我们还提供了一些分支流程的提示与处理,如果大家感兴趣,更详细的情况可以到1号店亲自参与秒杀活动来体验。
7、总结
目前我们的秒杀排队系统已经应用于1号店的历次大促,并取得了良好的效果,受到业务运营和消费者一致的好评。优秀的系统一定是建立在对业务透彻理解的基础上,针对业务的场景与痛点,结合现有的技术有针对性的提供解决方案。同时技术上成功的系统,往往也推动着业务的发展,给业务更好的支撑和推动。[/quote]