实战讲解高并发和秒杀抢购系统设计

互联网特别是电商平台,阿里双11秒杀、还有12306春运抢票、以及平时各种节假日抢购活动等,都是典型的高并发场景。

这类场景最大的特征就是活动周期短,瞬间流量大(高并发),大量的人短期涌入服务器抢购,但是数量有限,最终只有少数人能成功下单。

这里,就来讲一讲对应该场景下需要考虑的技术实现。

先从基本的概念的建立,再讲对应的实现部分。

第一:高并发

技术要做的事,一方面优化程序,让程序性能最优,单次请求时间能从50ms优化到25ms,那就可以在一秒钟内成功响应翻倍的请求了。

另一方面就是增加服务器,用更大的集群来处理用户请求,设计好一个可靠且灵活扩充的分布式方案就更加重要了。

第二:时间短

火热的秒杀活动,真的是一秒钟以内就会把商品抢购一空,而大部分用户的感受是,提交订单的过程却要等待好几秒、甚至十几秒,更糟糕的当然是请求报错。

那么一个好的秒杀体验,当然希望尽可能减少用户等待时间,准确的提示用户当前是否还有商品库存。而这些,也是需要有优秀的程序设计来保证的。

第三:系统容量预估

系统设计的时候,都需要有一个容量预估,那就是要提前计算好,我们设计的系统,要承载多大的数量级。

假如线上前端服务器规格是8核16G内存的服务器,而提交订单的处理程序耗时100ms,那么可以简单计算一下:

每秒可以处理的订单请求数=1000ms/100ms*8=80qps

上面这个结果,对于秒杀系统来说,肯定是非常不理想的。

如果能将处理程序耗时优化后,降低到10ms,那么就可以达到800qps。

如果我们可以把程序继续优化,能快速区分开有库存和无库存处理,那么无库存时处理就有可能做到1ms甚至更低的耗时。这样无库存时就能有更好的性能,上万的qps也是可以达到的。

上面的预估,都是针对单机,那么简单的增加前端服务器,是不是就能有更好的并发处理量呢?

肯定没这么简单,因为数据库、缓存系统甚至机房网络带宽都会成为瓶颈。

于是就要有一个更好的分布式方案。

第四:好的分布式方案

一个好的分布式方案,首先当然是稳定可靠,不要出乱子,然后就是方便扩充,最好的效果当然是增加一台服务器,并发处理量可以1:1线性增长。

比如:单机qps是1k,那么10台服务器可以做到1w,100台可以做到10w每秒。

要做到这样的线性增长效果,就要杜绝出现瓶颈,否则还是会代价太大。

拒绝假的分布式尤其重要,比如:前端服务器是可以独立存在的,但是都依赖集中的一个数据库或者缓存系统,那最后,一定是集中的那个数据库或者缓存系统受不了,同样无法做到一个好的分布式。

第五:关注系统的瓶颈

大家先有几个基本的共识,系统的处理速度

程序内数据读写 > redis > mysql > 磁盘

单机网络请求 > 局域网内请求 > 跨机房请求

我们优化程序的时候,尽量用最快的方式,尽量用最简短的逻辑。

用redis替代mysql来保存订单处理中依赖的数据,用程序中的提交的数据代替从redis中二次获取数据,比如:商品库存信息,用户订单信息。

逻辑处理中,把速度快且提前中断的逻辑放在最前面,比如:验证登录,验证问答。

我们做分布式方案的时候,尽量把资源调用放在最近的地方。

前端服务器依赖的数据尽量就在局域网内,如果能在单机都有读的redis服务当然更好,程序维护数据响应会复杂些。

不要出现跨机房网络请求,不要出现跨机房网络请求,不要出现跨机房网络请求,重要的事情说三遍。

第六:什么语言更适合这类系统

当然,像是用golang, ngx_lua可能在高并发和性能方面会更有优势。

如果使用java、php当然也是可以的,作为一个系统,语言只是工具,更好的设计和优化,才能达到最终想要的效果。

有了上面的基本概念,我们接下来再来看看,具体运行时,会出现什么状况。

下面是一些具体的实现问题:

问题1:库存超卖

只有10个库存,但是一秒钟有1k个订单,怎么能不超卖呢?

核心思想就是保证库存递减是原子性操作,10--返回9,9--返回8,8--返回7。

而不能是读取出来库存10,10-1=9再更新回去。因为这个读取和更新是并发执行的,很可能就会有1k个订单都成功了,而库存实际只有10。

那么,怎么保证原子性操作呢?

1 数据库:

update product set left_num=left_num-1 where left_num>0;

这里用到的是left_num=left_num-1,如果left_num>0才能执行成功,数据库查询、更新的时候有用到锁,是可以保证更新操作的原子性的。

数据库性能较差,不建议使用。

2 分布式锁

用redis来做一个分布式锁,reids->setnx('lock', 1) 设置一个锁,程序执行完成再del这个锁。

锁定的过程,不利于并发执行,大家都在等待锁解开,不建议使用。

3 消息队列

将订单请求全部放入消息队列,然后另外一个后台程序一个个处理队列中的订单请求。

并发不受影响,但是用户等待的时间较长,进入队列的订单也会很多,体验上并不好,也不建议使用。

4 redis递减

通过 redis->incrby('product', -1) 得到递减之后的库存数。

问题2:集群怎么来规划

前端服务器因为没有相互间关联,集群的数量不受影响。

redis的性能可以达到每秒几万次响应,所以一个集群的规模,也就是redis服务可以承载的数量。

比如:一台前端服务器是1~2k的qps(有库存时),那么10台+1台redis就可以是一个独立的集群,可以支撑1~2w每秒订单量。

10个上述的集群就可以做到一秒钟处理10w~20w的有效订单。

如果秒杀活动的库存量在1w以内,预计参与的人数在百万左右,那么有一个集群也就可以搞定。

如果秒杀参与的人数超过千万,那么就要用到不止一个集群了。

问题3:多个集群的数据怎么保持一致性

不要做多集群的数据同步,而是用散列,每个集群的数据是独立存在的。

假设,有10个商品,每个商品有1w库存,规划用10个集群,那么每个集群有10个商品,每个商品是1k库存。

每个集群只需要负责把自己的库存卖掉即可,至于说,会不会有用户知道有10个集群,然后每个集群都去抢。

这种情况就不要用程序来处理了,利用运营规则,活动结束后汇总订单的时候再去处理就好了。

如果担心散列的不合理,比如:某个集群用户访问量特别少,那么可以引入一个中控服务,来监控各个集群的库存,然后再做平衡。

问题4:机器人抢购怎么办:

没什么太好的办法,类似DDOS攻击,只能是让自身更强大才是王道。

运营策略上,可以严格控制用户注册,必须登录,提交订单的时候引入图像验证码,问答,交互式验证等。

以上是高并发和秒杀实战, 更多架构资料请狂戳

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏企鹅号快讯

Smartnet 网络运维

「举一反三」 「继开源工具分享之后,本章系列文章将带来团队初尝自研的一些故事和技术分享、几个python模块、几个自动化空白工作领域等....」 1、作者介绍 ...

30590
来自专栏即时通讯技术

简述移动端IM开发的那些坑:架构设计、通信协议和客户端1、前言 2、学习交流3、概述4、有关移动端IM通信协议的坑5、移动端IM客户端的坑6、移动端IM架构设计的坑7、结语附录:更多IM技术文章

有过移动端开发经历的开发者都深有体会:移动端IM的开发,与传统PC端IM有很大的不同,尤其无线网络的不可靠性、移动端硬件设备资源的有限性等问题,导致一个完整的移...

27510
来自专栏数据和云

【从根源出发,化风险为可控】应用到数据库的连接数管控

作者介绍 ? 巩飞(Morinson) 云和恩墨技术专家 网名Morinson,现服务于云和恩墨西北区,有14年在IT公司的技术类工作经验,特别是在 Ora...

32550
来自专栏运维一切

为什么我们不能使用KUBERNETES 原

kubernetes的服务发现到node创建启动,最终到提供服务,中间都离不开iptable的nat模块,在业务高访问量的情况下,这是无法满足性能要求的。

9120
来自专栏章鱼的慢慢技术路

游戏服务器存储系统设计

data——>file(database)——>file system——>hard driver

55830
来自专栏微服务生态

基于Nginx+lua的蓝绿发布系统

蓝绿部署是不停老版本,部署新版本然后进行测试,确认OK,将流量切到新版本,然后老版本同时也升级到新版本。

22140
来自专栏互扯程序

到底什么是分布式系统,该如何学习

现在是资源共享的时代,同样也是知识分享的时代,如果你觉得本文能学到知识,请把知识与别人分享。

18150
来自专栏杂烩

一种海量日志存储、分析解决方案V1.0 原

    flume,版本1.7.0,主要用来从业务系统收集数据以及从jms收集数据。

34020
来自专栏性能与架构

Hotjar在架构演进中总结的8条经验

Hotjar 提供了帮网站主了解用户行为的服务,网站接上此服务后,可以生成用户的点击热区,录制用户的行为,查看各个页面的跳出路径以及停留时间等,根据这些统计数据...

41360
来自专栏性能与架构

微服务架构

微服务产生的背景 在网站初期,网站的架构比较简单,通常把所有代码统一打包部署的服务器上 以java项目为例,例如有5个程序员,他们各自开发自己的功能模块,然后...

37450

扫码关注云+社区

领取腾讯云代金券