0

背景:私は、数百万以上のファイルを読み取り、それらのファイルを変換または解析するソフトウェア アプリケーションを設計しています。要件の一部は、スケーラブルな分散システムを構築して、それに応じて読み取りと解析をスケーリングできるようにすることです。

基本的に、ファイル名の最小限の詳細なリストは 1 つの DB であり、クライアントはリストにアクセスして、次にどのファイルを解析/変換する必要があるかを知る必要があります。ファイルは再び別のサーバー/場所にあります。ほとんどの部分は設計されていますが、再検討が必要な重要な部分の 1 つは、さまざまなクライアントにファイル名を提供する設計です。

現在、次の 2 つのオプションがあります。

  1. DB の隣に位置し、すべての要求をファイル名にチャネル化し、クライアントに供給する単一のサービスを設計します。したがって、この場合、クライアントはサービス (事前定義されたプロトコル/フォーマット) と対話し、リストを取得します。

  2. DB と直接対話し、クライアント内で同期/チャネライゼーションを実装するようにクライアントを設計します。

最初のオプションに関する私の唯一の懸念は、それはスケーラブルなアーキテクチャ/設計ですか? スケーラブルなアーキテクチャで、スケーリングで1つのリソースが重要になるような状況に対処した人はいますか(私の場合、すべてのクライアントに供給/サービスを提供する1つのサービスである可能性があります)

4

2 に答える 2

2

DB の上に GigaSpaces (http://www.gigaspaces.com/datagrid) のような分散データ グリッドを使用することをお勧めします。このようにして、データを複数のマシンに分割し、DB での競合を減らすことができます。クライアントは、データ グリッドのさまざまなインスタンスから処理するファイルを読み取ります。負荷の増加に応じてデータ グリッド パーティションの数を増やし、データ グリッド インスタンス間でデータを分割する方法を決定することで、スケーラビリティが可能になります。

1 つのクライアントのみが処理対象の特定のファイルを読み取るようにするために考慮すべき可能性がいくつかあります。そのうちの 1 つは、データ グリッドの取得操作 (読み取りと削除) を使用して、1 つのクライアントのみがファイルを「取得」するようにすることです。処理されます。

GigaSpaces は優れた監視ツールも提供しているため、負荷 (ライブネス、統計など) を監視できます。

于 2012-05-10T05:09:33.490 に答える
0

Rabbit MQ (http://www.rabbitmq.com)、Microsoft Message Queue (http://bit.ly/GMo4iI)、IBM Message Queue (http:// bit.ly/GMo6qY) で、既にスケーリング アーキテクチャが導入されています。

キューからのメッセージを要求するようにクライアントをセットアップし、処理するファイルの詳細が含まれるように各メッセージ本文を構成できます。ファイルが処理されると、クライアントはメッセージをキューから削除できます。

同じファイルが同時に読み取られないようにするためのメカニズムをセットアップする必要がありますが、これはキュー レベルで行うことができ、特定のキューまたはメッセージの優先度を調べるように各クライアントを構成します。

于 2012-03-24T09:09:52.467 に答える