怎么理解Spring非阻塞编程模式

本篇内容介绍了“怎么理解Spring非阻塞编程模式”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

测试方法

本文中，我们尝试了如下四种组合：

• Spring Web MVC + JDBC 数据库驱动

• Spring Web MVC + R2DBC 数据库驱动

• Spring WebFlux + JDBC 数据库驱动

• Spring WebFlux + R2DBC 数据库驱动

我已经将并行请求数以50个为单位从4增加到500，分别为负载生成器和服务分配4个核心(我的笔记本有12个核心)。我将所有的连接池都配置为100。为什么要固定核数和连接池的大小?因为在之前对JDBC和R2DBC的测试中，改变这些因素并没有提供更多的数据，所以我决定在这个测试中保持固定的变量，以减少测试需要运行的时间。

我在服务上模拟一个GET请求。该服务从数据库中获取了10条记录，并以JSON形式返回。首先，我对服务进行了2秒预热。接下来，我开始了1分钟的基准测试。我把每个场景运行5次(依次运行，而非5次之后再运行其他测试)，并计算结果的平均值。我只统计了那些没有错误的测试。当我将并发数增加到1000以上时，所有的实现都无一例外地有失败。

我使用了Postgres(12.2)作为数据库。并且使用wrk来进行基准测试。我用下面的方法解析wrk的输出。主要测量：

• 响应时间—来自Wrk测试报告

• 吞吐量(请求数)— 来自Wrk测试报告

• 进程CPU的使用情况—用户和内核时间(基于/proc/PID/Stat)

• 内存使用量—私有和共享进程内存(基于/proc/PID/maps)

你可以在这里查看所使用的测试脚本[1]。你可以在这里查看所使用的代码[2]。

测试结果

你可以在这里查看我在图表中使用的原始数据[3]。

响应时间

很显然在高并发下，Spring Web MVC + JDBC可能不是你的最佳选择。显然在更高的并发下，R2DBC可以提供更好的响应时间。Spring  Web MVC和Spring WebFlux也有类似的趋势。

吞吐量

与响应时间类似，使用JDBC+Spring Web  MVC在高并发下表现得更差。同样的，R2DBC显然表现的更胜一筹。如果你的后端仍然使用JDBC，那么从Spring Web MVC转移到Spring  WebFlux也并不是一个好主意。在低并发时，Spring Web MVC + JDBC 表现最好。

CPU

CPU是指整个运行过程中的CPU时间，即进程用户和内核时间之和。

使用JDBC+Web  MVC的方案在高并发时消耗的CPU最高。JDBC+WebFlux的方案使用的CPU时间最少，但吞吐量也最低。当你查看平均每请求所使用的CPU时，你就可以衡量各种方式的CPU使用效率。

与JDBC相比，R2DBC平均每个请求使用的CPU更少。使用JDBC+WebFlux似乎不是一个好主意。JDBC+Web  MVC在高并发量的情况下更加糟糕，而其他至少有一个非阻塞组件的实现更稳定。然而在低并发时，Web MVC + JDBC可以最有效地利用CPU。

内存

我们测量在运行结束时进程私有内存作为内存消耗量。内存使用情况取决于垃圾回收。我们使用JDK 11.0.6和G1GC。Xms 设置为 0.5 Gb  (默认是我可用内存32 Gb 的 1/64)。Xmx 设置为 8 Gb (默认是我可用内存 32 Gb 的 1/4)。

与Web  MVC相比，WebFlux的内存使用量似乎更稳定，而WebMVC在高并发时的内存使用量更大。当使用WebFlux+R2DBC时，在高并发情况下，内存使用量最少。在低并发时，Web  MVC + JDBC内存使用较低，但在高并发时，WebFlux + R2DB平均每个请求处理中使用的内存最少。

Fat Jar大小

下图中JPA占用了大头。如果你使用R2DBC的情况下不使用它，那么Fat JAR大小就会下降到15Mb左右!

• JDBC的继任者。

“怎么理解Spring非阻塞编程模式”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站，小编将为大家输出更多高质量的实用文章！