1. 当解数据库的架构原理之后，就该了解一下数据库的规划

有一定并发量的互联网类的系统，对数据库可能会产生每秒几百，每秒几千，甚至每秒上万的并发请求量，对于这类场景下，我们应该选择什么样的机器去部署数据库，才能比较好的抗下我们的系统压力呢?

2. 题外话:普通的Java应用系统部署在机器上能扛多少并发？

• 根据经验而言，Java应用系统部署的时候常选用的机器配置大致是2C4G和4C8G的较多一些，数据库部署的时候常选用的机器配置最低在8C16G以上，正常在16C32G.

• 以大量的高并发线上系统的生产经验观察下来而言，一般Java应用系统部署在4C8G的机器上，每秒钟扛下500左右的并发访问量，差不多是比较合适的，当然这个也不一定。因为你得考虑一下，假设你每个请求花费1s可以处理完，那么你一台机器每秒也许只可以处理100个请求，但是如果你每个请求只要花费100ms就可以处理完，那么你一台机器每秒也许就可以处理几百个请求。

• 一台机器能抗下每秒多少请求，往往是跟你每个请求处理耗费多长时间是关联的，但是大体上来说，根据大量的经验观察而言，4C8G的机器部署普通的Java应用系统，每秒大致就是抗下几百的并发访问，从每秒一两百请求到每秒七八百请求，都是有可能的，关键是看你每个请求处理需要耗费多长时间。

3. 高并发场景下，数据库应该用什么样的机器？

数据库而言，通常推荐的数据库至少是选用8C16G以的机器，甚至是16C32G的机器更加合适一些。

• 对于Java应用系统，主要耗费时间的是: Java系统和数据库之间的网络通信。

• 对Java系统自己而言，如果仅仅只是系统内部运行一些普通的业务逻辑，纯粹在自己内存中完成一些业务逻辑，这个性能是极高极高的。

• 对于Java系统接收到的每个请求，耗时最多的还是: 发送网络请求到数据库，等待数据库执行一些SQL语句，返回结果的这个过程。

• 一般而言, 通常来说, 有一个Java系统压力很大，负载很高!! 主要的原因大概率都是因为这个Java系统依赖的MySQL数据库的压力大、数据库负载高、或者执行的SQL缓慢、间接导致了Java系统的一系列的副作用。因为执行大量的增删改查的SQL语句的时候，MySQL数据库需要对内存和磁盘文件进行大量的IO操作，所以数据库往往是负载最高的！这个问题在这里《04 基于更新语句,在InnoDB存储引擎中的执行流程，聊聊binlog是什么？》，通过MySQL数据库架构原理的分析，都已经讲解过了。而Java系统一般直接大量的读写本地文件进行耗时的IO操作的情况通常来说不多,所以往往对一个数据库而言，都是选用8C16G的机器作为起步，最好是选用16C32G的机器更加合适一些，因为数据库需要执行大量的磁盘IO操作，他的每个请求都比较耗时一些，所以机器的配置自然需要高一些了。

• 通过以往经验而言，一般8C16G的机器部署的MySQL数据库，每秒扛个一两千并发请求是没问题的，但是如果并发量再高一些，假设每秒有几千并发请求，那么可能数据库就会有点危险了，因为数据库的CPU、磁盘、IO、内存的负载都会很高，弄不数据库压力过大就会宕机。

• 对于16C32G的机器部署的MySQL数据库而言，每秒扛个两三千，甚至三四千的并发请求也都是可以的，但是如果你达到每秒上万请求，那么数据库的CPU、磁盘、IO、内存的负载瞬间都会飙升到很高，数据库也是可能会扛不住宕机的。

这就是对于数据库，一般推荐选用的机器的配置，以及他大致可以抗下多高的并发请求量的经验分享。

另外对于数据库而言，如果可以的话，最好是采用SSD固态硬盘而不是普通的机械硬盘，因为数据库最大的复杂就在于大量的磁盘IO，他需要大量的读写磁盘文件，所以如果能使用SSD固态硬盘，那么你的数据库每秒能抗的并发请求量就会更高一些。

4. 🙋‍♂️🙋‍♂️🙋‍♂️思考题

假设一个Java系统部署在一台4C8G的机器上，假设这个Java系统处理一个请求非常非常快，每个请求只需要0.01ms就可以处理完了，那这一台机器部署的Java系统，可以实现每秒扛下几千并发请求吗？可以实现每秒扛下几万并发请求吗？

在一台4核8G的机器上部署 Java 系统时，能够扛下的并发请求数，要考虑以下几个因素：

1. 每个请求的处理时间。

2. 机器的核心数量。

3. 系统的并行处理能力。

假设每个请求需要0.01毫秒（ms）来处理，那么我们可以计算出每秒能够处理的请求数。

计算每秒处理的请求数

首先，将请求处理时间从毫秒转换为秒：

0.01 ms=0.01÷1000 s=0.00001 s

然后，计算每秒能够处理的请求数：

每秒处理的请求数=1s/(0.00001 s/请求)=100,000 请求/秒

考虑多核处理器

由于机器有4个核心，理论上每个核心可以独立处理请求，因此总的处理能力是单核的4倍：

总处理能力=100,000 请求/秒×4=400,000 请求/秒

实际情况中的并发处理能力

在实际情况下，由于操作系统调度、上下文切换、网络延迟等因素，实际的并发处理能力可能会低于理论最大值。通常，实际应用中能达到理论最大值的70%-80%左右。因此，我们可以估算实际的并发处理能力在：

400,000×0.7=280,000 请求/秒 到 400,000×0.8=320,000 请求/秒 之间

还要考虑以下几个因素：

1. CPU 使用率：

• 如果每个请求的处理时间只有 0.01 毫秒，理论上每个请求的 CPU 占用非常小，但因为是并发处理，CPU 资源会被多线程争用。假设请求能够完全并行处理，4 核 CPU 会有一定的并发处理能力，但超负荷运行的风险仍然存在。

2. 内存限制：

• 系统的内存是 8GB，这会限制你可以同时处理的并发请求数量，尤其是请求需要分配内存（比如请求中可能有大量的数据处理）。如果请求过多，内存不足可能导致 JVM GC 频繁触发，进而影响系统性能。

3. 线程上下文切换：

• 即使每个请求的处理时间非常短，Java 系统仍然需要为每个并发请求创建线程。线程上下文切换会带来一定的性能损耗，尤其是在请求数量过多时，CPU 会浪费时间在线程切换上，降低了整体的吞吐量。

4. I/O 性能：

• 如果请求涉及数据库、文件系统或网络 I/O，那么 I/O 性能成为瓶颈，而不仅仅是 CPU 处理能力。例如，数据库查询、网络请求等会导致系统等待时间，这时即使 CPU 处理请求很快，整体性能也会受限。

5. JVM 和垃圾回收：

• JVM 的垃圾回收机制（GC）也会影响系统的吞吐量。如果请求的生命周期比较长，频繁的 GC 会导致暂停，影响系统响应能力。

结论:

理论上，基于请求处理速度和机器配置，处理每秒几千请求甚至几万请求是有可能的，但在实际生产环境中，需要关注并发数过高时带来的资源瓶颈，比如 CPU、内存、网络 I/O 等，可能会影响实际的并发性能。根据上述计算，这台4C8G的机器部署的Java系统可以实现每秒扛下大约28万到32万的并发请求。因此，答案是可以实现每秒扛下几十万并发请求。

• 每秒几千并发请求： 理论上完全可以达到，甚至一台 4 C 8G 的机器在处理每个请求 0.01 毫秒的情况下，能够轻松应对每秒几千个并发请求，甚至几万。

• 每秒几万并发请求： 如果请求的处理只是计算密集型的（即不涉及大量的 I/O 操作），并且系统设计合理，仍然有可能达到几万并发请求的水平。然而，如果请求涉及到 I/O 操作或复杂的逻辑计算，可能会受到资源瓶颈的限制。