关于高并发和秒杀系统,你知道的和不知道的一些事

这篇文章也算是对于课程 《PHP秒杀系统 高并发高性能的极致挑战》 的一个整理,视频之外的另外一种形式吧。

大家也许开发过高并发的系统或者秒杀程序,但肯定都有接触过,像电商平台的秒杀、抢购等活动,还有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服务当然更好,程序维护数据响应会复杂些。

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

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

课程中用的是PHP语言,开发这类系统也是没问题的。

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

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

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

下面是一些具体的问题:

  • 问题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) 得到递减之后的库存数。

性能方面很好,同时体验上也很好,在PHP秒杀课程中,优化后就是用的这种方法,而没有使用上述其他方法,大家应该也能对比了解啦。

  • 问题2:集群怎么来规划

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上面的内容不知道大家还会有什么疑问,可以给我留言。

具体的关于高并发、秒杀的实战内容,在课程中也有详细的讲解,这里用文字的形式提炼整理出来,希望能更好的帮助大家理解,谢谢~

原文地址:https://www.cnblogs.com/gongxianjin/p/9790060.html

时间: 2024-10-12 18:02:42

关于高并发和秒杀系统,你知道的和不知道的一些事的相关文章

如何解决高并发,秒杀问题

相信不少人会被这个问题困扰,分享大家一篇这样的文章,希望能够帮到你! 一.秒杀业务为什么难做?1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息):2)微博系统,每个人读你关注的人的数据,一个人读多个人的数据:3)秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据. 例如:小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如:12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存.读写冲突,锁非

(转)电商网站50W-100W高并发,秒杀功能是怎么实现的?

电商网站50W-100W高并发,秒杀功能是怎么实现的? 在淘宝.天猫.京东等国内大型电商平台“造节”的带领下,国内各电商平台纷纷跟进,双十一.双十二.618等电商专属节日也吸引了大量的用户参与.节前生意惨淡.访客寥寥,节日当天流量增长却异常迅猛,这对于广大程序猿同学和运维人员来说,无疑是巨大的考验. 秒杀系统的流量虽然很高,但是实际有效流量比较小:利用系统的层次结构,在每个阶段提前校验,拦截无效流量,可以减少大量无效流量涌入数据库,从而保障业务系统的正常运行: 第一步:利用浏览器缓存和CDN加速

高并发实时弹幕系统 并发数一定是可以进行控制的 每个需要异步处理开启的 Goroutine(Go 协程)都必须预先创建好固定的个数,如果不提前进行控制,那么 Goroutine 就随时存在爆发的可能。

小结: 1.内存优化1.一个消息一定只有一块内存使用 Job 聚合消息,Comet 指针引用. 2.一个用户的内存尽量放到栈上内存创建在对应的用户 Goroutine(Go 程)中. 3.内存由自己控制主要是针对 Comet 模块所做的优化,可以查看模块中各个分配内存的地方,使用内存池. 2.模块优化1.消息分发一定是并行的并且互不干扰要保证到每一个 Comet 的通讯通道必须是相互独立的,保证消息分发必须是完全并列的,并且彼此之间互不干扰. 2.并发数一定是可以进行控制的每个需要异步处理开启的

【总结】瞬时高并发(秒杀/活动)Redis方案(转)

转载地址:http://bradyzhu.iteye.com/blog/2270698 1,Redis 丰富的数据结构(Data Structures) 字符串(String) Redis字符串能包含任意类型的数据 一个字符串类型的值最多能存储512M字节的内容 利用INCR命令簇(INCR, DECR, INCRBY)来把字符串当作原子计数器使用 使用APPEND命令在字符串后添加内容 列表(List) Redis列表是简单的字符串列表,按照插入顺序排序 你可以添加一个元素到列表的头部(左边:

PHP高并发商城秒杀

1.什么是秒杀 秒杀活动是一些购物平台推出的集中人气的活动,一般商品数量很少,价格很便宜,限定开始购买的时间,会在以秒为单位的时间内被购买一空.比如原价千元甚至万元的商品以一元的价格出售,但数量只有一件,在某天的某个时间开始出售,这就造成很多人去抢这一件商品.当然想抢到是需要很多因素的,比如你的电脑配置.网速,还有你的运气. 2.秒杀会带来的问题 (1).高并发 比较火热的秒杀在线人数都是10w起的,如此之高的在线人数对于网站架构从前到后都是一种考验. (2).超卖 任何商品都会有数量上限,如何

bilibili高并发实时弹幕系统的实战之路

高并发实时弹幕是一种互动的体验.对于互动来说,考虑最多的地方就是:高稳定性.高可用性以及低延迟这三个方面. 高稳定性,为了保证互动的实时性,所以要求连接状态稳定: 高可用性,相当于提供一种备用方案,比如,互动时如果一台机器挂了,此时必须保证可以和另外一台机器连接,这样就从侧面解决了,用户连接不中断的问题: 低延迟,弹幕的延迟周期控制在1秒以内,响应是比较快的,所以可以满足互动的需求. B站直播弹幕服务架构(下面简称GOIM)的出现就是为了解决这一系列的需求.下面将对此进行详细的介绍. B站直播弹

从宜人贷系统架构看互联网高并发对金融系统架构的挑战

原文:http://www.p2pquan.com/article-740-1.html 一.简介 随着互联网金融的持续火热,越来越多的银行纷纷发布了各自的互联网金融产品.但是互联网产品“高并发.大数据量”的特点却对于银行传统的核心系统架构带来了新的挑战. 1.互联网的核心技术特征 当前互联网的核心技术特征主要可以概括为:分布式,易扩展,大量低端设备,底层开源软件.分布式结构可以通过平行扩展来支撑互联网上蜂拥而至的访问客户.同时,基于客户行为分析的大数据平台也需要分布式系统来完成,其中最典型的就

微信高并发抢红包秒杀实战案例

前言 群里有小伙伴咨询微信红包的架构,对于我来说,显然是不知道的,但是写一个相对高并发的抢红包案例还是完全可以的. 架构设计 业务流程 老板发红包,此时缓存初始化红包个数,红包金额(单位分),并异步入库. 抢红包,判断缓存剩余红包金额,剩余金额大于零则抢到红包,否则手慢了,红包派完了 拆红包,根据 redPacketId 获取分布式锁,如果获取到锁,红包个数减一,如果剩余红包个数大于零抢红包成功.否则失败.成功则计算红包金额,缓存总红包金额减去抢到的红包金额,异步入库.异步到账. 数据库设计 红

Java秒杀系统方案优化 高性能高并发实战 视频教程

第1章 课程介绍及项目框架搭建 1-1 Java高并发商城秒杀优化导学 1-2 项目环境搭建(Eclipse) 1-3 项目环境搭建(IDEA) 1-4 集成mybatis 1-5 安装redis 1-6 集成redis上 1-7 集成redis中 1-8 集成redis下第2章 实现用户登录以及分布式session功能 2-1 两次md5 2-2 登录功能实现上 2-3 登录功能实现下 2-4 jsr303参数校验 2-5 异常处理 2-6 分布式session上 2-7 分布式session