我正在从事一个通过 TIBCO EMS 提供请求/响应服务的服务器端项目，我正在寻找有关存档可扩展性和低延迟的最佳实践的建议。我在 .NET 上执行此操作，但由于 TIBCO EMS 据称正在实现 JMS 规范，因此我认为针对其他 JMS 实现以及平台 (Java) 的建议是相关的。
目前，我们正在使用一个 Connection、一个 Session、一个 Consumer，并在单个 Consumer 上使用回调来监听消息。每个请求都在回调线程上处理，同步回复不同的队列(但相同的 session )。这行得通，但似乎无法扩展——即使在高事务率下，CPU 负载也可以忽略不计，但请求的延迟不断增加。
我假设发生的事情是 EMS 使用单个线程进行回调，处理时间以及发送回复所需的时间因此会阻止处理其他请求，但是 - 什么是获得的最佳方式这是规模化？
一种方法是在收到请求后立即在线程池上安排对传入请求的实际处理。这是一个快速修复并且可以扩展，但会引入额外的延迟并且会引入有关 session 使用的线程问题。另一个是拥有多个 Session 对象，甚至是 Connection 对象？任何人都可以就这样做的最佳实践提出建议，我想这一定是那里更常见的使用模式之一......
最佳答案
您需要一个两步排队过程。您的回调应该尽可能少地执行，我的首选选项是仅将消息排队到本地 Queue
您需要执行一些同步操作才能将结果返回给正确的消费者，但这应该相对微不足道。
关于.net - 在 TIBCO EMS(或其他 JMS)中，如何创建可扩展的请求/响应处理器？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7971791/