問題タブ [lmax]

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

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

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

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

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

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

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

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

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

LMAX Disruptor についての私の理解では、LMAX Disruptorは、(正しく使用された場合) 毎秒 2000 万メッセージのスループットを可能にする恐ろしく高速で恐ろしい並行 Java コードでいっぱいの JAR であるということです。

現在、1 秒あたり 400 メッセージのオーダーで、必要なものに対して遅い ActiveMQ インスタンスがあります。LMAX を使用するようにコードをリファクタリングすることでメリットがあるかどうか疑問に思っていますが、次の懸念があります。

• 1 つのパブリッシャーと複数の (競合する) コンシューマーを持つ方法
• LMAX はメッセージをどのように保存/保管しますか? 記憶に？
• フェイルオーバー - LMAX にはフェイルオーバー プロトコル/メカニズムが用意されていますか?
• ディスク I/O - LMAX は未使用のメッセージをディスクに保持し、後でそれらを回復できますか?

そして、私がこれらすべてに完全に的外れで、LMAX ディスラプターの使用を完全に誤解しているように見える場合、誰かがそれがいつ使用されるかの具体例を提供できますか? 前もって感謝します！

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

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 リクエストを順番に待機します。

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

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

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

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

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

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

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

私は LMAX Disruptor を初めて使用します。これは、大量のトラフィック フローを処理する必要がある多層非同期プロジェクトで使用することを検討しています。

SMS を送信するためのリクエストがプラットフォームに配信され、単純なエラーがないかリクエストがクリーニング/チェックされ、ログに記録されます。

SMS を送信しているクライアントに関連するその他のさまざまな情報が取得および分析され、その他のパラメーターが SMS 情報に追加されます。

適切なルーティング ルートが分析され、選択されます。次に、SMS-info からプラットフォーム固有のプロトコル パラメータが設定され、ルータに送信されます。

このように、ログ、請求、再試行などの SMS 配信を受信して​​処理するためのフローがあります。すべてのフェーズで、プログラム フローの同時実行または順次実行が行われます。これがプロジェクトのハイレベル ビューである場合、さまざまなモジュール間の通信 (sms-info) に LMAX ディスラプター フレームワークを使用する必要がありますか?

その場合、いくつのディスラプターの右バッファーを作成する必要がありますか?

私の理解が正しければ、異なるすべてのレイヤー/機能間で作成された新しいリングバッファーは分離されていますか?

POJO オブジェクトをリングバッファに書き込むことはできますか? これをクラスタ化された環境にどのように採用できますか? このフレームワークに関するいくつかのドキュメントを読み、いくつかのビデオを見たことがありますが、このフレームワークを使用したソリューションを視覚化することはできません。

ガイドライン/例/視覚的な図/ドキュメント、またはこれに関するあなたのアイデアは、私に大いに役立ちます。

Web アプリケーションで LMAX ディスラプターを使用しています。これは、http 要求パラメーターを受け取り、それらをリングバッファーに処理します。3 つのイベント ハンドラーがデータを処理および処理します。最後のデータはデータベースに保存されます。サーブレットがインスタンス化されるときに、リングバッファを一度初期化します。これは正しいですか？

ここで、値をリングバッファに直接入れます

イベントハンドラ

これはリングバッファに公開する正しい方法ですか? 「ringBuffer」オブジェクトを同期する必要がありますか? 最初の 2 つのイベントは並行して実行され、次に 3 番目のイベントが実行されます。パブリッシャーが速く、コンシューマーが遅い場合、これをどのように処理すればよいですか? 私はディスラプター 3.1.1 を使用していますが、Web 環境でのディスラプターの適切な使用例が見つかりませんでした。簡単なコードの実装があれば、これを理解するのに大いに役立ちます!

「クラウド」の普及が進んでいることと、さまざまなニーズに VM を使用している企業にとって、これは重要な問題のように思えます。

具体的には、Disruptor ライブラリが RHEL 仮想マシン vrs でどのように機能するかという質問です。RHEL がハードウェアに直接インストールされていますか? vrsを使用して改善があるかどうかを知ることも非常に役立ちます。VM 上にないのですか?

私はディスラプターのパターンについていくつかの調査を行いましたが、頭を包み込めないことが 1 つあります。

リング バッファのエントリを提供するプロデューサがあります。基本的に固定されているが無限の配列であるリングバッファがあります。リングバッファからのエントリを処理するコンシューマ (基本的には別々のスレッド) があります。

私は、ディスラプター パターンが株式市場の実際のシナリオでどのように使用できるかを関連付けようとしています。

通常、すべての注文を含むオーダーブックがあります。私の見方では、プロデューサーはブローカーから新しい注文を受け取ります。プロデューサーは、注文をリングバッファーに配置します。注文がリングバッファに配置された後、消費者は注文をフェッチし、注文書と照合します。

ここで、利点を理解するのに少し苦労している部分があります。スケーラブルなシステムに必要な複数の消費者がいる場合、どうすれば複数の消費者が注文を処理できますか?

整合性を確保するために、消費者がアクセスするときはオーダーブックをロックする必要があります。私が探しているのは、この質問に対する答えと、注文照合エンジンがこのパターンからどのように利益を得ることができるかという大まかなアイデアです。

LMAXは独自のオーダーマッチングエンジンを持っているので、見落としがあるはずです。

ありがとうございました