1

ファイルが絶えず生成されているサーバーがたくさんあります。これらのファイルは、中央の場所に送信する必要があります。ファイルは 50MB を超えることはありません。ZeroMQ を使用してこれらのファイル (メッセージにカプセル化) を送信し、中央の場所でファイルの書き込みが同時に行われないようにする予定です (たとえば、scp を使用して転送を行うと、宛先で多くのディスク書き込みプロセスが開始されます)。

ZeroMQ でこれを行ういくつかの方法を確認できます。

  1. プロデューサでは REQ ソケットを使用し、コンシューマでは単一の REP ソケットを使用します。これは機能する可能性がありますが、公平なキューイングがないため、低速のプロデューサーを飢えさせると思います。また、REP ソケットが使用できない場合に REQ ソケットがメッセージをドロップするかどうかもわかりません。
  2. プロデューサでは PUSH ソケットを使用し、コンシューマでは PULL ソケットを使用します。これにはコンシューマーでの公平なキューイングがあり、ドキュメントによると、PUSH ソケットはメッセージを決して破棄しません。しかし、それは完全に信頼できますか？

私の信頼性の要件は次のとおりです。

  1. メッセージ (私の場合はファイル) は失われません。そのため、コンシューマで受信したメッセージごとにプロデューサーへの確認があるように構築したいと思います。
  2. 特定のプロデューサからのメッセージは、プロデュースされたのと同じ順序で受信する必要があります。
  3. プロデューサーは行き来することができ、消費者が一定期間利用できなくなることに抵抗する必要があります。

この種のアプリケーションに適したソケットの種類は何ですか? 私が見るべきzmqパターンの種類へのポインタは素晴らしいでしょう.

4

1 に答える 1

0

メッセージの数が少なく、高い信頼性が要求されるため、このタスクには REQ/REP アプローチが最適と思われます。

  1. 作成順序 (ファイル名の時間または db のファイル インデックス) を確認できるように、各プロデューサーにファイルを保存します。
  2. 各プロデューサは、最も古いファイルを選択してソケットに送信し、ACK 応答を待つ必要があります。ファイルは、ACK 時に削除 (または配信済みとしてマーク) する必要があります。
  3. コンシューマーは、ソケットからファイルの内容を読み取り、それをディスクにフラッシュし、その後 ACK メッセージを送信する必要があります。
  4. プロデューサは、前のファイルから ack を受信した後にのみ、次のファイルを送信する必要があります。

これはうまくいくかもしれませんが、ここで大きな問題が 1 つあります。ディスクにアクセスしたり、コンシューマでプロセスを生成したりしなくても、複数のプロデューサがコンシューマのネットワーク インターフェイスをフラッディングします。これは、プロデューサが開始するファイル転送を使用する設計では問題になるはずです。PUSH/PULL ソケットにも同じ問題があります。

もう 1 つの注意点: ZeroMQ メッセージは、メッセージ全体が受信されるまでメモリにバッファリングされます。したがって、それぞれ 50MB のファイルを送信する 20 のプロデューサーは、ピーク時に 1GB の RAM を必要とします。

別の方法として、ファイルの名前だけをプロデューサーに送信し、ファイルを順番にプルすることを提案します。

于 2013-08-22T09:15:41.327 に答える