16

ZeroMQ PUB/SUB の簡単なテストを行ったところ、動作するコードがいくつかありました。ただし、zeromq で適用される最高水準点の概念については少し混乱しています。

ソケットに接続された各サブスクライバーのキューの長さを設定するパブリッシャー コードに HWM を設定しました。

ただし、サブスクライバーの受信ソケットに HWM を設定することもできます。サブスクライバー側で HWM を設定する理由はありますか?これは、パブリッシャー HWM の設定とどのように異なりますか?

4

2 に答える 2

34

簡潔な答え：

パブリッシャーでは、システム全体に影響を与えるクラッシュ (メモリ不足) の理由がたくさんあるため (パブリッシャーはすべてのサブスクライバーにサービスを提供するため)、ほとんど常に HWM を慎重に検討する必要があります。

サブスクライバでも、HWM の調整が役立つ場合がありますが、これは主にサブスクライバの性質、受信したメッセージの処理方法、およびサブスクライバで処理できない可能性の高さによって異なります。多数の受信メッセージの時間。予想されるランタイム環境 (使用可能なメモリの量、サブスクライバーの数など) によって異なります。

より詳細な回答：

ZMQ は、HWM (最高水準点) の概念を使用して、内部パイプの容量を定義します。ソケットからの、またはソケットへの各接続には、ソケットのタイプに応じて、独自のパイプと、送信および/または受信用の HWM があります。一部のソケット ( PUB, PUSH)には、送信バッファしかありません。一部の ( 、、、SUB)は受信バッファしかありません。一部の ( 、、) には、送信バッファーと受信バッファーの両方があります。PULLREQREPDEALERROUTERPAIR

利用可能なソケット オプションは次のとおりです。

ZMQ 3.0+ は、内部バッファ (いわゆる HWM) にデフォルトの制限を強制します。これは、HWM がメモリ オーバーフローの問題を軽減する優れた方法であるためです。

ZMQ_PUBとの両方ZMQ_SUBのZMQ_HWMオプション アクションが「ドロップ」に設定されているため、制限がリッチになると、少なくとも ZMQ バッファーに依存するものによって、サブスクライバーまたはパブリッシャーのメモリの増加が停止するはずです。

通常、無差別なメモリ使用 (メモリ不足の問題) から最も保護する必要があるのはパブリッシャーです。

インプロセス トランスポートでは、送信側と受信側が同じバッファーを共有するため、実際の HWM は両側で設定された HWM の合計になります。

ただし、TCP を使用していてサブスクライバーが遅い場合、メッセージはパブリッシャーでキューに入れられます。

の一般的な失敗の原因PUB-SUBは次のとおりです。

  • サブスクライバーがメッセージをフェッチするのが遅すぎる可能性があるため、キューが蓄積されてオーバーフローします。
  • ネットワークが遅くなりすぎて、発行元側のキューがオーバーフローし、発行元がクラッシュする可能性があります。

パブリッシャーでメッセージをキューに入れると、パブリッシャーがメモリ不足になり、特に多くのサブスクライバーがあり、パフォーマンス上の理由でディスクにフラッシュできない場合にクラッシュします。

パブリッシャーの観点からは、ZWM を適切に設定することによって使用する優れた戦略は、しばらくすると新しいメッセージのキューを停止することです。新しいメッセージは拒否またはドロップされます。これは、パブリッシャーが HWM を設定したときに ØMQ が行うことです。

ZMQ は、サブスクライバーでメッセージをキューに入れることもできます

誰かがメモリを使い果たしてクラッシュする場合、それはパブリッシャーではなくサブスクライバーになります。これは公平です。これは、サブスクライバーがしばらく追いつくことができない「ピーキー」なストリームに最適ですが、ストリームが遅くなったときに追いつくことができます。

注: HWM は正確ではありません。デフォルトで最大 1,000 のメッセージを受け取ることができますが、libzmq がそのキューを実装する方法により、実際のバッファー サイズははるかに小さい (半分程度) 場合があります。

これらの仮定の主な情報源は、電子形式でオンラインで入手できる Pieter Hintjens の本「Code Connected Volume 1」です。このトピックに関する詳細な説明を含むハイウォーターマーク専用の章があります。

于 2013-05-08T03:22:29.867 に答える