LMAX Disruptor vs JMS Provider

Question

不久前，有人告诉我LMAX disruptor，以及与标准消息队列相比，它的性能有多高。我下载了最新版本，发现它是一个普通的JAR，其中包含许多类和类型，它们都围绕着它的超快RingerBuffer对象。

归根结底，基于队列的JMS提供程序将归结为管理Java队列对象(或者更可能是并发队列)的大量代码。因此，在这方面，我看到了LMAX Disruptor和JMS提供程序(或者更确切地说，它是内部队列)之间的比较。

但是JMS提供程序不仅仅是几个队列。它是一个完整的中间件应用程序，用于处理与消费者和生产者之间的消息传递。我想知道在LMAX领域是否有JMS提供程序的等价物？

如果能以与任何其他JMS代理类似的方式连接到"Disruptor Broker“，并从它读取/写入消息，那将是非常好的。

像这样的东西真的存在吗，还是我在这里大错特错了？

Answer 1

主要区别在于，Disruptor被设计为在同一进程中工作。为什么？出于性能原因(简而言之)。更长的答案是，如果您不小心使用JMS接口、套接字连接、锁定和多线程的额外开销将有更高的开销，这使Disruptor相形见绌。

快速的JMS服务每秒可以处理超过20,000条消息，但disruptor被设计为处理每秒2000万条消息的速率。为了实现这一点，这意味着你不能做某些JMS认为没问题的事情。(见上)

Answer 2

这是一个组织为内部使用(CRUD、ORM等)开发自己的框架的时代。我有机会使用的一个框架是一个内部消息缓冲区(mediator)，它确保了应用程序部分(如消息使用者)和更慢(间歇性的)处理/持久化/网络部分之间的异步解耦。该中介器是基于与应用程序一起启动的ActiveMQ构建的，并且仅用于专用应用程序实例。

如今，我们已经有了一个环形缓冲框架Disruptor (或者构建在它之上的Reactor )，没有理由再去发明轮子了(感谢开源)。Disruptor的目的是使用FIFO缓冲区实现异步解耦，并使其更快、更方便地使用。

Disruptor相对于JMS的优势：

1. 不需要在应用程序内部支持、维护和支付外部中间件component.
2. It's，也不需要涉及任何TCP连接、网络或其他垃圾外部慢瓶颈资源，也不需要依赖于它和他们的团队。
3. Disruptor具有许多功能，如并行消耗和处理(工作进程与处理进程)策略以及开箱即用的实现，您也可以根据自己的行为要求实现自己的策略。

Disruptor wiki