3

これが私の要件です。

クラスター内に多数のマシンがあります（たとえば、約4-A、B、C、D）。

Aの仕事は、更新についてデータベースをポーリングすることです（したがって、Aは注文テーブルで新しい注文を探している可能性があります）。
Aが更新を受信すると、B、C、Dのどちらが比較的自由であるかを確認します（負荷分散は私が推測する正しい言葉です）。次に、B、C、Dのいずれかを注文して、注文の処理を開始します。B / C/Dで処理されている注文を追跡します。

B、C、Dはスレーブのようなものです。注文処理が完了すると、Aから更新を受け取り、Aに通知するだけです。Aがダウンした場合（ネットワークの問題などにより）、B、C、Dのいずれかがマスターになり、Aの役割を果たします。実行中のジョブに関するAのメタデータも、バックアップノードEに定期的にバックアップされます。 B / C / Dが新しいマスターになり、Eからメタデータを読み取ります。

少しハドゥープのように聞こえますが、注文処理はマップリデュースモデルに適合しないため、A、B、C、D間の調整に役立つZooKeeperなどの他のフレームワークを活用する方法を探しています。

ZooKeeperはここに適していますか？

4

2 に答える 2

11

Zookeeper は、調整の問題に最適です。

次のレシピは、ユース ケースに使用できます。

A の仕事は、更新のためにデータベースをポーリングすることです (したがって、A は注文テーブルで新しい注文を探している可能性があります)。A が更新を受信すると、B、C、D のどれが比較的空いているかを確認します (負荷分散という言葉が正しいと思います)。次に、B、C、D のいずれかを注文して、注文の処理を開始します。B/C/D でどの注文が処理されているかを追跡します。

分散キューは、タスクのスケジューリングに使用できます。

B、C、D はスレーブのようなものです。注文処理が完了すると、A からの更新のみを受け取り、A に通知します。A が (ネットワークの問題か何かで) ダウンした場合、B、C、D のいずれかがマスターになり、A の業務を実行します。

リーダー選挙の問題のように見えます

実行中のジョブに関する A のメタデータも定期的にバックアップ ノード E にバックアップされます。

Zookeeper を使用してメタデータを保存できます。

于 2011-12-16T13:48:25.540 に答える
3

Zookeeperは、クラスターの同期（マスターの選択など）に最適です。あなたを助けることができるもう一つの関連する（Zookeeperのサブプロジェクト）は簿記係です

hadoopはzookeeperを使用しないことに注意してください（バージョン0.23は使用しますが、まだリリースされていません）-HBaseは現在および以前のバージョンでも使用します

于 2011-12-16T13:19:49.327 に答える