15

ご挨拶、

マルチデータセンター分散システムのいくつかのコンポーネントを評価しています。（RabbitMQまたはQpidのいずれかを介して）メッセージキューを使用するため、エージェントは、アドレス指定、ルーティング、負荷分散、または再送信について心配することなく、他のエージェントに対して非同期要求を行うことができます。

多くの場合、エージェントは高度な同時アクセス用に設計されていないコンポーネントと対話するため、競合状態を回避するためにロックとエージェント間の調整が必要になります。また、エージェントまたはデータセンターの障害にシステムが自動的に対応するようにします。

上記のユースケースを念頭に置いて、ZooKeeperは適切であるように思われました。しかし、ZKとメッセージキューの両方を使おうとするのはやり過ぎではないかと思います。Zookeeperが行うことは、AMQPメッセージングを使用して自分のクラスターマネージャーで実行できるようですが、それを正しく行うのは難しいでしょう。一方、ZooKeeperを使用してメッセージキューを実装した例をいくつか見てきましたが、RabbitMQ/Qpidの方が自然に適していると思います。

誰かがこのような組み合わせを使用したことがありますか？

前もって感謝します、

-クリス

4

2 に答える 2

6

これは遅くなりますが、多分それはいくつかの役に立つでしょう。主な考慮事項は、システムのパフォーマンス特性です。ZooKeeperは、あなたが言ったように、分散キューを使用してタスク分散システムを実装する能力を超えていますが、現在、zkは書き込みよりも読み取り用に最適化されています（これは1秒あたり数千回の操作でのみ機能します） 。必要なスループットがこれより少ない場合は、zkだけを使用してシステムを実装すると、ランタイムコンポーネントの数が減り、システムがシンプルになります。もちろん、決定する前に常にパフォーマンステストを実行する必要があります。

分散調整を正しく行うのは非常に難しいので、自分でローリングするのではなく、Zookeeperを使用することを強くお勧めします。

于 2011-06-25T06:21:23.777 に答える
0

ZooKeeperが正確に何であるかはよくわかりませんが、分散同期やグループサービスなどを自分で管理する前に、Apacheのコンポーネントを使用することをお勧めします（ニーズに合っている場合）。もちろん、特にその目的のために開発者のチームを雇うこともできますが、それはあなたがより良い実装を保証するものではありません。

とにかく別のコンポーネントとして実装されると思いますが、他の方法では非常に複雑になり、ワークフローが遅くなる可能性があります。したがって、ZooKeeperまたは同様のものの好みは（私には）明らかです。

そして確かに、プロジェクトワークフローのグローバル最適化フェーズにいない限り、RabbitMQなどを使用する方が良いと思います（AMQPのcuz実装（特に商用）はすべてよりも信頼性が高いことを強調しておきます）あなたが思い付くであろうこと）。

ですから、私は両方を選び、適切なサードパーティ製品を慎重に選択しますが、必要なだけそれらを使用します。そしてそれは私の意見です。読んでくれてありがとう ：）

于 2010-05-31T05:48:25.743 に答える