为Java多线程应用程序优化数据存储库

需要从数据库中检索数据的Java应用程序，如REST微服务或异步消息处理器，通常以多线程应用程序(*1)实现，其中：

• 每个线程在其执行的某个时刻执行相同的查询(每个查询具有不同的参数)。
• 并发线程数很高(每秒数十或数百)。

在这种场景下，数据库很可能在较短的时间间隔内多次执行相同的查询。

如前所述，如果将1个参数的n个查询替换为具有n个参数的单个等效查询，那么则应用程序将使用较少的数据库服务器和网络资源。

好消息是它可以通过timewindows(时间窗口)的机制来实现，如下所示：

第一个尝试执行查询的线程会打开一个时间窗口，因此其参数被存储在一个列表中，同时该线程被暂停。在时间窗口内执行相同查询的其余线程会将其参数添加到列表中，并且也会被暂停。此时，数据库上未执行任何查询。

时间窗口结束或列表已满(先前已定义最大容量限制)后，将使用列表中存储的所有参数执行单个查询。最后，一旦数据库提供了该查询的结果，每个线程将接收相应的结果，同时所有线程将自动恢复。

笔者构建了一个简单而轻量级的应用机制(DelayedBatchExecutor)，很容易在新的或现有的应用程序中使用。它基于Reactor库，并且为参数列表使用超时的Flux缓冲发布器。

运用DelayedBatchExecutor的吞吐量和延迟分析

假设针对Products的REST微服务公开了一个端点，用于检索数据库中给定的 productId的Product数据。在没有DelayedBatchExecutor的情况下，如果每秒对端点命中200次，则数据库每秒执行200个查询。如果端点使用的DelayedBatchExecutor 配置了50毫秒的时间窗口且最大容量=10个参数，数据库每秒钟将只执行10个参数的20个查询，代价是每执行一个线程，最多在50毫秒内增加延时(*2)。

换句话说，为了将延时增加50毫秒(* 2)，数据库每秒接收的查询减少了10倍，然而保持了系统的整体吞吐量。还不错!!

其他有趣的配置：

• 窗口时间= 100毫秒，最大容量= 20个参数→20个参数的10个查询(查询减少20倍)
• 窗口时间= 500毫秒，最大容量= 100个参数→2个查询100个参数(查询减少100倍)

执行中的DelayedBatchExecutor

深入研究Product微服务示例。假设对于每个传入的HTTP请求，微服务的控制器都要求检索已有id的Product(Java Bean)，因此将调用以下方法：

（编辑：鞍山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!