5

シナリオ: 地理的に分散した複数のノードがあり、その場所のメッセージを収集するキューが必要です。次に、この収集されたデータをすべてのノードのすべてのキューから中央の場所にある対応するキューに送信します。中央ノードでは、キューに収集されたデータを(他のノードから)引き出し、処理して永続的に保存します。

制約:

  • データは私たちにとって非常に重要です。したがって、どのような場合でもデータが失われないようにする必要があります。
  • したがって、ノードが何らかのランダムな理由でダウンした場合でも、ノードを起動したときに収集されたデータを安全に保管し、中央ノードに送信して処理できるように、すべてのノードに永続的なキューが必要です。
  • 同様に、中央ノードがダウンした場合、データは他のすべてのノードに残っている必要があります。これにより、中央ノードが起動したときに、処理のためにすべてのデータを中央ノードに送信できます。
  • また、中央ノードのデータが複製されたり、再度保存されたりしてはなりません。つまり、ノードの1つで収集されたデータは、中央ノードに1回だけ保存する必要があります。
  • 収集するデータは私たちにとって非常に重要であり、中央ノードへのデータ配信の順序は問題ではありません。

私たちのソリューション 私たちはいくつかのソリューションを検討しましたが、その中から私たちが最良だと思ったソリューションをリストアップします。考えられる解決策(私たちの意見では)は、Redisが永続ストレージを提供するため、Redisを使用してあらゆる場所でキューを維持することです。次に、地理的に離れたすべてのノードでデーモンを実行し、キューからデータを読み取り、中央ノードに送信します。データを受信すると、中央ノードはデータを受信したノードにACKを送信し(データは非常に重要であるため)、ACKを受信すると、ノードはキューからデータを削除します。もちろん、ACKを受信する必要があるタイムアウト期間があります。

問題 上記の解決策(私たちによると)はうまく機能しますが、問題は、ここで間違っている可能性があるという単純な理由で、同期プロトコル全体を自分で実装したくないということです。Redisでこの特定の同期方法を見つけることができませんでした。そのため、RabbitMQ、ZeroMQなどの他のAMQPベースのキューを利用できます。これらのソリューションでこれを実行できるかどうかもわかりませんでした。

  • これらのメッセージキューまたはその他のデータストアは、問題の解決策となる機能を提供しますか?はいの場合、どのように?
  • そうでない場合、私たちのソリューションは十分に良いですか?
  • 誰かがより良い解決策を提案できますか?
  • これを行うためのより良い方法はありますか?
  • フェイルセーフにするための最良の方法は何でしょうか?
  • 収集するデータは私たちにとって非常に重要であり、中央ノードへのデータ配信の順序は問題ではありません。
4

1 に答える 1

4

中央ノード(またはノードのクラスター)を他のノードからのメッセージのコンシューマーとして設定し、メッセージ確認機能を使用することで、RabbitMQでこれを行うことができます。この機能は、中央ノードがack配信を実行できることを意味し、他のノードはackの後にのみメッセージを削除します。例を参照してください:http ://www.rabbitmq.com/tutorials/tutorial-two-python.html

さらに質問がある場合は、メーリングリストrabbitmq-discussに電子メールを送信してください。

于 2012-06-28T09:53:19.987 に答える