content
- General business system operation flow chart
- How much concurrency can a 4-core 8G machine resist?
- Will the database be killed first when high concurrency hits?
- How much concurrency pressure can an 8-core 16G database resist per second?
- How can the database schema be optimized?
- Summarize
Today I will share with you a knowledge point about the evolution of MySQL database architecture, because many brothers do system development based on MySQL every day, but the systems they write are all of the kind with low concurrency pressure and small amount of data, so even if they go online, that’s it. It just runs normally, but do you know how much concurrency pressure the MySQL database you are connecting to can withstand? If the MySQL database can't handle the pressure, how should it evolve? Do you know?
General business system operation flow chart
First of all, let's first look at the most basic java business system to connect to the database operation architecture. In fact, to put it simply, we usually use the spring boot+ssm technology stack to develop a java business system, and use spring boot to embed tomcat. The http interface can be provided externally, and then at most, nacos+dubbo will be added to call other system interfaces. All data can be crud by connecting to the mysql database, as shown in the following figure.
The system with the above architecture is estimated to be the system architecture that many brothers do the most on a daily basis. Some brothers do a little bit taller. Generally speaking, it may be simple to add some middleware such as es, redis, and rocketmq. Let's use it, but that's basically the same thing, so let's go back to the topic. Do you know how much pressure the database he connects to can withstand under the system you mentioned above?
How much concurrency can a 4-core 8G machine carry?
To be honest, to solve this problem, generally speaking, it is not necessary to talk about how much pressure the data can withstand first, because often it is not the database that resists high concurrency first, but the web system you connect to the database must resist high concurrency first! That is, we have to figure out how high concurrency our spring boot+ssm business system can resist!
所以要搞明白这个问题，就得先说一个主题，一般来说我们的spring boot应用系统大致就是部署在2核4G或者4核8G的机器上，这个机器配置其实是很关键的，所以这里直接告诉大家一个经验值，即使说咱们如果部署的是一个4核8G的机器，然后spring boot内嵌的tomcat默认开了200个线程来处理请求，接着每个请求都要读写多次数据库，那么此时，大致来说你的一台机器可以抗大概500~1000这个并发量，具体多少得看你的接口复杂度，如下图。
高并发来袭时数据库会先被打死吗？
所以其实一般来说，当你的高并发压力来袭的时候，通常不会是数据库先扛不住了，而是你的业务系统所在机器抗不住了，比如你部署了2台机器，那么其实到每秒一两千并发的时候，这两台机器基本上cpu负载都得飙升到90%以上 ，压力很大，而且接口性能会开始往下掉很多了，如下图。
那么这个时候我们的数据库压力会如何呢？其实一般来说你的两台机器抗下每秒一两千的请求的时候后，数据库压力通常也会到一个小瓶颈，因为为什么呢？关键是你的业务系统处理每个业务请求的时候，他是会读写多次数据库的，所以业务系统的一次请求可能会导致数据库有多次请求，也正因为这样，所以此时可能你的数据库并发压力会到几千的样子。
8核16G的数据库每秒大概可以抗多少并发压力？
那么所以下一个问题来了，你的数据库通常是部署在什么样配置的机器上？一般来说给大家说，数据库的配置如果是那种特别低并发的场景，其实2核4G或者4核8G也是够了，但是如果是常规化一点的公司的生产环境数据库，通常会是8核16G。那么8核16G的数据库每秒大概可以抗多少并发压力？大体上来说，在几千这个数量级。
因为这个具体能抗多少并发也得看你数据库里的数据量 以及你的SQL语句的复杂度，所以一般来说8核16G的机器，大概也就是抗到每秒几千并发就差不多了，量再大基本就扛不住了，因为往往到这个量级下，数据库的cpu、内存、网络、io的负载基本都很高了，尤其是cpu，可能至少也在百分之七八十了，如下图。
数据库架构可以从哪些方面优化？
1.根据业务系统拆分多个数据库机器优化方案
那么接着说，如果到了这个并发压力之下，通常来说可以如何进行**数据库架构的优化呢？**其实也简单，我们完全可以加机器，把数据库部署到多台机器上去。因为通常来说，我们的一个数据库里会放很多业务系统的db和tables，所以首先就是可以按照业务系统来进行拆分，比如说多加一台机器，再部署一个数据库，然后这里放一部分业务系统的db和tables，老数据库机器放另外一部分业务系统的db和tables，此时一下子就可以缓解老数据库机器的压力了，如下图。
2. 读写分离架构优化方案
那么接着问题来了，如果说并发压力继续提升，导致拆分出去的两台数据库压力越来越大了呢？此时可以上一招，叫做读写分离，就是说给每个数据库挂一个从库，让主数据库基于binlog数据更新日志同步复制给从数据库，让主从数据库保持数据一致，然后我们的系统其实可以往主库里写入，在从库里查询，此时就又可以缓解原来的主数据库的压力了，如下图。
3. Sub-database sub-table structure optimization scheme
Going further, what if even if the main database is linked to the slave library, and then the concurrency pressure continues to increase, the write pressure of our main database is too large, and it can’t handle thousands of writes per second? At this time, we can only use the ultimate solution, sub-database and sub-table , which is to split the main database into multiple databases, put some data of a table in each database, and then use multiple main databases to resist high concurrent write pressure. This will spread our stress again, as shown in the image below.
Summarize
Well, the knowledge shared today is here. In fact, the evolution of our database architecture is basically a gradual evolution according to the order and ideas mentioned today. At the beginning, your single database machine cannot withstand thousands of concurrency. , just split multiple database machines according to the business system , and then if it can't bear it, the master-slave architecture will share the read and write pressure, and if it can't bear it again, it will split the database and the table , multiple machines resist the database write pressure, and finally It is always possible to withstand high concurrency pressure with database architecture.
END
Scan the code to get 600+ pages of Shishan's original excellent articles summary PDF for free
Summary of original technical articles