3

タイトルに記載されている問題に対する水平スケーリングの解決策を見つけようとしています。

問題のより詳細な説明は、次のようになります。メッセージ キュー Web サービスから、どこかにアップロードされたファイルへの URL を含むメッセージを読み取り、ファイルをダウンロードして解析し、そのコンテンツの場所がコンテンツに依存するファイルに追加します。 .

大量のメッセージがキューに入るため (毎秒 100 メッセージを連続して想定)、複数のワーカーで同時処理を実行する場合、ファイルへの制御されたアクセスがない場合、データが失われる可能性があります。

関連する特定の情報は、メッセージのバッチ内で、2 つのメッセージが同じ宛先ファイルに対するものである可能性は低いということです (これは、メッセージの 1% で均等に分散されると仮定します)。メッセージとそのファイルは、キューからメッセージを読み取る速度をわずかに上回っているため、衝突の可能性がかなり低くなります。

確率が非常に低い場合は、一部のデータを失うことは許容できるかもしれませんが、正確な数はわかりません。

これに使用できるアルゴリズムまたは設計パターンは何ですか?

いくつかの詳細：

  • 1,000 万個の異なる出力ファイル
  • 1 日あたり 500 万通のメッセージ
  • ファイル ストレージはサードパーティの Web サービスによって提供され、無制限の同時読み取り/書き込みが可能です。
  • メッセージの順序は重要ではありません
  • メッセージにはファイルへの URL のみが含まれます (GUID を名前として含む)
4

2 に答える 2

1

何が問題なのかわかりません。あなたはおそらくそれについて言及するのを忘れていました。あなたが説明した問題については、非常に簡単な解決策があります。ラウンド ロビンまたはバランスのとれた方法で、ワーカー ノードのプール全体にメッセージを配信するだけです。各ワーカーはファイルをロードし、解析してサードパーティのストレージに保存します。それで全部です。

たとえば、 RabitMQなどの (分散型) メッセージ キュー ソリューションを探します。

編集：つまり、それはダムストレージの問題であることがわかりました。「アトミックな」追加と透過的な圧縮/解凍を提供する、ダムのサードパーティストレージの前に、実際のストレージレイヤーが必要です。スケーラブルなストレージを構築するためのテクニックがあります。有名なダイナモ紙を見てください。機能要件が非常に狭いため、RiakのRiak Coreとしてオープン ソース リング実装を中心に独自のソリューションを簡単に作成し、サード パーティのストレージをバックエンドとして使用できます。

基本原理を簡単に説明します。(一貫性のある) ハッシュによって宛先スペースをバケットに分割します。次に、アトミック操作を提供する各バックのシリアライザーを保持します。あなたの場合、それはappend透過的（解凍）圧縮です。シリアライザーは状態を保持し、キャッシュとしても機能します。なので外からはロックフリーに見えます。

于 2014-07-10T06:32:53.627 に答える
1

ダウンロードと追加の基本的な作業は、任意の数のワーカー間で任意にスケーリングできるため、ここでの重要な問題は、一度に 1 つのファイル更新のみが発生することを保証する方法のようです。それを達成するためのいくつかの方法： -

オプション 1: ダウンロードを追加から分割します。 複数の「ダウンロード」ワーカー: コンテンツをフェッチし、場所を計算し、場所のハッシュを計算し、ハッシュに基づいてコンテンツをライター キューに入れます。複数の「ライター」ワーカーは、それぞれが単一のキューを消費し、他のライターが同じ場所を更新しようとしないことを保証して、そのキューを順番に処理します。システムが恣意的な障害に正常に耐えられるように、何らかの形式の一貫したハッシュを実装する必要がある場合があります。

オプション 2: ロック用に別のシステムを作成する 複数のワーカーがそれぞれコンテンツをダウンロードし、場所を計算し、セカンダリ システム (データベース、ファイル システム、メモリ内分散キャッシュ) で場所をロックし、追加操作を実行し、解放します。ロック。基本的に、これは分散ロックの問題になります。

于 2014-07-10T05:42:35.517 に答える