java - Java EE アプリケーションのスケーラビリティ。どのようにアプローチしますか？

Question

私は金融業界向けのソリューションに取り組んできました。アプリケーションの主な機能は、大量の入力ファイルを読み込み、それらを消化し、永続ストアの状態を更新し、要求に応じて永続ストアから抽出を生成する機能です。かなり簡単です。

入力ファイルは、多数の繰り返しエントリを含む、業界標準形式の大きな (数百メガバイトを超える) XML メッセージです。永続ストレージはリレーショナルデータベースです。エンジンは、J2EE アプリケーションサーバーにデプロイ可能な POJO ベース (バックボーンとしての Spring Framework) Java アプリケーションとして実装されています。

問題は、ソリューションのスケーラビリティとパフォーマンスに関するものです。アプリケーションが XML からのエントリを順番に処理する場合、ソリューションのスケーラビリティはやや劣ります。アプリケーションの複数のインスタンスを 1 つのファイルの処理に関与させる方法はありません。これが、入力 XML ファイルからのエントリの並列処理を導入した理由です。基本的には、ワーカーの個々のエントリの処理をプールからディスパッチするという考え方です。ディスパッチには JMS を使用することにしました。ファイルをロードするコンポーネントはストリームを読み取り、単純に単一のエントリを抽出してディスパッチキューにフィードします。キューの反対側には多数のコンシューマーが同時にいます。それぞれがキューの 1 つのメッセージを選択してエントリを処理し、すぐに他のエントリを処理できるようになります。これは、Web コンテナー内のサーブレットとよく似ています。このアプローチで特に強力な点は、キューが共有されている限り、リモートサーバーにデプロイされたアプリケーションの個別のインスタンス内にワーカーを配置できることです。残念ながら、すべてのワーカーは永続ストレージを維持する同じデータベースに接続します。データベースサーバーが同時ワーカーからの負荷を処理するのに十分強力でない場合、これがボトルネックになる可能性があります。

このアーキテクチャについてどう思いますか? デザインへの同様のアプリケーションはありましたか？その時、どのようなデザインを選択しましたか?

score 3 · Accepted Answer

また、Map/Reduce ジョブの非常に便利なプラットフォームである Hadoop も参照してください。大きな利点は、すべてのインフラストラクチャが Hadoop によって提供されるため、新しいハードウェアノードのみを適用してスケーリングできることです。Map および Reduce ジョブの実装は 1 回だけ行う必要があります。その後は、クラスターに大量の負荷を与えることができます。

score 2 · Accepted Answer

アーキテクチャは全体的に健全だと思います。データベースがワーカーからの多数の同時更新の処理に問題がある場合は、アプリの反対側の「サイド」に 2 つ目のキューを導入できます。各ワーカーがタスクを完了すると、そのタスクの結果が列。次に、単一のワーカープロセスが定期的に 2 番目のキューから結果オブジェクトを取得し、大規模なバッチ操作でデータベースを更新しますか? これにより、データベースの同時実行性が低下し、更新の効率が向上する可能性があります。

score 1 · Accepted Answer

Mork0075が言ったように、並列処理の場合、hadoopは優れたソリューションです。実際、多くの企業が非常に大規模なログ分析に使用しています。そして、興味深いプロジェクトHiveは、データウェアハウジング用のHadoopに基づいて構築されています。

とにかく、あなたの現在のデザインはかなりスケーラブルだと思います。すべてのワーカーがデータベースにアクセスすることについての懸念については、ワーカーとデータベースの間に別のメッセージングキューを配置するだけです。ワーカーは処理結果をキューに入れ、キューにサブスクライブしてデータベースを更新する別のプログラムを作成します。欠点は、2つのキューによってシステムが複雑になりすぎる可能性があることです。もちろん、既存のMQシステムに別のトピックを追加することもできます。これにより、システムがよりシンプルになります。別のアプローチは、NFSなどの共有ファイルシステムを使用することです。各ワーカーマシンは共有ファイルサーバーに同じディレクトリをマウントし、各ワーカーはその処理結果を共有ファイルサーバー上の個別のファイルに書き込みます。次に、データベースを更新するために新しいファイルをチェックするプログラムを作成します。このアプローチでは、別の複雑さを導入します。共有ファイルサーバーです。

score 1 · Accepted Answer

1

また、Terracota クラスタリングソリューションもご覧ください。

于 2009-03-13T18:46:21.520 に答える

score 1 · Accepted Answer

私は最近、Spring Batch 2.0 の調査に余暇を費やしています。これは、Spring フレームワークに基づく Java バッチ処理エンジンの新しいバージョンです。Spring Batch を実装した人たちは、このリリースの同時実行と実行の並列化に集中しました。私はそれが有望に見えると言わなければなりません！

score 0 · Accepted Answer

すでに Spring/Java EE を使用している場合、「並行アーキテクチャ」のソリューションとして Spring Batch を適用するのは当然です。

バットの 2 つの利点:

Spring Batch (2.0 以降) はパーティショニングを実装します。つまり、フレームワークがデータを個別のパーティショニングステップ ( StepExecution) でパーティショニングし、これらのステップの実際の実行を複数のスレッドまたは他の分散システム (PartitionHandlersたとえばTaskExecutorPartitionHandler、またはもっと分散するMessageChannelPartitionHandler、など。）
Spring には、XML を処理するための優れた OXM パッケージがあります。Spring Batch には、StaxEventItemReader処理用のレコードに対応する入力 XML ドキュメントからフラグメントを抽出するパッケージがあります。

Spring Batch を試してみてください。ご不明な点がございましたら、お気軽にお問い合わせください。喜んでお手伝いさせていただきます。

EDIT:

Scala/AKKA Actorsおよび/またはも参照してくださいScala parallel collections。あなたのタスクがシャーディング/パーティション化/分散に適用できる場合=>それがアクターモデルの目的です。

非 JVM ソリューションを検討したい場合は、Erlang OTP=> シンプルでエレガントをご覧ください。

score 0 · Accepted Answer

あなたの質問に答えて：

このアーキテクチャについてどう思いますか? デザインへの同様のアプリケーションはありましたか？その時、どのようなデザインを選択しましたか?

それは良いアーキテクチャだと思います。DB がボトルネックであることは間違いありません。ただし、設計は柔軟で、データベースへの入力量を制御できます。

ノード間のマルチスレッドが機能しています。Haddoop やその他の分散処理システムが、データベースに対して単に I/O を行っているだけなので、既に持っているものよりもはるかに多くの機能を提供できるかどうかは完全にはわかりません。

集中ロギングのために JMS キューを使用して同様のものを実装しましたが、コードへの影響が少なく、ログをディスクに書き込むことで非常にうまく機能しました。あなたのアプリケーションにはうまくいくと思います。

java - Java EE アプリケーションのスケーラビリティ。どのようにアプローチしますか？

7 に答える 7

Related

Reference