今天给大家分享一个知识点，是关于MySQL数据库架构演进的，因为很多兄弟天天基于mysql做系统开发，但是写的系统都是那种低并发压力、小数据量的，所以哪怕上线了也就是这么正常跑着而已，但是你知道你连接的这个MySQL数据库他到底能抗多大并发压力吗？如果MySQL数据库扛不住压力了，应该如何演进你知道吗？
一般业务系统运行流程图
首先，我们先来看一个最最基础的java业务系统连接数据库运行的架构，其实简单来说，我们平时都是用spring boot+ssm技术栈开发一个java业务系统的，用spring boot内嵌tomcat就可以对外提供http接口了，然后最多现在会加上nacos+dubbo调用别的系统接口，数据全部靠连接mysql数据库进行crud就可以了，如下图。
上面那种架构的系统，估计就是很多兄弟日常做的最多的系统架构了，有的兄弟稍微做的高大上一点，大概来说，可能就是会加入一些es、redis、rocketmq一类的中间件简单使用一下，但是大致来说也就这么回事了，那么还是回归主题，大家知道你上述那种系统下，他连接的数据库能抗多大压力吗？
一台4核8G的机器能扛多少并发量呢？
说实话，要解决这个问题，一般来说，不是先聊数据能抗多少压力，因为往往不是数据库先去抗高并发，而是你连接数据库的web系统得先去抗高并发！也就是我们的spring boot+ssm那套业务系统能抗多高并发我们得先搞清楚！
所以要搞明白这个问题，就得先说一个主题，一般来说我们的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、分库分表架构优化方案
再往下说，如果说即使是给主数据库挂了从库，然后接着并发压力继续提升，让我们的主数据库写入压力过大，每秒几千写入，又要扛不住了呢？此时就只能上终极方案，分库分表了，就是把主库拆分为多个库，每个库里放一个表的部分数据，然后用多个主库抗高并发写入压力，这样就可以再次分散我们的压力了，如下图所示。
总结优化
好了，今天分享的知识就到这里了，其实我们的数据库架构演进基本上就是按照今天说的这个顺序和思路逐步逐步的演进的，刚开始你单台数据库机器抗几千并发扛不住了，就按照业务系统拆分多个数据库机器，然后再扛不住了，就上主从架构分摊读写压力，再扛不住了就分库分表，多个机器抗数据库写入压力，最后总是可以用数据库架构抗住高并发压力的。
真实环境问题
30万用户的web系统，单台mysql服务器可以扛住吗？
最近看了很多高可用，集群的方案，越看越头疼。看后的感觉就是，维护成本太大，对于我这种没这方面经验的新手，实在头大。
实在不想弄那种集群，高可用的方案，什么分表，分库，水平拆分，垂直拆分，什么mycat啥的，统统都不想弄。我技术水平驾驭不住！
服务器，32g-ddr3内存，ssd-240g硬盘，cpu-xeon系列！
单mysql服务器，实在好控制，不用操心，不在自己技术范围外的异常情况！
例如redis，我没经验，写到是能写出来，照葫芦画瓢，但是他有数据不一致的问题，需要额外处理，这个没经验，感觉还是驾驭不了。
主要是没时间，去试错。
平均每天5万条数据左右写入，剩下的基本都是读！
qps是什么？
QPS(Query Per Second)意思为“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
一，分析
一般应用来说，并发估算公式如下：
qps = 5 * 日pv / 86400
5是通用峰值倍数，如果你有高峰值特性自行调整，比如秒杀功能。
mysql通常在实体机的读写综合qps在几千左右，具体你可以自己压测一下，跟机器配置有关。
所以首先你需要通过收集日志得到日pv，然后通过估算得到当前qps，再根据未来一段时间的用户量和场景看看够不够。
比如你每天数据库访问次数是100万，可估算峰值qps为60左右，比如数据库qps可达3000，那么可估算你的服务器还能撑同等场景50倍增长。
以上方法都是通用方法，杠精退散。
脱离具体方法来说，题主这种小型站点，我的建议是不要听某些人说的用什么牛逼方案，用最成熟的通用方案就对了，有问题方便解决，以后也便于别人接盘。
切忌过度优化，互联网老兵给你的成熟建议。
根据全日的qps计算，该用户一天大概只能5万的写入量，如果是平均的话每两秒只有一次写入，qps只有0.5左右，当前服务器绰绰有余的就可以接盘，如果是在同一个时间段有上万数据同时涌入的话，数据库会到达一个瓶颈，有可能会出现崩溃的情况，但是如果这么高的并发的话，大可能是前面web端的服务器先支撑不住。
二，qps计算
业务qps的估算一般按照场景来划分，阐述下常见场景的估算方法：
1、抢购和活动场景
按照80%的访问量集中在20%的时间内
qps=pv*80%/86400*20%
2、白天提供业务的场景（例如政务查询系统等）
按照一半时间去计算4w秒
qps=pv/40000
3、全天后无明显波峰场景
qps=pv/86400
至于mysql的性能直接测试一下，不同机器配置差异太大，一般qps几k没有问题
附带建议：不要只一台服务，怎么也搞个主从，只为少些晚上被叫起来搞事情
三，总结
1、通常情况下，线上环境应用部署在4核8G的机器上，而数据库应部署在8核16G或者16核32G，正常情况下单节点应用服务可支撑500左右的并发，当然还要根据请求的处理时长来计算，比如接口请求响应过慢就会导致并发降低
2、在一个系统中，往往压力会集中在数据库上，因为请求一般最终会落到数据库上，而数据库需要在内存以及磁盘上进行大量的IO操作。一般来说8核16G的机器部署mysql数据库可以扛住一两千的并发，如果并发量再高些比如几千，就会造成数据库CPU、磁盘、IO、内存等负载过高，严重会引起宕机
3、16核32G的机器，一般可以扛住两三千的并发、甚至到三四千也都可以，具体还是有要看sql的复杂度等，对于数据库而已，一般采用的SSD固态硬盘，因为数据操作需要大量的磁盘IO，SSD的IO会相对大很多。
参考文章
