数据库刚开始支撑到每秒并发二三千基本就完了，如果瞬间承载每秒5000/8000，甚至上万。一定会宕机。mysql压根扛不住这么高的并发量。
很多app高峰期每秒并发几千，双十一甚至几万几十万。
1、系统拆分
如dubbo，每个系统连接一个数据库。
2、缓存
大部分的高并发场景，都是读多写少，可以在数据库和缓存都写一份，读的时候大量走缓存。redis轻松单机几万的并发。
3、MQ
高并发写的场景，大量的写请求灌入MQ，排队，后面系统消费后慢慢写，控制在mysql承载范围之内。
用户100万请求--->全写入MQ---> 系统A每次去MQ消费2000条 --->mysql
3.1、MQ其余使用场景
发布订阅模型：
场景是系统A会产生用户ID：userId，要把userId通过调用系统B\C\D的接口传给他们做业务处理。若添加新系统，也需要此userId，则要再加一个接口调用。耦合严重。
解耦的做法就是：在系统A与系统BCD之间，增加消息队列MQ，系统A产生userId后，将其放入MQ，系统BCD通过监听MQ，来消费userId。
3.2、异步：主要解决请求的耗时
场景是用户发送请求到系统A，系统A执行完本地SQL（耗时100ms）后，还要调用BCD三个系统的接口，假设三次调用都耗时200ms。那么，总共一次请求耗时700ms。一旦调用接口变多，耗时会变得更长。
使用MQ解决耗时长的办法就是，在系统A与系统BCD之间分别增加MQ，系统A将数
开通VIP 解锁文章