比如数据库存了一个 int 值,这时有大量请求进来服务器在不到一秒内把初始化为一亿的值依次减一最终变成零,并立即给用户响应反馈已经扣减成功了
比如阿里百度这些大厂在春晚几亿人同时抢红包这种功能,是不是也是这么实现的?
1
dzdh 2020-07-20 12:15:33 +08:00
关键词:
秒杀 mysql redis memcache |
2
adrianXu 2020-07-20 12:16:05 +08:00
怎么可能光靠 mysql 实现的,都是各种 mq,nosql,集群一起上才把这种大并发的任务给实现的
|
3
lshero 2020-07-20 12:18:35 +08:00
你看到的红包早就是放在队列里拆分好的一个一个的小红包了,不会去现场计算的
|
6
kop1989 2020-07-20 12:25:22 +08:00 92
很多场景都不是靠性能优化的。而是靠业务优化。
比如你说的抢红包,都是“假”抢。 你看到的秒杀也是“假”秒。 你以为的数据库高压场景跟美国打砸抢烧一样是人往里冲。 实际上是一个广场上,用机枪扫射,活下来的人走进商场买东西。 |
7
wangyanrui 2020-07-20 12:26:02 +08:00
1E 呀,单用 MySQL 实现,这得个多大的集群啊!
|
8
zjsxwc 2020-07-20 12:28:21 +08:00 2
每次并发请求传输数据 5kB,
每秒一亿并发大概需要 4T 的带宽 |
10
Jackeriss 2020-07-20 12:30:13 +08:00 via iPhone
单机是不可能的
|
12
littlewing 2020-07-20 12:33:39 +08:00
@wangyanrui 多大的集群都没用,因为是单行更新
|
13
liprais 2020-07-20 12:33:47 +08:00 via iPhone 1
梦里啥都有
|
14
hangszhang 2020-07-20 12:34:20 +08:00 1
这个是一亿 qps,不是一亿并发
|
17
kop1989 2020-07-20 12:43:35 +08:00 27
@ninblue #15 你这思路还是太窄,甚至都不需要拉取,直接就是一个“预打款”下发到本地 app,新年的时候点击本地直接把到账信息 show 出来就 ok 。
然后我猜你会说这样的话红包余额不严谨,容易欠发。(超发基本不可能) 欠不欠发都是马云说了算😀。 然后秒杀的场景,可以进行多级淘汰。 1 、秒杀之前几天,先把“预约”的账号洗一遍,留下预售数量 200%左右的账号,其他账号秒杀当天的请求直接抛弃。 2 、秒杀当场,按照请求缓存队列随机枪毙请求,剩下 110%。进入下单流程。 3 、最终下单再进行数据库严格校验。锁定账号——货品的对应信息。 |
18
jugelizi 2020-07-20 12:46:18 +08:00 via iPhone
程序员就是这么天真
|
19
GM 2020-07-20 12:49:39 +08:00
每秒一亿并发?没搞错数字吗?
首先你需要约 50Gbps 的带宽,光是为了支持这个带宽,每月费用起码是数百万的级别。 |
20
dream4ever 2020-07-20 12:50:37 +08:00
@kop1989 涨姿势了
|
21
burugui 2020-07-20 12:52:24 +08:00
@阿里云 @腾讯云 @华为云 工程师
|
23
leonme 2020-07-20 13:05:53 +08:00 via iPhone
你能做到 500 万,你就能做到 1 亿,因为用户都是库隔离的
|
24
opengps 2020-07-20 13:06:37 +08:00 via Android
首先因素是硬盘
|
25
love 2020-07-20 13:07:16 +08:00
新手就是这么天真,很多常见的业务都是有成熟的设计模式的,比如秒杀,订单,Feed 流之类。
曾经我呆的公司程序员就是这么做秒杀的,结果测试得好好的到那一天来了系统崩了,程序员很快被 fire 掉了。 |
26
wangyanrui 2020-07-20 13:11:28 +08:00
@littlewing 拆开呀~ 拆成多份,每份 1/份数
|
27
leeg810312 2020-07-20 13:11:51 +08:00 via Android
这个例子是经典的系统设计案例。系统设计师不仅是设计技术架构,还得理解业务需求,调和技术需求。初级设计师只会冥思苦想我要如何满足 1 亿并发。早年的竞价购买网站已经用过#17 的类似方法,甚至是更假的流程。抽奖程序更是假流程的典型。做过类似功能的都知道要怎么处理。只能说开发过的还是太少。
|
28
CRVV 2020-07-20 13:15:11 +08:00 via Android
@ninblue
不引入缓存,需要强一致性,意味着每一个减一都是一个事务。 每个事务都要求把修改写入硬盘。 你需要一个支持至少 1 亿 iops 的硬盘,显然这样的硬盘不存在。 当然可以用更复杂的方法把储存系统搞到支持 1 亿 iops 。但我这里要说的意思是,这个不是怎么优化 MySQL,而是整个系统的每一部分都需要优化。 至于能不能到 1 亿,如果钱给够,也许可以吧。 |
29
sadfQED2 2020-07-20 13:46:29 +08:00 via Android
如果只是秒杀问题的话,其实 99%的请求都走不到查库这一步,在 httpserver 层就判断返回了,就算到后面业务层,也只会有极少数的请求会走到 db 层,而且 db 会是 redis 之类的 nosql,不会是 mysql
另外,秒杀的时候不需要强一致检验,比如 1000 件商品,秒杀的时候 2000 人加购成功完全没问题,在支付的时候再做强一致的订单检验就 ok(秒杀拦住了大量请求,支付这里也不会有大流量了,而且用户会有填收货地址之类的操作,这里已经没有并发了) |
30
xsm1890 2020-07-20 13:50:24 +08:00
楼上的各位基本上把要讲的点都讲到了,凑个楼
|
31
Jooooooooo 2020-07-20 14:18:33 +08:00
楼上是的是对的, 从业务优化出发
10w 个人抢一个东西, 5w 请求直接拦截在前端或者直接后端 50% 请求直接返回空 |
34
zhs227 2020-07-20 15:58:13 +08:00
想起一个笑话,某粗粮公司早期的手机抢购火爆,动不动都是 10 万台 xx 秒售完。某程序员为了提高成功率,早早的备好了抓包工具,准备看看抢购系统的数据格式是什么样的。到点时点了一下抢购按钮,排队又排队,又系统故障又是抢购人员较多重新排队的,弄了 10 来分钟竟然没有抓到除网页以外的动态数据请求。
原来系统只是返回了一段 JS 动画让部分用户感觉到在参与,通过这个方法降低后端的负载。后面有人质疑以后似乎没有再用这种太过明显的方式了。 这种做法从用户角度来讲是不人道的,如果换成国计民生的资源比如过年回家的火车票,就更不人道了。但这几乎是大流量系统的唯一出路(关键词几乎,不接受抬杠),把流量拦截在外层,降低核心层负载来保证操作的一致性。 |
36
murmur 2020-07-20 16:06:18 +08:00
国内真一亿并发的公司有几个,阿里双十一的抢购也就每秒几十万单上百万可能还是近些年的事
|
37
murmur 2020-07-20 16:07:32 +08:00
而且现在都不玩双十一促销了,你当消费者是傻子,消费者也会醒悟,明明天天都可以促销为啥整 0 点不睡觉?所以今年从 61 到 620 都是 618,而且每天价格都不一样,并发是可以通过业务化解的
|
38
liuguang 2020-07-20 16:21:43 +08:00
MySQL 本身完全不可能做到
|
39
inktiger 2020-07-20 17:14:58 +08:00
每秒 1 亿不现实,还是 mysql,不借助队列和缓存不好搞的,阿里双十一每秒也就百万级别,千万级都少,更别谈亿了
|
40
smallpython 2020-07-20 17:37:22 +08:00
把用户分成 1 万份, 每份抢 1 万元红包
|
41
ajaxfunction 2020-07-20 17:41:16 +08:00 1
您搁这里修航母呢?
每秒 1 亿并发,就算全地球人类加起来, 同时用你产品也达不到 每秒 1 亿并发。 言归正传,这类并发都是用障眼法来优化业务,比如抢红包,红包发出来那一刻金额就已经拆分好, 电商秒杀,给你个随机数看起来在排队,实际是让人错开几秒进入业务 抢票,给你出验证码,这样根据输入验证码速度的快慢也是把压力错开了, 等等,都是巧妙的用 UI 或动画来优化业务的 |
42
soulzz 2020-07-20 17:46:37 +08:00
用户表按地区分库 按地区分商品库
强迫用户安装应用 每次打开时获取用户位置,然后在所在地区的用户表中查询用户,没找到再去主表拉取(中间可能会牵涉到多表同步策略,这个可以在凌晨三四点跑定时任务来解决) 在地区商品存里再进行秒杀操作 如果有些区域确实用户比较多比如北上广,地区甚至可以多一个层级到区 这样压力就没有了 |
43
nlysh007 2020-07-20 17:55:17 +08:00
加钱世界可及...
|
44
peng0416 2020-07-20 17:56:06 +08:00
假的
|
45
vone 2020-07-20 18:17:23 +08:00
100000000QPS 恐怕连火星人来抢红包的场景都考虑到了吧。
|
46
nmap 2020-07-20 18:17:28 +08:00
疯求了
|
47
GeruzoniAnsasu 2020-07-20 18:41:14 +08:00
一亿=100,000,000
100 million 抓了一下请求百度的一个单一请求(其实是一个 tcp stream,毕竟 https 分辨不了内容 5k 左右 一亿个这样的请求 500,000,000,000 bytes 这可是每秒 500g 的流量 你确定你要先考虑数据库的问题? |
48
zchlwj 2020-07-20 18:51:44 +08:00
双十一的时候,支付宝也就是 25w 比 /S 左右
|
49
framlog 2020-07-20 18:54:16 +08:00
单用 mysql 的话就看你有多少钱了
|
50
huayumo 2020-07-20 19:02:14 +08:00
这个业务流程优化都是实践中得来的,如果想学可以看看大厂的大佬的做法,不然自己摸索成本很高的,除非老板钱多可以给你弄点服务器测试
|
51
gimp 2020-07-20 19:22:40 +08:00
100 年后的服务器和 MySQL 应该随便支持无需优化了。
|
53
GM 2020-07-20 19:38:37 +08:00
|
54
cnrting 2020-07-20 19:48:43 +08:00 via iPhone
去问 google 怎么做的
|
57
ohao 2020-07-20 22:10:45 +08:00 via iPhone
@GM 这个也看区域的,我们最低的洛杉矶机房 1Gbps 低于 50 美金,BGP 的,跑满,量大还能更低
做大带宽批发的 fdcservers 更低,100Gbps 以上都有 所以你应该标注个国家 不然你吃定了,2333333 /doge |
58
JerryCha 2020-07-20 22:48:30 +08:00 1
上液氮、超频到 114514GHz
|
59
casillasyi 2020-07-20 22:52:37 +08:00 1
春晚你确定有几亿人同时抢红包?如果真有,中国没有一家公司能做好这个事,必挂。再说,总是在提并发,所谓的技术人都是在堆积木,不是 redis 就是 kafka 之类的,排列组合,加集群,这不算本事。为什么不想想,怎么做出一个 redis 或者一个 VM,能为下一代的高性能计算提供一些基石。
|
60
neoblackcap 2020-07-20 23:01:35 +08:00
@casillasyi 为什么不做?因为没有需求。没有新的大规模的需求,就无法产生创新的理念与技术
|
61
realpg 2020-07-21 00:33:18 +08:00 1
|
63
DoctorCat 2020-07-21 02:33:32 +08:00
Web 层肯定要考虑集群,这个是常识。根据业务系统 QPS 、负载和所需带宽做容量规划。
写个业务中间件或者微服务,实现抢红包这个逻辑。因为量大只能指望内存中计算了,存储到消息队列集群。保证最终逐步同步到 mysql 集群就好了。 要求这个服务用最简单的方式实现,缩减无关的程序指令… |
64
DoctorCat 2020-07-21 02:46:45 +08:00
1 个亿的并发没问题,前提是机器够!元子性保证和容灾设计是大头。
但是请求不可能要靠一个集群来扛。如果业务本身比较复杂,还得考虑请求的路由问题,根据请求进行分区读写 Cache 。每个数据中心可用区都打通了专线,传输延迟按照 10ms 算,用户对后端业务延迟的感知基本可以忽略不计。 容灾是个问题 |
65
levelworm 2020-07-21 03:09:21 +08:00
@kop1989 说到这个就想起我们公司做的抽奖。其实每次都是后台 BA 从数据库拉随机用户出来,最后批量颁发奖项的。而且因为奖品和账户正相关,所以就算随机到了大客户,也会从名单里删除。。。
|
66
atonku 2020-07-21 08:47:26 +08:00
最简单的办法,加一亿个 mysql 节点,算下来并发也才 1 !你举得例子我觉得都是靠堆服务器完成的
|
67
aeli 2020-07-21 09:11:07 +08:00
都有 1 亿并发流量了,请不起会写秒杀的程序员么?
|
68
cco 2020-07-21 09:31:45 +08:00
本来只是修个自行车,你却非要问成修航母。虽然都是拧螺丝,但是螺丝的大小和数量真的没区别吗?
另外回答问题,mysql 自己做不到,需要其他中间件支持。 |
70
youngster 2020-07-21 09:58:02 +08:00
@kop1989 大佬,那么火车票抢票是如何实现的呢,如果按你说的话,那 12306 是不是现在比较可能的并发最大的场景
|
71
youngster 2020-07-21 09:59:06 +08:00
@hangszhang 每秒一亿并发就是一亿 qps
|
72
zhongjun96 2020-07-21 10:06:50 +08:00
@youngster #70 你猜 12306 的 loading 拿来干嘛的 ,你哪次抢票没 loading ?
|
74
zjsxwc 2020-07-21 10:10:55 +08:00
@youngster 这个比较简单吧,只要每个列车、甚至每个班次单独一个服务器,路由数据预先加载到 App 中,每台服务器的压力会小很多。
|
75
kop1989 2020-07-21 10:22:08 +08:00
@youngster #70 如果论并发,我个人认为越即时的请求越难以在业务上处理。比如除夕微信互抢红包。
12306 的技术性其实也很强,主要是火车存在跨站票量同步、行程冲突校验等问题,虽然明显能感觉到 12306 其实不是实时同步的(比如所谓的全程票好抢)。 但 12306 再复杂,也是既定业务,可以有优化的空间。 |
78
wu1990 2020-07-21 10:58:24 +08:00
这种问题居然还能讨论。。
|
79
someonedeng 2020-07-21 11:20:50 +08:00
但凡花点时间了解一下 mysql 就不会有这个问题的出现了
|
80
ShadowAble 2020-07-21 11:30:14 +08:00
一亿的 QPS, 阿里的双 11 也没那么大的流量吧,这种场景单独讨论 mysql 意义不大
|
81
2kCS5c0b0ITXE5k2 2020-07-21 11:32:46 +08:00
12306 刚出来那几年不也一堆人喷吗.. 这几年稍微好一点了
|
82
guanhui07 2020-07-21 11:53:46 +08:00
哪里有那么大的量打到 mysql 集群 ,就算有也要业务优化,不允许打到 mysql 的请求 这么多
|
83
jeeyong 2020-07-21 11:56:54 +08:00
这是架构的问题, 不是优化的问题...
|
84
JokeEnd 2020-07-21 12:02:28 +08:00
但凡花点时间了解一下 MySql 就不会有这个问题的出现了
|
85
ulpyxua 2020-07-21 12:15:53 +08:00
又学到了新技能。
|
86
mmdsun 2020-07-21 12:35:49 +08:00 via Android
MySQL 是可以做到的。阿里云 MySQL 就有电商秒杀版本。当然价格也不便宜。
|
87
Funian 2020-07-22 09:55:46 +08:00
学习下
|