0

私はこれを誤解しているかもしれませんが、ROUTER/DEALERパターンを使用するzmqと、リクエストがレスポンダーによって受信されたときに、来た道を戻る必要があるようです。

リプライヤがリモート リクエスタに直接応答するようにすると、ネットワーク レイテンシが減少するようです。

の代わりに物理アドレスを渡すことで、これを行う方法はありますidか?

このようなシステムを構築することは可能ですか？

REQこの-> ROUTER-> DEALER-> REP- >のような伝送チェーンを見たいと思いますREQ。両方の出現がREQ同じマシンを表しています

4

2 に答える 2

1

ここで探していることを行うことができますが、システムを乱用して意図しない方法で動作させないでください。そうしないと、メンテナンスの悪夢を自分で作成することになります. この場合の「遠すぎる」の境界線は、開発チームやプロジェクトごとに異なりますが、覚えておいてください。

提案されたパターンで問題が発生するいくつかの理由を次に示します。

  • DEALER ソケットは、他の 2 つのソケットとピアリングされています。DEALER ソケットはラウンドロビン方式でデータを送信するため、1 つのメッセージを REP ソケットに送信し、次のメッセージを ROUTER ソケットに戻します。おそらくあなたが望むものではありません。
  • 明確なサーバー ソケット (使用するbind()) またはクライアント ソケット (使用する) はありませんconnect()。提案されたパターンでは、ソケットの合計が偶数であるためうまくいきますが、チェーン内のソケットを追加または削除すると、次のシナリオに遭遇します。

-

SOCKET A  ->  SOCKET B  ->  SOCKET C  ->  (SOCKET A)
CLIENT        SERVER        CLIENT        ( CLIENT )
CONNECT       BIND          CONNECT       ( CONNECT)

別のソケットconnect()に接続できないソケットconnect()。2 つのソケットと同じですbind()。

  • REQ ソケットは要求を送信したソケットからの応答を期待し、REP ソケットは要求を送信したソケットに応答するという概念を破ろうとしています。それが可能であれば（私はそれを調べていません）、それは「遠すぎる」と「メンテナンスの頭痛を期待する」という私のラインになります。

... これが私のアドバイスです。

  • 持っていない、または持っていない場合は、ガイドをお読みください。
  • メッセージング プロトコルは難しいものです。それらは簡単であるように見えますが、間違いを犯しやすいです。これが、効率が悪いと思われる場合でも、市販のプロトコルを使用することをお勧めする理由です。
  • 時期尚早に最適化しないでください。おそらく、余分なネットワーク遅延がボトルネックになることはありません. 実際にどれだけのデータを渡していますか? 大部分のデータをオフロードする方法はありますか? たとえば、メッセージごとに MB のデータを送信する場合、中央からアクセス可能なリポジトリに保存し、メッセージで URI を送信するだけでよいでしょうか?
  • ガイドには多数のメッセージング プロトコルが記載されており、ZMQ リソース サイトで無料で配布されています。それらはテストされ、適切に設計されています。それらがうまくいかない場合を除き、試してみてください。

提案したメッセージング パターンを機能させたい場合は、それにソケットを追加する必要があります。各プロセスは着信ソケットと発信ソケットを所有する必要があります (これにより、常に偶数のソケットが存在し、bind()ing とconnect()ing が管理可能であることが保証されます。ソケットの種類ごとに適切なメッセージングを維持できます (REQ と REP の期待を壊すことはありません)。 ) 通信の残りの半分をピックアップする別のソケットを追加する. しかし、実際には、既存のプロトコルを調べて、それらが機能しないことと、その理由を最初に判断する必要があります.

于 2014-10-24T14:39:28.210 に答える
0

はい、そうですが、そうでなければ論理的な質問にはいくつかの注意事項があります

ZeroMQ は、メッセージ ペイロード内にカプセル化されたノードの物理アドレスを問題なく渡すことができますが、これがあなたの願いを簡単に解決しない理由があります。

  1. ZeroMQ は、スマートでスケーラブルな正式なパターンの強力なフレームワークであり、その上にユーザーが独自のメッセージング システムを構築します。したがって、正式なパターン (alikePUB/SUBまたはREQ/REP) を使用することは、その半分または 3 分の 1 だけでなく、ハードワイヤード プロパティ (その動作) を完全に再利用することを意味します。動作を理解することで、開発を計画している機能の上位レイヤーを構築できるようになりますが、ZeroMQ ライブラリ プリミティブ == ビルディング ブロックの動作モデルを妥協することはできません。構成要素を不安定にすると逆効果になるため、新しいよりスマートなアドオン機能を統合してください」フレームワークの強度と堅牢性を失うことを犠牲にして物事をハッキング/密輸しようとするよりも、完全に機能するプリミティブ関係の "。

  2. ZeroMQ プリミティブは、複数の「トランスポート クラス」を介して同時に相手側に接続される可能性があり、この事実はアプリケーション ロジックに対して完全に透過的です。これは、あなたのアイデアがinproc:「接続された」状態で始まった場合REQ、アドレスの受け渡し/ルーティングは遠端では機能しないことを意味します。REPノードには発信元へのそのようなトランスポートクラス互換のパスがなく、アドレスは偶然に衝突するか、リモート側に存在しないと役に立たなくなるため、応答をより速く/より簡単にルーティングすることで期待される利点が得られます。リクエスタ（ルーティングが中間ノードの軌道セグメントをスキップ/バイパスし、応答を待つままになると、ペアワイズで協力するピア間の「ハンドシェイク」が失われるという問題をこの瞬間スキップします... )

詳細はどこで確認できますか?

このための最善の次のステップは、私の意見では、もう少しグローバルなビューを取得することです。これは、ZeroMQ でコーディングしようとする最初のいくつかのことについては複雑に聞こえるかもしれませんが、少なくとも265 ページにジャンプする場合Code Connected, Volume 1、そこを順を追って読む場合でなければ。

史上最速の学習曲線は、最初に図 60 更新の再発行と図 62 HA クローン サーバーのペアを非公開で表示して、 可能な高 可用性アプローチを実現し、次にルート、要素、および詳細に戻ることです。 .

ここに画像の説明を入力

于 2014-10-24T10:22:23.043 に答える