Spring集成线程限制

Question

我们有一个 SI 应用程序，用于路由消息、进行一些验证、转换和过滤。

本质上，它使用来自各种队列的 JMS 消息并将它们路由到预先注册的下游出站 JMS 队列。

我们通过 spring 配置管理所有这些。

在 1 个 JVM 中，我们有数百个（400-500）个队列通道和相关的轮询器。

我们注意到，随着我们扩大规模（添加新的入站 + 出站路由），我们的性能有所下降。

我们似乎没有对盒子产生影响（CPU、内存等），所有这些似乎都没有得到充分利用。

当分析应用程序看起来像这样，

• ~650 线程总数可运行
• 0-2 Blocked 0（有时会飙升到 10 左右，似乎找不到他们的阻塞点）
• 在 Net I/O ~100+（通常等待 JMS 接收）
• 等待 ~500

我们已经从容量的角度对应用程序进行了负载测试，但正在从入站 + 出站处理流程的扩展中查看它。

我们在机器上运行了其中的几个（都指向不同的外部 JMS 资源），但我们只看到其中一个 JVM（配置了最多入站 + 出站流的那个）运行缓慢。

从长远的角度来看，我们试图理解

1. 在轮询器 + 队列通道方面，SI 是否有扩展限制？
2. 大概有些限度，什么症状，怎么检测？
3. 这里有什么限制，线程上下文切换？还有什么？
4. 我们使用的是旧版本的 SI (1) 是否已针对此类架构进行了改进，或者是否需要重新设计？
5. 在多个入站和出站通道之间的高并发、事件样式路由的替代架构？每个入站和出站通道仍然有一组可能运行的东西（转换、过滤、验证）

Answer 1

为什么有这么多队列通道？在一个流中拥有多个异步切换（如果有的话）是不寻常的，而且通常是不必要的。通常根本没有必要，尤其是在使用消息驱动的入站端点（例如 JMS 消息驱动适配器）时。

这是因为线程和并发可以完全由适配器的消息侦听器容器管理。

最有效的配置是将入站适配器上的并发（线程数）设置为所需的，并始终使用直接通道。

事实上，如果您不希望丢失消息，这是必需的；一旦消息在队列通道中传递，JMS 消息就会被确认（默认情况下）。