目录
1、普通的Java应用系统部署在机器上能抗多少并发？
配置经验值：
- Java应用系统部署的时候常选用的机器配置大致是2核4G和4核8G的较多一些
- 数据库部署的时候常选用的机器配置最低在8核16G以上，正常在16核32G。
高并发线上经验值：
- 一般Java应用系统部署在4核8G的机器上，每秒钟抗下500左右的并发访问量，差不多是比较合适的，当然这个也不一定。 一台机器能抗下每秒多少请求，往往是跟你每个请求处理耗费多长时间是关联的。大体上来说，根据我们大量的经验观察而言，4核8G的机器部署普通的Java应用系统，每秒大致就是抗下几百的并发访问，从每秒一两百请求到每秒七八百请求，都是有可能的，关键是看你每个请求处理需要耗费多长时间。
- 一般8核16G的机器部署的MySQL数据库，每秒抗个一两千并发请求是没问题的，但是如果你的并发量再高一些，假设每秒有几千并发请求，那么可能数据库就会有点危险了，因为数据库的CPU、磁盘、IO、内存的负载都会很高，弄不数据库压力过大就会宕机。
- 对于16核32G的机器部署的MySQL数据库，每秒抗个两三千，甚至三四千的并发请求也都是可以的，但是如果你达到每秒上万请求，那么数据库的CPU、磁盘、IO、内存的负载瞬间都会飙升到很高，数据库也是可能会扛不住宕机的。
Java应用耗时：
Java应用系统，主要耗费时间的是Java系统和数据库之间的网络通信。
对于你Java系统接收到的每个请求，
耗时最多的还是发送网络请求到数据库上去，等待数据库执行一些SQL语句，返回结果
给你。
常说你有一个Java系统压力很大，负载很高，但是其实你要明白一点，你这个Java系统其实主要的
压力和复杂都是集中在你依赖的那个MySQL数据库上的
！因为你执行大量的增删改查的SQL语句的时候，MySQL数据库需要对内存和磁盘文件进行大量的IO操作，所以数据库往往是
负载最高的！
2、数据库第一步 ---- 压测
2.1、压测
就是 基于一些工具模拟一个系统每秒发出1000个请求到数据库上去，观察一下他的CPU负载、磁盘IO负载、网络IO负载、内存负载，然后数据库能否每秒处理掉这1000个请求，还是每秒只能处理500个请求？
2.2、压测相关指标
（1）QPS与TPS
QPS就是说，你的这个数据库每秒可以处理多少个请求，你大致可以理解为，一次请求就是一条SQL语句，也就是说这个数据库每秒可以处理多少个SQL语句。对于QPS而言，其实你的一些Java系统或者中间件系统在进行压测的时候，也可以使用这个指标，也就是说，你的Java系统每秒可以处理多少个请求。
TPS，他的英文全称是：Transaction Per Second。其实就是
每秒可处理的事务量
，这个TPS往往是用在数据库中较多一些，其实从字面意思就能看的出来，他就是说数据库每秒会处理多少次事务提交或者回滚。
一个事务就会包含多个SQL语句，这些SQL最好要么就是事务提交，大家一起成功了，要么就是最好事务回滚，大家一起失败了，这就是事务。 所以
TPS往往指的是一个数据库每秒里有多少个事务执行完毕了，事务提交或者回滚都算是事务执行完毕了，所以TPS衡量的是一个数据库每秒处理完的事务的数量。
（2）IOPS：
这个指的是
机器的随机IO并发处理的能力
，比如机器可以达到200 IOPS，意思就是说
每秒可以执行200个随机IO读写请求
。 你在内存中更新的脏数据库，最后都会由后台IO线程在不确 定的时间，刷回到磁盘里去，这就是随机IO的过程。如果说IOPS指标太低了，那么会导致你内存里的脏数据刷回磁盘的效率 就会不高。
（3）吞吐量：
这个指的是机器的
磁盘存储每秒可以读写字节的数据量。
我们平时在执行各种SQL语句的时候，提交事务的时候，其实都是大量的会写redo log之类的日志的，这些日志都会直接写磁盘文件。所以一台机器他的存储每秒可以读写多少字节的数据量，就决定了他每秒可以把多少redo log之类的日志写入到磁盘里去。
一般来说我们写redo log之类的日志，都是对磁盘文件进行顺序写入的，也就是一行接着一行的写，不会说进行随机的读写。
一般普通磁盘的顺序写入的吞吐量每秒都可以达到200MB左右。
所以
通常而言，机器的磁盘吞吐量都是足够承载高并发请求的。
（4）latency：
这个指标说的是
往磁盘里写入一条数据的延迟
。
因为我们执行SQL语句和提交事务的时候，都需要顺序写redo log磁盘文件，所以此时你写一条日志到磁盘文件里去，到底是延迟1ms，还是延迟100us，这就对你的数据库的SQL语句执行性能是有影响的。
一般来说，当然是你的磁盘读写延迟越低，那么你的数据库性能就越高，你执行每个SQL语句和事务的时候速度就会越快。
（5）CPU负载：
CPU负载是一个很重要的性能指标，因为假设你数据库压测到了每秒处理3000请求了，可能其他的性能指标都还正常，但是此时CPU负载特别高，那么也说明你的数据库不能继续往下压测更高的QPS了，否则CPU是吃不消的。
（6）网络负载：
这个主要是要看看你的机器带宽情况下，在压测到一定的QPS和TPS的时候，
每秒钟机器的网卡会输入多少 MB数据，会输出多少MB数据
，因为有可能你的网络带宽最多每秒传输100MB的数据，那么可能你的QPS到1000的时候，网卡就打满了，已经每秒传输100MB的数据了，此时即使其他指标都还算正常，但是你也不能继续压测下去了。
（7）内存负载：
这个就是看看在压测到一定情况下的时候，你的机
器内存耗费了多少
，如果说机器内存耗费过高了，说明也不能继续压测下去了。
2.3、压测工具
一个非常好用的数据库压测工具，就是sysbench
，这个工具可以自动帮你在数据库里构造出来大量的数据，你想要多少数据，他就自动给你构造出来多少条数据。 然后这个工具接着可以模拟几千个线程并发的访问你的数据库，模拟使用各种各样的SQL语句来访问你的数据库，包括模拟出来各种事务提交到你的数据库里去，甚至可以模拟出几十万的TPS去压测你的数据库。
2.4、观察机器CPU负载情况？
监测linux机器性能的命令，就是top命令，直接在linux命令行只能够输入top指令
top - 15:52:00 up 42:35, 1 user, load average: 0.15, 0.05, 0.01
- 15:52:00指的是当前时间
- up 42:35指的是机器已经运行了多长时间
- 1 user就是说当前机器有1个用户在使用
- load average: 0.15, 0.05, 0.01是CPU在1分钟、5分钟、15分钟内的负载情况。
CPU负载是什么意思？
假设我们是一个4核的CPU，此时如果你的CPU负载是0.15，这就说明，4核CPU中连一个核都没用满，4核CPU基本都很空闲，没啥人在用。
如果你的CPU负载是1，那说明4核CPU中有一个核已经被使用的比较繁忙了，另外3个核还是比较空闲一些。
要是CPU负载是1.5，说明有一个核被使用繁忙，另外一个核也在使用，但是没那么繁忙，还有2个核可能还是空闲的。
如果你的CPU负载是4，那说明4核CPU都被跑满了
如果你的CPU负载是6，那说明4核CPU被繁忙的使用还不够处理当前的任务，很多进程可能一直在等待CPU去执行自己的任务。
上面看到的load average实际上就是CPU在最近1分钟，5分钟，15分钟内的平均负载数值，上面都是0.15之类的，说明CPU根本就没怎么用。
但是如果你在压测的过程中，发现4核CPU的load average已经基本达到3.5，4了，那么说明几个CPU基本都跑满了，在满负荷运转，那么此时你就不要再继续提高线程的数量和增加数据库的QPS了，否则CPU负载太高是不合理的。
2.5、观察机器内存负载情况？
监测linux机器性能的命令，就是top命令，直接在linux命令行只能够输入top指令
Mem: 33554432k total, 20971520k used, 12268339 free, 307200k buffers
- 总内存大概有32GB
- 已经使用了20GB左右的内存
- 还有10多G的内存是空闲的
- 然后有大概300MB左右的内存用作OS内核的缓冲区了
一般来说，如果内存的使用率在80%以内，基本都还能接受，在正常范围内，但是如果你的机器的内存使用率到了70%~80%了，就说明有点危险了
，此时就不要继续增加压测的线程数量和QPS了，差不多就可以了。
2.6、观察机器的磁盘IO情况？
使用dstat命令，包括存储的IO吞吐量、IOPS这些
使用dstat -d命令，会看到如下的东西：
-dsk/total -read writ103k 211k0 11k
存储的IO吞吐量是每秒钟读取103kb的数据，每秒写入211kb的数据，像这个存储IO吞吐量基本上都不 算多的，因为
普通的机械硬盘都可以做到每秒钟上百MB的读写数据量
。
dstat -r，可以看到如下的信息--io/total
read writ0.25 31.90 2530 39.0
读IOPS和写IOPS分别是多少，也就是说随机磁盘读取每秒钟多少次，随机磁盘写入每秒钟执行多少次。
一般来说，随机磁盘读写每秒在两三百次都是可以承受的。
所以在这里，我们就需要在压测的时候密切观察机器的磁盘IO情况，如果磁盘IO吞吐量已经太高了，都达到极限的每秒上百MB了，或者随机磁盘读写每秒都到极限的两三百次了，此时就不要继续增加线程数量了，否则磁盘IO负载就太高了。
Version:0.9 StartHTML:0000000105 EndHTML:0000001951 StartFragment:0000000141 EndFragment:0000001911
2.7、观察网卡的流量情况
接着我们可以使用dstat -n命令，可以看到如下的信息：
-net/totalrecv send16k 17k
每秒钟网卡接收到流量有多少kb，每秒钟通过网卡发送出去的流量有多少kb。
通常来说，如果你的机器使用的是
千兆网卡，那么每秒钟网卡的总流量也就在100MB左右
，甚至更低一些。
所以我们在压测的时候也得观察好网卡的流量情况，如果网卡传输流量已经到了极限值了，那么此时你再怎么提高sysbench 线程数量，数据库的QPS也上不去了，因为这台机器每秒钟无法通过网卡传输更多的数据了。
总结
在硬件的一定合理的负载范围内，把数据库的QPS提高到最大，这就是数据库压测的时候最合理的一个极限QPS值。
3、数据库第二步 ---- 设置监控出报表
要做到心里有数，一台什么样配置的机器，部署了一个数据库之后，利用sysbench构造了多少个表和数据量，然后模拟了多少个线程压测的时候，机器的各项硬件负载在可以接受的范围内时，数据库的QPS和TPS可以压测到多高。
这个时候你大致就明白你的数据库在高峰时期最多可以让他去承受多少QPS和TPS了。
不光是对你开发的Java系统进行监控，还得对你的数据库进行监控，包括对CPU、内存、网络、磁盘IO、慢查询、QPS、TPS的监控。
搭建一下生产环境数据库的可视化监控平台，我们会基于Prometheus+Grafana来搭建。
609
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
