3

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

归根结底，基于队列的 JMS 提供者最终会归结为管理 Java 队列对象（或者，更可能是并发队列）的大量代码。所以在这方面，我看到了 LMAX Disruptor 和 JMS 提供者（或者更确切地说，它是内部队列）之间的比较。

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

最好以与任何其他 JMS 代理类似的方式连接到“Disruptor Broker”，并向其读取/写入消息。

是否存在这样的事情，或者我在这里离基地很远？

4

2 回答 2

7

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

一个快速的 JMS 服务每秒可以处理超过 20,000 条消息，但中断器的设计目的是处理超过 2000 万条消息的速率。要实现这一点，这意味着您不能做 JMS 认为可以的某些事情。（往上看）

于 2012-04-26T21:03:08.830 回答
1

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

如今，我们有一个可用的环形缓冲区框架 Disruptor（或基于它的 Reactor），没有理由再次发明轮子（感谢开源）。Disruptor 的目的是通过 FIFO 缓冲区带来异步解耦，并使其使用起来更加快捷方便。

Disruptor 相对于 JMS 的优势：

  1. 上面提到的方法是相同的，而且速度要快得多。
  2. 无需支持、维护和支付外部中间件组件。
  3. 它在应用程序内部，无需涉及任何 TCP 连接、网络或其他垃圾外部慢速瓶颈资源，并且依赖于它和他们的团队。
  4. Disruptor 有很多特性，比如并行消费和处理（workers vs handlers）策略，开箱即用，或者您可以根据您的行为要求实现自己的策略。

破坏者维基

于 2019-06-27T16:05:15.040 回答