問題タブ [disruptor-pattern]

私は高性能で信頼性の高いメッセージングシステムのディスラプターパターンについて調査を行ってきましたが、NServiceBusの熱心なユーザーとして、これを実装できるものかどうか疑問に思っていました。または、おそらくこれはすでに実装されています...私はこれについて他の人の考えについて疑問に思っていましたか？

簡単な例でディスラプターのデザインパターンとは何か教えてもらえますか? このデザインパターンの基本を知りたいです。

次は正しいですか？

• 各エントリを複数の方法（io操作またはアノテーション）で処理する必要がある場合、ディスラプターパターンは、競合することなく複数のコンシューマーを使用して並列化できるため、並列パフォーマンスとスケーラビリティが向上します。
• 逆に、ワークスティーリング（つまり、エントリをローカルに保存し、他のスレッドからエントリを盗む）は、各エントリを単一の方法でのみ処理する必要がある場合、ディスラプターパターンでエントリを複数のスレッドにばらばらに分散すると競合が発生するため、並列パフォーマンスとスケーラビリティが向上します。

（そして、複数のプロデューサー（つまりCAS操作）が関与している場合、ディスラプターパターンは他のロックレスマルチプロデューサーマルチコンシューマーキュー（ブーストなど）よりもはるかに高速ですか？）

私の状況の詳細：

エントリを処理すると、いくつかの新しいエントリが生成される可能性があり、それらも最終的に処理する必要があります。パフォーマンスが最優先され、FIFO順に処理されるエントリが2番目に優先されます。

現在の実装では、各スレッドはローカルFIFOを使用し、そこで新しいエントリを追加します。アイドルスレッドは、他のスレッドのローカルFIFOから作業を盗みます。スレッドの処理間の依存関係は、ロックレスで機械的に同情的なハッシュテーブル（書き込み時のCAS、バケットの粒度）を使用して解決されます。これにより、競合はかなり少なくなりますが、FIFOの順序が崩れることがあります。

ディスラプタパターンを使用すると、FIFOの順序が保証されます。しかし、エントリをスレッドに分散すると、作業を盗むローカルFIFO（各スレッドのスループットはほぼ同じ）よりもはるかに高い競合（読み取りカーソルでのCASなど）が発生しませんか？

私が見つけた参考文献

ディスラプターに関する標準テクニカルペーパー（第5章+第6章）のパフォーマンステストは、ばらばらの作業分散をカバーしていません。

https://groups.google.com/forum/?fromgroups=#!topic/lmax-disruptor/tt3wQthBYd0は、ディスラプターとワークスティーリングについて私が見つけた唯一のリファレンスです。共有状態がある場合、スレッドごとのキューは劇的に遅くなると述べていますが、詳細や理由については説明していません。この文が私の状況に当てはまるとは思えません。

• ロックレスハッシュテーブルで解決されている共有状態。
• 消費者間でエントリをばらばらに配布する必要があります。
• 作業の盗用を除いて、各スレッドはローカルキューでのみ読み取りと書き込みを行います。

MartinFowlerによるLMAXアーキテクチャの説明から次のシナリオを検討してください。

説明のために、LMAX以外の簡単な例を使用します。クレジットカードでゼリービーンズを注文していると想像してみてください。<...>

LMAXアーキテクチャでは、この操作を2つに分割します。最初の操作では、注文情報を取得し、イベント（クレジットカードの検証が要求された）をクレジットカード会社に出力して終了します。次に、ビジネスロジックプロセッサは、入力イベントストリームでクレジットカードで検証されたイベントを受信するまで、他の顧客のイベントの処理を続行します。そのイベントを処理すると、その注文の確認タスクが実行されます。

したがって、支払い処理の結果を受け取るまで、注文はメモリに保持されます。

ここで、クレジットカードの処理ステップの代わりに、はるかに時間がかかるステップがあると仮定します。たとえば、在庫チェックを実行する必要があります。この場合、注文したジェリービーンズの特定のフレーバーがあることを誰かが物理的に確認する必要があります。これには1時間かかる場合があります。

この場合、多くの注文が在庫状況の更新イベントを待機している可能性があるため、メモリに保持されているデータの増加につながることはありませんか？

おそらくそのようなシナリオでは、メモリから注文を削除し、それを出力イベントの一部として含める必要があります。外部システム（在庫）は、注文の詳細を含む別の入力イベントを生成する責任があります。

このアプローチで私が目にする問題は、ビジネスロジックプロセッサの一部として在庫を含め​​ることができないことです。

これにどのように対処するかについての考えは？

lmax ディスラプター パターンでの BatchEventProcessor の役割は何ですか?

= new BatchEventProcessor( ringBuffer, バリア, ハンドラ );

私のシステムには、タイプ A と B の 2 つの異なるタイプのメッセージがあります。各メッセージには異なる構造があります。タイプ A には int メンバーが含まれ、タイプ B には double メンバーが含まれます。私のシステムでは、両方のタイプのメッセージを多数のビジネス ロジック スレッドに渡す必要があります。待ち時間を短縮することは非常に重要であるため、ディスラプターを使用してメイン スレッドからビジネス ロジック スレッドにメッセージを機械的に適切に渡す方法を調査しています。

私の問題は、ディスラプターがリング バッファー内の 1 種類のオブジェクトしか受け付けないことです。これは、ディスラプタがリング バッファ内のオブジェクトを事前に割り当てるため、理にかなっています。ただし、Disruptor を介して 2 つの異なるタイプのメッセージをビジネス ロジック スレッドに渡すことも困難です。私が知る限り、次の 4 つのオプションがあります。

1. 固定サイズのバイト配列を含むオブジェクトを使用するようにディスラプターを構成します( How should one use Disruptor (Disruptor Pattern) to build real-world message systems?で推奨されているように)。この場合、メイン スレッドはメッセージをディスラプタにパブリッシュする前にバイト配列にエンコードする必要があり、各ビジネス ロジック スレッドは受信時にバイト配列をデコードしてオブジェクトに戻す必要があります。このセットアップの欠点は、ビジネス ロジック スレッドが実際にはディスラプターからのメモリを共有していないことです。代わりに、ディスラプターによって提供されたバイト配列から新しいオブジェクトを作成しています (したがって、ガベージを作成しています)。このセットアップの利点は、すべてのビジネス ロジック スレッドが同じディスラプタから複数の異なるタイプのメッセージを読み取ることができることです。

2. 単一タイプのオブジェクトを使用するようにディスラプターを構成しますが、オブジェクト タイプごとに 1 つずつ、複数のディスラプターを作成します。上記の場合、タイプ A のオブジェクト用とタイプ B のオブジェクト用の 2 つの個別のディスラプターがあります。このセットアップの利点は、メイン スレッドがオブジェクトをバイト配列にエンコードする必要がないことです。ビジネス レス ロジック スレッドは、ディスラプターで使用されるのと同じオブジェクトを共有できます (ガベージは作成されません)。このセットアップの欠点は、何らかの形で各ビジネス ロジック スレッドが複数のディスラプターからのメッセージをサブスクライブする必要があることです。

3. メッセージ A と B の両方のすべてのフィールドを含む単一タイプの「スーパー」オブジェクトを使用するようにディスラプターを構成します。

4. オブジェクト参照を使用するようにディスラプターを構成します。ただし、この場合、オブジェクトの事前割り当てとメモリの順序付けによるパフォーマンス上の利点が失われます。

この状況におすすめは？オプション #2 が最もクリーンなソリューションだと思いますが、消費者が複数のディスラプターからのメッセージを技術的にサブスクライブできるかどうか、またはどのようにサブスクライブできるかはわかりません。オプション＃2を実装する方法の例を誰かが提供できれば、それは大歓迎です！

ディスラプターに関して次の質問があります。

1. 消費者 (イベント プロセッサ) は、EventHandler を実装する Callable または Runnable インターフェースを実装していません。次に、どのように並行して実行できますか。たとえば、このようなダイヤモンド パターンがあるディスラプター実装があります。

c1 から c3 までは p1 の後に並行して動作し、C4 と C5 はそれらの後に動作します。

したがって、従来、私はこのようなものを持っていました（P1とC1-C5が実行可能/呼び出し可能である）

しかし、ディスラプターの場合、どのイベント ハンドラーも Runnable または Callable を実装していません。

次のシナリオを考えてみましょう:

私のコンシューマ C2 は、イベントへの注釈のために Web サービス呼び出しを行う必要があります。SEDA では、そのような 10 個の C2 要求に対して 10 個のスレッドを起動できます [キューからメッセージを引き出す + Web サービス呼び出しを行い、次の SEDA キューを更新する]。この場合、単一のインスタンスであるイベント プロセッサ C2 (if) が 10 個の C2 リクエストを順番に待機します。

LMX ディスラプターのバリアはどのように機能しますか? DSL でディスラプターを使用する方法を理解しています。しかし、バリアまたはシーケンスバリアがどのように機能するかについての適切なリファレンスが見つかりませんでした。

たとえば、次のリンクを見つけましたが、Barrier データ構造の使用方法がわかりません。 http://mechanitis.blogspot.com/2011/08/dissecting-disruptor-why-its-so-fast.html

たとえば、 new BatchEventProcessor() は SequenceBarrier を受け入れます。なんで？どうすれば作成できますか。

LMAX ディスラプターパターンでは、マスター ノードからスレーブ ノードに入力イベントをレプリケートするためにレプリケーターが使用されます。したがって、セットアップはおそらく次のようになります。

マスター ノードのレプリケータは、イベントを DB に書き込みます (DB に書き込むよりも優れたメカニズムを考えることができますが、問題のステートメントにはあまり重要ではありません)。スレーブ ノードのレシーバーは、DB から読み取り、イベントをスレーブ ノードのリング バッファーに配置します。

スレーブ ノードの出力イベントは無視されます。

ここで、マスター ノードのビジネス ロジック プロセッサがスレーブ ノードのビジネス ロジック プロセッサよりも遅くなる可能性があります。たとえば、マスタ ノードの BL はスロット 102 にあり、スレーブ ノードはスロット 106 にある可能性があります (これは、ビジネス ロジック プロセッサの前にリプリケータがリング バッファからイベントを読み取るために発生する可能性があります)。

このようなシナリオでは、マスター ノードに障害が発生し、スレーブ ノードがマスター ノードになると、外部システムがいくつかの重要なイベントを見逃す可能性があります。これは、スレーブ ノードとして機能していたノード 2 の出力が無視されるために発生する可能性があります。

Martin Fowler は、レプリケーターの仕事はノードの同期を維持することであると述べています。

しかし、ビジネス ロジック プロセッサの同期を維持する方法がわかりません。何か案は？