从 LinkedBlockingQueue 迁移到 LMAX 的 Disruptor

Posted 2023-04-12

【中文标题】从 LinkedBlockingQueue 迁移到 LMAX 的 Disruptor

【英文标题】：Migrating from LinkedBlockingQueue to LMAX' Disruptor

【发布时间】：2013-05-28 07:02:11

【问题描述】：

是否有一些示例代码可用于从标准 LinkedBlockingQueue 迁移到 LMAX' Disruptor 架构？我有一个可能从更改中受益的事件处理应用程序（单个生产者，多个消费者）。

当我的目标是最大化吞吐量而不是最小化延迟时，这是否有意义？

【问题讨论】：

嗨@pmf，我已经添加了对您的问题的一般答复。如果您能更清楚地了解您认为 LBQ 是一个问题的确切原因以及您的应用程序架构是什么样的，这可能会有所帮助。

【参考方案1】：

Mentaqueue 提供了基于相同想法的单一生产者单一消费者队列 - http://mentaqueue.soliveirajr.com/Page.mtw，您可以检查代码，虽然我自己从未使用过。

Disruptor 提供了两种开箱即用的技术 - 我暂时不会介绍代码，但如果您需要，可以这样做。

它允许对事件处理程序进行排序，您可以对其进行配置，以便每个处理程序并行处理所有请求；每个请求都由每个处理程序处理。

允许工作线程池为每个处理请求的工作线程池实现；每个请求都会从线程池中处理一次。

如果您发现排队需要很长时间，或者您有大量时间争用（锁定/同步），那么我肯定会查看 Disruptor。通过查看对架构的调整是否可能导致对 Disruptor 的干净使用，您将获得最大的好处。

是的，减少事务延迟应该有助于实现吞吐量，所以这可能是有道理的，但这取决于阻碍吞吐量的因素。这将成为一个非常笼统的评论 - 您应该确定应用程序阻碍吞吐量的区域。

引导我使用 Disruptor 的指标是 - 以类似方式处理的大量短期任务、内存争用、排序要求、流式传输或大量 IO（可能从批处理中受益）。