架构实战案例解析
王庆友
前1号店首席架构师
立即订阅
2680 人已学习
课程目录
已完结 23 讲
0/4登录后,你可以任选4讲全文学习。
概述篇 (2讲)
开篇词 | 想吃透架构?你得看看真实、接地气的架构案例
免费
01 | 架构的本质:如何打造一个有序的系统?
业务架构篇 (9讲)
02 | 业务架构:作为开发,你真的了解业务吗?
03 | 可扩展架构:如何打造一个善变的柔性系统?
04 | 可扩展架构案例(一):电商平台架构是如何演变的?
05 | 可扩展架构案例(二):App服务端架构是如何升级的?
06 | 可扩展架构案例(三):你真的需要一个中台吗?
07 | 可复用架构:如何实现高层次的复用?
08 | 可复用架构案例(一):如何设计一个基础服务?
09 | 可复用架构案例(二):如何对现有系统做微服务改造?
10 | 可复用架构案例(三):中台是如何炼成的?
技术架构篇 (9讲)
11 | 技术架构:作为开发,你真的了解系统吗?
12 | 高可用架构:如何让你的系统不掉链子?
13 | 高可用架构案例(一):如何实现O2O平台日订单500万?
14 | 高可用架构案例(二):如何第一时间知道系统哪里有问题?
15 | 高可用架构案例(三):如何打造一体化的监控系统?
16 | 高性能和可伸缩架构:业务增长,能不能加台机器就搞定?
17 | 高性能架构案例:如何设计一个秒杀系统?
18 | 可伸缩架构案例:数据太多,如何无限扩展你的数据库?
19 | 综合案例:电商平台技术架构是如何演变的?
总结篇 (2讲)
20 | 从务实的角度,给你架构设计的重点知识和学习路径
结束语 | 和你聊聊我的架构心路历程
结课测试 (1讲)
结课测试 | “架构实战案例解析”100分试卷等你来挑战!
架构实战案例解析
15
15
1.0x
00:00/00:00
登录|注册

17 | 高性能架构案例:如何设计一个秒杀系统?

王庆友 2020-03-30
你好,我是王庆友。
在上一讲中,我和你详细介绍了打造一个高性能系统的应对策略和架构手段。那么今天,我就以 1 号店的秒杀系统为例,来具体说明如何实现一个高性能的系统。

背景和问题

先说下背景。在 2014 年的时候,1 号店作为网上超市类电商,经常在线上举行各种大促活动。比如进口牛奶促销活动,每次促销的牛奶有几十万盒,促销价格非常优惠,一般这样的促销活动会在某个整点的时间进行开卖(如上午 10 点)。对于这种质高价优并且是刚需的商品,会有大量的用户来抢购,俗话说“手快有,手慢无”,往往短短几分钟内,所有牛奶就能售卖完毕。
这本质上是一种秒杀活动,但商品数量非常大,一瞬间会有大量的用户流量涌入,流量可以高达平时的几十倍。而且和少量商品的秒杀不同,这些都是有效流量,最终会生成订单。
而在正常情况下,系统因为资源有限,只能处理 10% 的流量,无法处理剩下的 90% 流量,瞬间高并发的流量涌入,很大程度上会引起后台系统超时报错,导致用户下单不成功。这样一来,用户就会反复刷新页面,多次尝试下单,不但用户的体验不好,而且系统的压力会更大。
最终的结果就是,系统往往由于过载,整体处理能力下降,甚至瘫痪,导致所有用户都无法购买。就像下图表示的一样,在秒杀场景下,系统会面临这样的困境:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《架构实战案例解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(16)

  • 小祺
    20W用户下单成功,后面的用户提示下单失败,预下单成功的用户全部放弃支付,导致活动结束了但是商品没卖出去,怎么解决?

    作者回复: 后台下单时,会有异常订单自动审核,比如黄牛下的单,恶意订单等,这部分库存会回到前台可用队列中,只要是正常订单,不会出现大面积不支付的情况

    2020-03-31
    3
  • 孙同学
    https://www.processon.com/view/link/5e51378ce4b0c037b5f9d1e3 整理学习更新 又学到一些 自己之前做过一个思想类似的 利用redis做缓存 异步慢慢消费数据
    2020-03-30
    1
  • Jeff.Smile
    如果有些前置知识会比较好,比如流量洪峰到来的时候对于秒杀这种类型的活动,首先要把流量接下来,起码不能在网关入口处就被拒绝了,这个时候能用到的技术有哪些,比如nginx或者其他的方式。接下来,流量怎么分发到后端的应用服务器,负载均衡或者是直接操作redis,这里也有一些技术点。
    老师整体上讲的比较言简意赅,不过我还是想关注下一些技术点,哪怕一笔带过略微提一下,也可以受益匪浅哈!感谢!

    作者回复: 对于接入系统来说,这点流量照常接,没有变化,所以文章里就没提

    2020-03-30
    1
  • zeor
    老师您好,当正常下单时采用同步方式,但流量也很大,如果按您说的,库存只有一个库,但库已经达到了瓶颈,有什么方式在同步情况下解决这个瓶颈?

    作者回复: 可以用redis放库存数据,利用redis的锁保证互斥访问。这样相当于把redis作为前置数据库。
    应用直接改redis数据,通过发消息,再异步改db的数据。

    2020-03-30
    1
    1
  • Jxin
    1.秒杀案例讲得很棒。
    2.外卖那个场景,其实单纯讲加机器,易伸缩。感觉没说到点子上。这个场景其实是做性能优化,价值会很高的场景。如何通过技术手段和各种权衡,在有限的资源下满足更多的并发。这个话题会比较在点子上。
    3.限于篇幅,已经很棒,感谢栏主分享。
    2020-03-30
    1
  • 乖,摸摸头
    根据排队号获取消息在队列中的位置,是怎么实现的?redis list 并没找到这样的接口。如果是通过 LINDEX 来获取,感觉比 遍历还慢。

    为啥还要弄个请求队列,不直接去读商品秒杀队列,商品队列读取不到了就返回失败
    2020-06-15
  • 旅途
    老师,后台服务消费队列的线程数这个是压测得来的吗,这个是使用的程序内部的线程是吧

    作者回复: 这个主要是评估后面下单服务的处理能力,把下单能力充分发挥就可以。每个消费者是一个线程

    2020-05-28
  • Robin康F
    公司应对高并发的措施有:限流、降级、异步消息、redis缓存化、增加节点
    2020-05-07
  • 密码123456
    通过排队系统,对流量进行消峰
    2020-05-07
  • ……
    根据排队号获取消息再队列中的位置,怎么实现的,通过遍历吗?

    作者回复: 不是遍历,遍历太慢,具体你看下redis list对象提供的接口。

    2020-04-15
  • 雨霖铃声声慢
    我们的并发场景没那么多用户,所以靠最土的办法: 增加机器节点+缓存 扛过去的,囧
    2020-04-06
  • 小洛
    首先感谢老师您的分享 有两个问题请教下老师:
    1、一个秒杀商品一个单独redis队列,如果秒杀商品几十万,就算按照1:1的比例 那么理论上瞬间也有10万的请求打到redis上,单个redis 支撑10W, 这里是不是还有一些限流的策略?
    2、老师能加餐分享下库存的方案吗

    作者回复: 10万请求入队,是分1-2分钟,处理得过来,要限流的话,直接在接入层就限流。

    2020-04-05
  • 蓝天
    排队数据存在redis中是不也需要开启持久化呢

    作者回复: 很好的思考,要持久化的,这是关键的业务数据。

    2020-03-31
    1
  • 正在减肥的胖籽。
    老师您好。我有几个问题先请教你下。
    1.如果系统有上万个商品,redis一个商品一个队列,然后生成上万个队列?
    2.异步化处理逻辑,来削峰流量。但是如果需要同步,库存事实扣的?这种可以讲一下吗?因为数据库是有状态的,数据库并发能力就比较弱,这方面可以讲一下吗?
    3.

    作者回复: 1.秒杀不会有上万个商品,一般就十几个
    2.异步处理,后台下单根据实际能力来,库存正常该怎么扣就怎么扣,一分钟更新1-2万次不是问题

    2020-03-31
  • tt
    这节课讲得方法挺适合我们的,我们之前上过一个抢购的活动,由于没有经验,所以跑起来很卡,今天讲的方法不复杂,还能解决问题,真好。
    2020-03-30
  • 阿杜
    讲解的比较精炼,也很实用,能满足大部分秒杀业务,业务落地简单快速。
    2020-03-30
收起评论
16
返回
顶部