0

ContentServers と ContentBuilders の 2 種類のノードのクラスターで構成されるコンテンツ提供アプリケーションを構築しています。

アイデアは、常に新鮮なコンテンツを提供することです。最近ビルドされた場合、コンテンツは最新です。つまり、Content.buildTime < MAX_AGE です。

要件：

*ContentServers は、コンテンツをルックアップして提供するだけで済み (分散キャッシュなどから)、コンテンツの各アイテムの最初のリクエストを除いて、何かが構築されるのを待つ必要はありません。

*ContentBuilders は負荷を分散し、有効期限が切れる直前にコンテンツを再構築し、実際に要求されているコンテンツのみを構築する必要があります。ビルドされたコンテンツは、すべての ContentServer ですばやく取得できる必要があります

どのアーキテクチャを使用すればよいですか? 私は現在、構築されたコンテンツを保持するための分散キャッシュ (おそらく EhCache) と、コンテンツ リクエストをビルダーに中継するためのメッセージング キュー (JMS/ActiveMQ など) を考えていますが、他のオプション/提案を検討します。ContentBuilders が同時に同じものをビルドせず、有効期限が近づいたときにのみコンテンツをビルドするようにするにはどうすればよいですか?

ありがとう。

4

4 に答える 4

3

正直なところ、私はあなたのアプローチを再考し、その理由を説明します.

私は分散型の大容量システム (具体的には金融取引) とあなたのソリューションについて多くの作業を行ってきました。最近では、1 つの既製のボックスから非常に多くの電力を得ることができます)--そうすると、リモート呼び出し (つまり、別のノードからのデータの呼び出し) で命を落とすことになります。

ここでは Tangosol/Oracle Coherence について話します。これは、Terracotta がこれらの機能の一部またはほとんどをサポートし、無料であるにもかかわらず、私が最も多くの経験を持っているためです。

Coherence の用語では、n 個のノードがある場合、各ノードが合計データの1/nを所有するパーティション化されたキャッシュです。通常、少なくとも 1 レベルの冗長性があり、その冗長性はできるだけ均等に分散されるため、他のn-1ノードのそれぞれがバックアップ ノードの1/n-1を所有します。

このようなソリューションのアイデアは、可能な限り多くのキャッシュ ヒットがローカル (同じクラスター ノードに対して) であることを確認することです。また、特にパーティション化されたキャッシュでは、書き込みは比較的負荷がかかります (そして、キャッシュ エントリごとにバックアップ ノードが増えるほどコストが高くなります)。ただし、後書きキャッシュはこれを最小限に抑えることができます。あなたの要件から外したい）。

したがって、ソリューションは、すべてのキャッシュ ヒットがリモート ノードに送信されるようにします。

また、コンテンツを生成することは、それを提供することよりも間違いなくはるかにコストがかかることも考慮してください。これが、サーバーよりも多くのコンテンツジェネレーターを使用できるため、このアイデアを思いついた理由だと思います。これはより階層化されたアプローチであり、私が水平スライスとして特徴付けるものです。

アプリケーションを垂直にスライスできれば、スケーラビリティが大幅に向上します。つまり、各ノードは、すべてのコンテンツのサブセットを保存、生成、および提供する役割を果たします。これにより、ノード間の通信 (バックアップを除く) が効果的に排除され、各ノードにコンテンツの異なるサイズのサブセットを与えるだけでソリューションを調整できます。

理想的には、データのパーティション分割にどのようなスキームを選択しても、Web サーバーで再現可能である必要があります。これにより、関連データをヒットするノードを正確に認識できます。

今、あなたが提案している方法でそれを行う他の理由があるかもしれませんが、私は入手可能な情報のコンテキストでのみこれに答えることができます.

また、別の質問への回答として私が書いた、Java のグリッド/クラスター テクノロジの概要も紹介します。

于 2009-01-19T14:41:47.873 に答える
1

Hazelcastを試してみてください。これは、オープン ソース、peer2peer、分散/パーティション分割されたマップ、およびエビクションをサポートするキューです。1 つの jar をインポートします。準備完了です。超シンプル。

于 2009-05-15T06:03:24.463 に答える
0

何らかの形の分散キャッシュ、分散ロック、およびメッセージングが必要なようです。

Terracotta は、分散キャッシュ、分散ロック、およびメッセージングの 3 つすべてを提供し、プログラミング モデルは単なる Java (JMS は不要) です。

私は、キャッシュのコンテンツが 1 回だけ読み込まれるようにする方法についてブログを書きました: What is a memoizer and why you should care about it .

私はCletusに同意します-高性能が必要な場合はパーティショニングを検討する必要がありますが、ほとんどのソリューションとは異なり、Terracottaは必要になるまでパーティショニングなしで問題なく動作し、パーティショニングを適用すると、に従って作業が分割されますあなたのパーティショニングアルゴリズム。

于 2009-01-27T07:32:11.020 に答える
0

コンテンツのビルドを並列化できる場合 (ビルダー 1 は 1..1000 を実行し、ビルダー 2 は 1001..2000 を実行する)、構成ファイルを作成してこの情報を渡すことができます。ContentBuilder は、その領域の有効期限を監視する責任があります。

これが不可能な場合は、コンテンツの構築を調整する何らかのマネージャーが必要です。このマネージャーは、ロード バランサーの役割を果たすこともできます。マネージャーは、ContentBuilder と一緒にバンドルすることも、独自のノードにすることもできます。

分散キャッシュと JMS メッセージングのアイデアは良いと思います。

于 2009-01-19T14:14:42.500 に答える