不久前有人告诉我有关 LMAX 干扰器以及与标准消息队列相比它的性能如何。我下载了最新版本，发现它是一个普通的 JAR，其中包含许多类和类型，这些类和类型都围绕其超快的 RingerBuffer 对象。
归根结底，基于队列的 JMS 提供程序最终会归结为管理 Java 队列对象（或者，更可能是并发队列）的大量代码。所以在这方面，我看到了 LMAX Disruptor 和 JMS 提供者（或者更确切地说，它是内部队列）之间的比较。
但 JMS 提供者不仅仅是几个队列。它是一个完整的中间件应用程序，用于处理与消费者和生产者之间的消息传递。我想知道 LMAX 领域是否有等效的 JMS 提供程序？
最好以与任何其他 JMS 代理类似的方式连接到“Disruptor Broker”，并向其读取/写入消息。
这样的事情是否存在，或者我在这里太离谱了？
【问题讨论】：
标签： java concurrency jms message-queue
主要区别在于 Disruptor 设计为在同一进程中工作。为什么？出于性能原因（简短回答）。更长的答案是，如果你不小心使用 JMS 接口、套接字连接、锁定和多线程的额外开销，将会有更高的开销，这会使 Disruptor 相形见绌。
快速 JMS 服务每秒可以处理超过 20,000 条消息，但中断器的设计目的是处理超过 2000 万条消息的速率。要实现这一点，这意味着您不能做 JMS 认为可以的某些事情。 （见上文）
【讨论】：
当时组织开发了自己的内部使用框架（CRUD、ORM 等）。我有机会使用的框架之一是内部消息缓冲区（中介），它确保应用程序部分（如消息消费者）和更慢（间歇性）的处理/持久化/网络部分之间的异步解耦。该中介器是基于 ActiveMQ 构建的，该 ActiveMQ 与应用程序一起启动并仅用于专用应用程序实例。
如今，我们有一个可用的环形缓冲区框架 Disruptor（或基于它构建的 Reactor），没有理由再次发明轮子（感谢开源）。 Disruptor 的目的是通过 FIFO 缓冲区带来异步解耦，使其使用起来更加快捷方便。
Disruptor 相对于 JMS 的优势：
【讨论】：