面试官：请您从并发压力的角度分析一下MySQL数据库架构是如何演进的。系统是那种并发压力小，数据量小的系统，所以就算上线了，也只是正常运行而已。但是你知道你连接的MySQL数据库能承受多大的并发压力吗？如果MySQL数据库再也承受不住压力，你知道它应该如何进化吗？通用业务系统运行流程图首先我们来看最基本的其实简单来说，我们通常使用SpringBoot+SSM技术栈开发一个Java业务系统，使用SpringBoot嵌入Tomcat对外提供Http接口.那么现在顶多增加Nacos+Dubbo调用其他系统接口，所有的数据都可以通过连接MySQL数据库进行粗制。如下图所示：上面架构的系统估计是很多兄弟每天做的最多的系统架构了。有的兄弟把它弄高了一点。一般来说，他们可能会加一些ES，Redis，RocketMQ之类的。中间件使用简单。不过大体上是这样的，言归正传。你知道在你上面说的系统下，你连接的数据库能承受多大的压力吗？4核8G机器能处理多少并发？说实话，要解决这个问题，一般来说，并不是首先要讲数据能承受多大的压力，因为首先抗住高并发的往往不是数据库，而是你连接的web系统数据库首先要抗高并发！那就是我们的SpringBoot我们首先要搞清楚SSM业务系统能抗多高的并发！那么要搞清楚这个问题，首先要说一个话题。一般来说，我们的SpringBoot应用系统大致部署在2核4G或者4核8G的机器上，这个机器配置其实是非常关键的。所以这里有一个经验直接告诉大家，即使我们部署4核8G的机器，那么SpringBoot中嵌入的Tomcat默认开启200个线程来处理请求，然后每次请求都要多次读写数据库。所以这个时候粗略的说，你的一台机器可以承受大概500~1000的并发量，看你接口的复杂程度。如下图所示：高并发来袭时，数据库会先被kill掉吗？所以其实一般来说，当你的高并发压力来袭的时候，往往不是数据库先扛不住，而是你的业务系统机器承受不住了。比如你部署两台机器，其实在每秒一两千并发的情况下，这两台机器的CPU负载基本都会飙升到90%以上，压力很大，接口性能开始下降很多。如下图所示：那么此时我们的数据库压力会怎样呢？其实一般来说，你们两台机器每秒承受一两千个请求后，数据库压力通常会达到一个小瓶颈。为什么？关键你的业务系统在处理每一个业务请求的时候，都会对数据库进行多次读写，所以业务系统的一个请求可能会引起对数据库的多次请求。正因为如此，你的数据库可能并发压力会在几千。一个8核16G的数据库每秒能承受多大的并发压力？那么下一个问题就是，你的数据库一般部署在什么样的机器上？一般来说，我告诉你，如果数据库配置是在并发特别低的场景下，2核4G或者4核8G就够了，但是如果是比较常规的公司生产环境数据库，通常会是8核16G。那么一个8核16G的数据库每秒能承受多大的并发压力呢？一般来说，是几千的数量级。因为它能抵抗多少并发取决于你数据库的数据量和你SQL语句的复杂程度，所以一般来说8核16G的机器每秒能抵抗几千个并发。不管量有多大，基本是承受不了的，因为往往在这个级别，数据库的CPU、内存、网络、IO负载基本上都很高，尤其是CPU，可能至少70%或者80%。.如下图所示：数据库架构可以优化哪些方面？根据业务系统拆分多个数据库机优化方案那么继续下去，如果你在这种并发压力下，你通常如何优化数据库架构？其实很简单，我们可以添加机器，将数据库部署到多台机器上。因为一般来说我们的一个数据库里面会包含很多业务系统的dbs和tables，所以首先可以按照业务系统进行拆分。比如多加一台机器，然后部署一个数据库，然后把一部分业务系统的db和表放在这里，另一部分业务系统的db和表放在旧的数据库机器上。这时候老数据库机器的压力一下子就可以缓解了。如下图所示：读写分离架构优化方案那么下一个问题来了，如果并发压力持续增加，导致两个分离的数据库压力越来越大？这时候，我们可以使用一个叫做读写分离的trick。也就是为每个数据库挂一个从库，让主库根据binlog数据更新日志同步复制到从库，这样主从库就可以保持数据的一致性。那么我们的系统就可以真正的写入主库，从从库进行查询了。这时候就可以缓解原来master数据库的压力了。如下图：分库分表架构优化方案再说下去，如果即使从库挂主库，然后并发压力不断增加，写压力我们的主库太高了，每秒几千条写，这种情况下，只能走最终的解决方案，就是分库分表，也就是把主库拆分成多个数据库，把一部分数据放到每个数据库一个表，然后用多个主库来抵抗高并发写压力，这样我们的压力又可以分散了。如下图所示：总结一下，今天分享的知识到此结束。其实我们数据库架构的演进，基本上就是按照今天说的顺序和思路在逐步演进。一开始，如果你的单台数据库机无法处理上千并发，你可以根据业务系统拆分多台数据库机。那么，如果实在扛不住了，主从架构来分担读写压力。实在扛不住了，可以分库分表，多机抗数据库写压力，最终数据库架构总能抗高并发压力。
