如何设计一个系统

数据库刚开始支撑到每秒并发二三千基本就完了，如果瞬间承载每秒5000/8000，甚至上万。一定会宕机。mysql压根扛不住这么高的并发量。 

 

很多app高峰期每秒并发几千，双十一甚至几万几十万。

1、系统拆分

如dubbo，每个系统连接一个数据库。

2、缓存

在计算机的世界中，CPU的处理速度可谓是一马当先，远远甩开了其他操作，尤其是I/O操作，除了那种CPU密集型的系统，其余大部分的业务系统性能瓶颈最后或多或少都会出现在I/O操作上，所以为了减少磁盘的I/O次数，那么缓存是必不可少的，通过缓存的使用我们可以大大减少I/O操作次数，从而在一定程度上弥补了I/O操作和CPU处理速度之间的鸿沟。而在我们ORM框架中引入缓存的目的就是为了减少读取数据库的次数，从而提升查询的效率。

大部分的高并发场景，都是读多写少，可以在数据库和缓存都写一份，读的时候大量走缓存。redis轻松单机几万的并发。

典型应用场景：一趟火车只有2000张票，200W人买，最多2000人下单成功，其他人都是查询库存。（可以加数据库二级缓存、和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将数据消息写入MQ（耗时5ms），成功就返回并提示用户，剩余的BCD系统自己监听MQ并做相应业务操作。那么，这个请求耗时也就是100+5 = 105ms。

4、分库分表

可能到最后