想问问 mysql 要怎么优化才能做到支持每秒一亿并发

[ninblue]

比如数据库存了一个 int 值，这时有大量请求进来服务器在不到一秒内把初始化为一亿的值依次减一最终变成零，并立即给用户响应反馈已经扣减成功了

比如阿里百度这些大厂在春晚几亿人同时抢红包这种功能，是不是也是这么实现的？

[burugui]

@阿里云 @腾讯云 @华为云 工程师

[zwl2012]

@zjsxwc #16 数据机房 40 100G 的口子很多呢

[leonme]

你能做到 500 万，你就能做到 1 亿，因为用户都是库隔离的

[opengps]

首先因素是硬盘

[love]

新手就是这么天真，很多常见的业务都是有成熟的设计模式的，比如秒杀，订单，Feed 流之类。
曾经我呆的公司程序员就是这么做秒杀的，结果测试得好好的到那一天来了系统崩了，程序员很快被 fire 掉了。

[wangyanrui]

@littlewing 拆开呀~ 拆成多份，每份 1/份数

[leeg810312]

这个例子是经典的系统设计案例。系统设计师不仅是设计技术架构，还得理解业务需求，调和技术需求。初级设计师只会冥思苦想我要如何满足 1 亿并发。早年的竞价购买网站已经用过#17 的类似方法，甚至是更假的流程。抽奖程序更是假流程的典型。做过类似功能的都知道要怎么处理。只能说开发过的还是太少。

[CRVV]

@ninblue
不引入缓存，需要强一致性，意味着每一个减一都是一个事务。
每个事务都要求把修改写入硬盘。
你需要一个支持至少 1 亿 iops 的硬盘，显然这样的硬盘不存在。
当然可以用更复杂的方法把储存系统搞到支持 1 亿 iops 。但我这里要说的意思是，这个不是怎么优化 MySQL，而是整个系统的每一部分都需要优化。
至于能不能到 1 亿，如果钱给够，也许可以吧。

[sadfQED2]

如果只是秒杀问题的话，其实 99%的请求都走不到查库这一步，在 httpserver 层就判断返回了，就算到后面业务层，也只会有极少数的请求会走到 db 层，而且 db 会是 redis 之类的 nosql，不会是 mysql

另外，秒杀的时候不需要强一致检验，比如 1000 件商品，秒杀的时候 2000 人加购成功完全没问题，在支付的时候再做强一致的订单检验就 ok(秒杀拦住了大量请求，支付这里也不会有大流量了，而且用户会有填收货地址之类的操作，这里已经没有并发了)

[xsm1890]

楼上的各位基本上把要讲的点都讲到了，凑个楼

[Jooooooooo]

楼上是的是对的, 从业务优化出发

10w 个人抢一个东西, 5w 请求直接拦截在前端或者直接后端 50% 请求直接返回空

[ooozx]

@kop1989 mark

[realpg]

@GM
五个万兆，就算是公网带宽也没几个钱。。。
数据库又不是公网应用

[zhs227]

想起一个笑话，某粗粮公司早期的手机抢购火爆，动不动都是 10 万台 xx 秒售完。某程序员为了提高成功率，早早的备好了抓包工具，准备看看抢购系统的数据格式是什么样的。到点时点了一下抢购按钮，排队又排队，又系统故障又是抢购人员较多重新排队的，弄了 10 来分钟竟然没有抓到除网页以外的动态数据请求。
原来系统只是返回了一段 JS 动画让部分用户感觉到在参与，通过这个方法降低后端的负载。后面有人质疑以后似乎没有再用这种太过明显的方式了。
这种做法从用户角度来讲是不人道的，如果换成国计民生的资源比如过年回家的火车票，就更不人道了。但这几乎是大流量系统的唯一出路（关键词几乎，不接受抬杠），把流量拦截在外层，降低核心层负载来保证操作的一致性。

[bruce0]

@kop1989 太形象了 0.0

[murmur]

国内真一亿并发的公司有几个，阿里双十一的抢购也就每秒几十万单上百万可能还是近些年的事

[murmur]

而且现在都不玩双十一促销了，你当消费者是傻子，消费者也会醒悟，明明天天都可以促销为啥整 0 点不睡觉？所以今年从 61 到 620 都是 618，而且每天价格都不一样，并发是可以通过业务化解的

[liuguang]

MySQL 本身完全不可能做到

[inktiger]

每秒 1 亿不现实，还是 mysql，不借助队列和缓存不好搞的，阿里双十一每秒也就百万级别，千万级都少，更别谈亿了

[smallpython]

把用户分成 1 万份, 每份抢 1 万元红包