程序员如何应对秒杀场景?
凡是做过电商的同学,都会遇到运营展开的秒杀,限时购等“高并发”的活动。
秒杀从规模上来说可以分为大秒和小秒。大秒指的是比如双11这种特定的节日,商品规模超大、价格超低、流量超大的这种类型活动,小秒一般指的是商家自己配置的一些时段类型的活动,由商家自己指定时间上架。从形式来说还可以分为单时段秒杀和多时段秒杀。但是在这个场景里,我们一般就是指的单时段大型秒杀。
秒杀这种业务场景其实特点很明显:
1、带有短期流量峰值特性,即:短时间内会有大量的请求涌入;
2、请求的数据带有热点性,即:大量的请求同一数据;
3、请求的成功有效率低,即:大量的请求中可能只有少量请求会成功处理业务;
4、请求的流量峰值发生在下单之前,即:付款阶段很少存在流量峰值。
一、秒杀的技术挑战
1、对现有网站业务造成冲击:秒杀活动只是网站营销的一个附加活动,这个活动具有时间短,并发访问量大的特点,如果和网站原有应用部署在一起,必然会对现有业务造成冲击,稍有不慎可能导致整个网站瘫痪;
2、高并发下的应用、数据库负载:用户在秒杀活动开始之前,通过不停的刷新浏览器页面以保证不错过秒杀,这些请求如果按照一般网站的应用架构,访问应用,连接数据库,会对应用服务器和数据库服务器造成极大的负载压力;
3、突然增加的网络及服务器带宽:因为访问秒杀页面的用户剧增,对资源的请求量也是剧增,网络带宽也上去了,超过平时网站使用的带宽;
4、直接下单:秒杀的规则是到了秒杀秒杀时间才能开始对商品下单购买,在此时间点之前,只能浏览商品信息,不能下单。而下单页面也是一个普通的URL,如果得到了这个URL,不用等到秒杀开始就可以下单了。
二、秒杀系统的应对策略
1、技术第一招:限流
对于秒杀出现的流量峰值,限流是最直接的削峰手段,被限制的请求可以直接返回,客户端提示请求中提示。可想而知,当10000/S的请求量被削成100/S的量,估计系统稍微优化一下就能抗住。
2、第二招:消息队列
说到消息队列,每个程序员都不陌生,它相当于一个快速的数据容器,可以作为一个缓冲层来应对流量高峰。如果从它的使用场景上来看,它可以算是低速设备和高速设备之间的平衡者,使用消息队列来进行削峰是一个很明显的异步流程。应用到秒杀的场景下,大量的请求会先进入消息队列,它不仅削平了流量的峰值,而且把秒杀下单的这个流程异步化,只要把请求都暂存入队列,消费端慢慢消费即可,但是这里要注意,如果消费的速度远远慢于消息的投递速度,可能会影响整个系统性能。
除了削峰之外,我始终认为消息队列的最大作用是系统解耦,它把下单和支付解耦,下单和支付业务可以随着自身系统的承载量来单独扩容。
3、第三招:缓存
为什么要加入缓存这个选项呢?别忘了,除了大量的用户下单这个写操作之外,还有更大量的用户请求下单结果这个读操作。当用户点击秒杀按钮之后,系统会弹出等待的提示框,很多系统是不停的去轮训用户的下单结果,我之前也写过缓存的文章,曾经提到过缓存最大的作用是提供读操作的快速响应。其实很多系统应用上消息队列 限流之后,针对秒杀业务已经足够了,其余的分库分表等方案可以根据自己的业务量来确定。每个系统在满足功能性的需求下,也在满足非功能性需求的前提下越简单越好,不是每个系统都需要淘宝的架构。
消息队列RabbitMQ是一款支持持久化消息队列的消息中间件。通过创建集群的方式来实现RabbitMQ以及所依赖的服务的部署,完全兼容RabbitMQ开源生态以及多语言客户端,为用户提供快速创建、方便管理的消息中间件。
创新互联消息队列RabbitMQ支持多种模式,满足不同使用场景,包括简单队列模式、work模式、发布/订阅模式、路由模式、topic模式等,提供CPU使用率、内存使用率、磁盘使用率、文件句柄使用数、Sockets句柄使用数等监控项,支持设置多项报警策略,帮助用户了解实例动态:https://www.cdcxhl.com/
富平ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:13518219792(备注:SSL证书合作)期待与您的合作!
新闻名称:程序员如何应对秒杀场景?
链接分享:http://ybzwz.com/article/ccphh.html