ディスラプターの使用中に、遅れているコンシューマーが存在する可能性があり、その遅いコンシューマーのために、アプリケーション全体が影響を受けます。
すべてのプロデューサー (パブリッシャー) とコンシューマー (EventProcessor) がそれぞれ 1 つのスレッドで実行されていることを念頭に置いて、遅いコンシューマーの問題を解決するにはどうすればよいでしょうか?
単一のコンシューマーで複数のスレッドを使用できますか? そうでない場合、より良い代替手段は何ですか?
ディスラプターの使用中に、遅れているコンシューマーが存在する可能性があり、その遅いコンシューマーのために、アプリケーション全体が影響を受けます。
すべてのプロデューサー (パブリッシャー) とコンシューマー (EventProcessor) がそれぞれ 1 つのスレッドで実行されていることを念頭に置いて、遅いコンシューマーの問題を解決するにはどうすればよいでしょうか?
単一のコンシューマーで複数のスレッドを使用できますか? そうでない場合、より良い代替手段は何ですか?
一般的に言えば、WorkerPool を使用して、複数のプールされたワーカー スレッドが 1 つのコンシューマで動作できるようにします。これは、独立した、潜在的に可変の期間 (たとえば、短いタスクと長いタスク) があるタスクがある場合に適しています。
もう 1 つのオプションは、複数の独立したワーカーがイベントを並列処理するようにすることですが、各ワーカーはモジュロ N ワーカーのみを処理します (たとえば、2 つのスレッドで 1 つのスレッドが奇数を処理し、1 つのスレッドが偶数のイベント ID を処理します)。これは、一貫した期間の処理タスクがある場合にうまく機能し、バッチ処理も非常に効率的に機能します。
考慮すべきもう 1 つのことは、コンシューマーが「バッチ処理」を実行できることです。これは、たとえば監査で特に役立ちます。コンシューマーが 10 個のイベントを待機している場合、10 個のイベントを個別に監査ログに書き込むのではなく、10 個のイベントすべてを収集して同時に書き込むことができます。私の経験では、これは複数のスレッドを実行する必要性をカバーする以上のものです。
遅い部分を他のスレッド (O(1) や O(log) 計算などではなく I/O) に分離するか、コンシューマが過負荷になったときに何らかのバック プレッシャーを適用するようにしてください (プロデューサの譲歩または一時的な駐車によって、 503 または 429 ステータス コードでの再生など): http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html