LMAX Disruptor 如何解决典型的消息代理问题？

Posted 2023-04-12

【中文标题】LMAX Disruptor 如何解决典型的消息代理问题？

【英文标题】：How does the LMAX Disruptor address typical message broker problems?

【发布时间】：2013-03-20 16:19:43

【问题描述】：

我对@9​​87654321@ 的理解是，它是一个 JAR，里面装满了可怕的快速、可怕的并发 Java 代码，每秒可以处理 2000 万条消息（如果使用正确的话）。

我们目前有一个 ActiveMQ 实例，它在整个过程中运行速度很慢，大约每秒 400 条消息。我想知道我们是否会从重构代码以使用 LMAX 中受益，但有以下顾虑：

如何拥有 1 个发布者和多个（竞争）消费者 LMAX 如何存储/存放其消息？在记忆中？ 故障转移 - LMAX 是否有故障转移协议/机制 磁盘 I/O - LMAX 能否将未使用的消息保存到磁盘并在以后恢复它们？

而且，如果我对所有这些完全不了解，并且似乎完全误解了 LMAX 干扰器的使用，那么有人可以提供一个具体的例子来说明何时使用它吗？提前致谢！

【参考方案1】：

Disruptor 不是跨进程或跨服务器消息传递系统的直接替代品。它被设计为一个进程内跨线程消息传递系统。认为替换通常在它们之间具有队列的处理线程之间的依赖关系图很有用。这对于在线程之间使用管道或多播模式的设计非常有用。 ActiveMQ 有不同的用途。

基于 Disruptor 的系统中的线程更像是长寿的 Actor，它们通过 Disruptor 传递事件来进行通信。

有关一些好的示例，请查看源代码提供的性能测试。

【讨论】：

感谢@Martin Thompson (+1)。那么是不是让每个线程都像自己的企业集成模式 (EIP) 一样工作，而 Disruptor 是每个 EIP 线程之间的超快速消息传递系统？

Disruptor 可用于将 IO 放在网络或磁盘的前面，以便可以应用智能批处理，从而以无锁方式分摊昂贵的 IO 操作成本。我不是大多数“企业”软件的粉丝，因为它可以增加成本而几乎没有价值。单个线程可以处理 IO，但它们也可以执行业务逻辑。几年前，迈克和我在 QCon 讨论过这个问题。 infoq.com/presentations/LMAX