從LinkedBlockingQueue遷移到LMAX'Disruptor

Question

是否有一些示例代碼用於從標准LinkedBlockingQueue遷移到LMAX的Disruptor架構？ 我有一個事件處理應用程序（單個生產者，多個消費者）可能會從更改中受益。

當我的目標是最大化吞吐量而不是最小化延遲時，它是否有意義？

Answer 1

Mentaqueue基於相同的想法提供單個生產者單個消費者隊列 - http://mentaqueue.soliveirajr.com/Page.mtw ，您可以檢查代碼，但我自己從未使用過它。

Disruptor開箱即用提供了兩種技術 - 我不會進入代碼但是如果你需要可以這樣做。

1. 它允許一種對事件處理程序進行排序的方法，您可以對其進行配置，以便每個處理程序將並行處理所有請求; 每個請求都由每個處理程序處理。

2. 一個Worker Pool實現，允許每個工作線程池處理一個請求; 每個請求都將從線程池中處理一次。

如果您已經確定排隊需要很長時間，或者您有很長時間爭用（鎖定/同步），那么我肯定會看看Disruptor。 通過查看對您的體系結構的調整是否可以導致干擾器的清潔使用，您將獲得最大的好處。

是的，減少事務延遲應該有助於實現吞吐量 ，因此它可能有意義，但這取決於阻礙吞吐量的因素。 這將成為一個非常籠統的評論 - 您應該確定應用程序阻礙吞吐量的區域。

導致我使用Disruptor的指標是 - 許多以類似方式處理的短期任務，內存爭用，排序要求，流式傳輸或重IO（可以從批處理中受益）。