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

关键词：
秒杀 mysql redis memcache

怎么可能光靠 mysql 实现的,都是各种 mq,nosql,集群一起上才把这种大并发的任务给实现的

你看到的红包早就是放在队列里拆分好的一个一个的小红包了，不会去现场计算的

@dzdh 如果不引入缓存要怎么做，需要强一致性的

@ninblue 不是最终一致吗？

每秒 1 亿并发是啥概念...

很多场景都不是靠性能优化的。而是靠业务优化。
比如你说的抢红包，都是“假”抢。
你看到的秒杀也是“假”秒。
你以为的数据库高压场景跟美国打砸抢烧一样是人往里冲。
实际上是一个广场上，用机枪扫射，活下来的人走进商场买东西。

1E 呀，单用 MySQL 实现，这得个多大的集群啊！

每次并发请求传输数据 5kB，
每秒一亿并发大概需要 4T 的带宽

@kop1989 #6 一下子有画面了

单机是不可能的

@adrianXu 有想过集群，但是一个 int 值只能存在一个服务器里好像也拆不出来吧

@wangyanrui 多大的集群都没用，因为是单行更新

梦里啥都有

这个是一亿 qps，不是一亿并发

@kop1989 就是说只能是换种实现思路了，把修改值变成从队列拉取

@zjsxwc 市面上好像没有 4T 的单机路由器吧，最多是千兆带宽路由。

@ninblue #15 你这思路还是太窄，甚至都不需要拉取，直接就是一个“预打款”下发到本地 app，新年的时候点击本地直接把到账信息 show 出来就 ok 。
然后我猜你会说这样的话红包余额不严谨，容易欠发。（超发基本不可能）
欠不欠发都是马云说了算?。

然后秒杀的场景，可以进行多级淘汰。
1 、秒杀之前几天，先把“预约”的账号洗一遍，留下预售数量 200%左右的账号，其他账号秒杀当天的请求直接抛弃。
2 、秒杀当场，按照请求缓存队列随机枪毙请求，剩下 110%。进入下单流程。
3 、最终下单再进行数据库严格校验。锁定账号——货品的对应信息。

程序员就是这么天真

每秒一亿并发？没搞错数字吗？
首先你需要约 50Gbps 的带宽，光是为了支持这个带宽，每月费用起码是数百万的级别。

@kop1989 涨姿势了

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

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

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

首先因素是硬盘

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

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

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

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

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

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

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

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

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

@kop1989 mark

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

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

@kop1989 太形象了 0.0

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

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

MySQL 本身完全不可能做到

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

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

您搁这里修航母呢？
每秒 1 亿并发，就算全地球人类加起来， 同时用你产品也达不到 每秒 1 亿并发。

言归正传，这类并发都是用障眼法来优化业务，比如抢红包，红包发出来那一刻金额就已经拆分好，
电商秒杀，给你个随机数看起来在排队，实际是让人错开几秒进入业务
抢票，给你出验证码，这样根据输入验证码速度的快慢也是把压力错开了，
等等，都是巧妙的用 UI 或动画来优化业务的

用户表按地区分库 按地区分商品库
强迫用户安装应用 每次打开时获取用户位置，然后在所在地区的用户表中查询用户，没找到再去主表拉取（中间可能会牵涉到多表同步策略，这个可以在凌晨三四点跑定时任务来解决）
在地区商品存里再进行秒杀操作

如果有些区域确实用户比较多比如北上广，地区甚至可以多一个层级到区
这样压力就没有了

加钱世界可及...

假的

100000000QPS 恐怕连火星人来抢红包的场景都考虑到了吧。

疯求了

一亿=100,000,000
100 million

抓了一下请求百度的一个单一请求（其实是一个 tcp stream，毕竟 https 分辨不了内容
5k 左右

一亿个这样的请求
500,000,000,000 bytes
这可是每秒 500g 的流量

你确定你要先考虑数据库的问题？

双十一的时候，支付宝也就是 25w 比 /S 左右

单用 mysql 的话就看你有多少钱了

这个业务流程优化都是实践中得来的,如果想学可以看看大厂的大佬的做法,不然自己摸索成本很高的,除非老板钱多可以给你弄点服务器测试

100 年后的服务器和 MySQL 应该随便支持无需优化了。

@ninblue #11 100 个数据库，每个只百万级别了
然后后端随机选择一个数据库服务器。

@realpg 你确定五个万兆没多少钱？请弄清楚什么叫“带宽”，什么叫“流量”，流量确实没几个钱，阿里云流量大概是 0.8 元 /G 。

50Gbps 的带宽，一个月低于 100 万我直播吃屎。

去问 google 怎么做的

@kop1989 哈哈哈哈哈

@vone #45 火星 ping 太高，抢不到的

@GM 这个也看区域的，我们最低的洛杉矶机房 1Gbps 低于 50 美金，BGP 的，跑满，量大还能更低
做大带宽批发的 fdcservers 更低，100Gbps 以上都有

所以你应该标注个国家 不然你吃定了，2333333 /doge

上液氮、超频到 114514GHz

春晚你确定有几亿人同时抢红包？如果真有，中国没有一家公司能做好这个事，必挂。再说，总是在提并发，所谓的技术人都是在堆积木，不是 redis 就是 kafka 之类的，排列组合，加集群，这不算本事。为什么不想想，怎么做出一个 redis 或者一个 VM，能为下一代的高性能计算提供一些基石。

@casillasyi 为什么不做？因为没有需求。没有新的大规模的需求，就无法产生创新的理念与技术

@GM #53
来吧 我们签合同 一级运营商三家随便选 一个净 10Gbps 端口只要 15 万，50Gbps 就 75 万，全中国除了西藏新疆，任何省任何运营商都可以~

抖音直播还是啥直播？

@GM #53
一级运营商的目录价，15/Mbps*月，从来没有傻逼用这个价签合同的……

Web 层肯定要考虑集群，这个是常识。根据业务系统 QPS 、负载和所需带宽做容量规划。
写个业务中间件或者微服务，实现抢红包这个逻辑。因为量大只能指望内存中计算了，存储到消息队列集群。保证最终逐步同步到 mysql 集群就好了。

要求这个服务用最简单的方式实现，缩减无关的程序指令…

1 个亿的并发没问题，前提是机器够！元子性保证和容灾设计是大头。
但是请求不可能要靠一个集群来扛。如果业务本身比较复杂，还得考虑请求的路由问题，根据请求进行分区读写 Cache 。每个数据中心可用区都打通了专线，传输延迟按照 10ms 算，用户对后端业务延迟的感知基本可以忽略不计。
容灾是个问题

@kop1989 说到这个就想起我们公司做的抽奖。其实每次都是后台 BA 从数据库拉随机用户出来，最后批量颁发奖项的。而且因为奖品和账户正相关，所以就算随机到了大客户，也会从名单里删除。。。

最简单的办法，加一亿个 mysql 节点，算下来并发也才 1 ！你举得例子我觉得都是靠堆服务器完成的

都有 1 亿并发流量了，请不起会写秒杀的程序员么？

本来只是修个自行车，你却非要问成修航母。虽然都是拧螺丝，但是螺丝的大小和数量真的没区别吗？
另外回答问题，mysql 自己做不到，需要其他中间件支持。

@zwl2012 100G 离 4T 差远了

@kop1989 大佬，那么火车票抢票是如何实现的呢，如果按你说的话，那 12306 是不是现在比较可能的并发最大的场景

@hangszhang 每秒一亿并发就是一亿 qps

@youngster #70 你猜 12306 的 loading 拿来干嘛的 ，你哪次抢票没 loading ？

@JerryCha 全人类感谢你 11451.4 次

@youngster 这个比较简单吧，只要每个列车、甚至每个班次单独一个服务器，路由数据预先加载到 App 中，每台服务器的压力会小很多。

@youngster #70 如果论并发，我个人认为越即时的请求越难以在业务上处理。比如除夕微信互抢红包。
12306 的技术性其实也很强，主要是火车存在跨站票量同步、行程冲突校验等问题，虽然明显能感觉到 12306 其实不是实时同步的（比如所谓的全程票好抢）。
但 12306 再复杂，也是既定业务，可以有优化的空间。

@realpg 我是没想到一级运营商，原始货源自然是最便宜的。

在下输了。。。。

@ohao 这里讨论的默认是国内吧，国外流量那么便宜，随便个 vps 就给 100Mbps 不限速，不能比的。

这种问题居然还能讨论。。

但凡花点时间了解一下 mysql 就不会有这个问题的出现了

一亿的 QPS， 阿里的双 11 也没那么大的流量吧，这种场景单独讨论 mysql 意义不大

12306 刚出来那几年不也一堆人喷吗.. 这几年稍微好一点了

哪里有那么大的量打到 mysql 集群 ，就算有也要业务优化，不允许打到 mysql 的请求 这么多

这是架构的问题, 不是优化的问题...

但凡花点时间了解一下 MySql 就不会有这个问题的出现了

又学到了新技能。

MySQL 是可以做到的。阿里云 MySQL 就有电商秒杀版本。当然价格也不便宜。

学习下

@atonku