我正在开发一个服务器端项目，通过TIBCO EMS提供请求/响应服务，我正在寻找有关存档可扩展性以及此服务中的低延迟的最佳实践的建议。我在.NET上这样做，但由于TIBCO EMS应该实现JMS规范，我认为对其他JMS实现以及平台（Java）的建议是相关的。
目前，我们正在使用一个Connection，一个Session，一个Consumer并使用该单个Consumer上的回调来侦听消息。每个请求都在回调线程上处理，同步回复不同的队列（但同一个会话）。这种方法有效，但似乎没有扩展 - 即使在高事务处理率下CPU负载也可以忽略不计，但请求的延迟仍在不断增长。
我假设发生的事情是EMS使用单个线程进行回调，因此处理时间以及发送回复所需的时间会阻止其他请求被处理，但是 - 获取的最佳方式是什么这可以扩展吗？
一种方法是在收到线程池后立即安排对传入请求的实际处理。这是一个快速解决方案，可以扩展，但会引入额外的延迟，并会引入有关会话使用的线程问题。另一个是拥有多个Session对象，甚至是Connection对象？任何人都可以请求关于这方面的最佳实践的建议，我想它必须是那里更常见的使用模式之一......
答案 0 :(得分：1)
您需要两步排队流程。您的回调应尽可能少，我的首选选项仅仅是将消息排入本地队列＆lt; T＆gt;。然后，可以通过多个本地线程访问此队列，对任何可用项进行队列处理并允许JMS排队过程继续进行，从而消除大量延迟。
您需要进行一些同步才能将结果返回给正确的消费者，但这应该相对简单。
答案 1 :(得分：0)
消息处理受确认模式和并行会话计数的影响。
根据您所说的，听起来我只使用一个会话并在一个接一个地处理（和回复）之后确认（客户确认）该消息。
这可以通过使用自动确认加速（在接收时确认消息） 和/或并行使用多个会话。
最重要的是，EMS可以通过名为“预取计数”的参数来加速消息推送 减少从队列中获取新消息的时间。 （参见EMS文档）。
迟到的答案，但我希望它有所帮助;）