3

我正在开发一个通过 TIBCO EMS 提供请求/响应服务的服务器端项目，并且正在寻找有关存档可扩展性以及此服务的低延迟的最佳实践的建议。我在 .NET 上执行此操作，但由于 TIBCO EMS 据称正在实现 JMS 规范，因此我认为其他 JMS 实现以及平台 (Java) 的建议是相关的。

目前，我们正在使用一个 Connection、一个 Session、一个 Consumer，并使用该单个 Consumer 上的回调来监听消息。每个请求都在回调线程上处理，同步回复不同的队列（但相同的会话）。这可行，但似乎无法扩展 - 即使在高事务率下，CPU 负载也可以忽略不计，但请求的延迟不断增长。

我假设正在发生的事情是 EMS 使用单个线程进行回调，因此处理时间以及发送回复所需的时间会阻止其他请求被处理，但是 - 什么是让它扩展的最佳方法?

一种方法是在收到后立即安排线程池上传入请求的实际处理。这是一个快速修复并且可以扩展，但是会引入额外的延迟并且会引入围绕会话使用的线程问题。另一种是拥有多个 Session 对象，甚至是 Connection 对象？任何人都可以就这样做的最佳实践提出建议，我想它一定是那里更常见的使用模式之一......

4

2 回答 2

1

消息的处理受确认模式和并行会话数的影响。

根据您所说，在我看来，您只使用一个会话并在处理（和回复）一个接一个之后确认（客户端确认）消息。

这可以通过使用自动确认（在接收时确认消息）和/或并行使用多个会话来加速。

最重要的是，EMS 可以通过一个名为“prefetch count”的参数来加速消息推送，从而减少从队列中获取新消息的时间。（请参阅 EMS 文档）。

迟到的答案，但我希望它有所帮助;）

于 2013-03-03T23:38:22.740 回答
1

您需要一个两步排队过程。您的回调应该尽可能少做，而我的首选选项是仅将消息排入本地 Queue<T>。然后可以由多个本地线程访问此队列，对任何可用项目进行出队和处理，并允许 JMS 排队过程继续进行，从而消除大量延迟。

您需要进行一些同步才能将结果返回给正确的消费者，但这应该是相对微不足道的。

于 2011-11-16T11:35:23.453 回答