Q1:ここで説明されているデフォルトのプロセス間通信と比較して、子プロセスにメッセージを送信するために使用することの違いは何ですか?ZeroMQ
Q2: プロセスから子への直接的なコミュニケーションとして、どちらがより適切ですか? (より速く)
Q3: ドキュメントには次Creates an IPC channel
のように書かIPC
れています。TCP
? ソケット?
非常に最初の瞬間に述べる良い点 -ブローカーレスZeroMQ
です
ZeroMQ
A1:メッセージの送信と使用の違いIPC
このように言えば、メッセージを送信してスケールアップする機能だけでなく、ZeroMQ
さまざまな利点に集中しています (どちらも役立ちます)。
ZeroMQ
(十分にスケーラブルな)正式なコミュニケーション パターンを導入するこれは、コア アプリケーション側の焦点は、参加するエージェント間で実際に必要な動作モデル (1 PUB
+ 多くのSUB
-s / 多くのPUB
-s + 多くの相互接続されたSUB
-s )
または
、もう少し複雑なアプリケーション固有のシグナリング プレーンを構成する方法 (利用可能なZeroMQ
ビルディング ブロックの動作プリミティブ ソケット アーキタイプ + デバイス + アプリケーション ロジックを使用して、シグナリング プレーン追加機能用の有限状態マシンまたはトランザクション エンジンを提供します)。
IPC
は、動作のないダムの O/S ベースのサービスを提供しますこれは、純粋な O/S コンテキストで理解されていれば問題ありません (つまり、「バッテリーが含まれています」は当てはまりません)。
それにもかかわらず、より高いレベルのメッセージング サポートとその他の壮大な機能 (フェア キュー、ラウンド ロビン スケジューリング、任意/すべての{ inproc:// | ipc:// | tcp:// | pqm:// | ... }
トランスポート クラスでの多重化されたトランスポートに依存しないサービス構成、ミリ秒単位で調整されたマルチチャネル ポーラー、ゼロコピー メッセージなど)ハンドオーバーやその他の多くのスマート機能) は、自分で設計/実装する必要があります (これがまさに、ZeroMQ がゲームに組み込まれた理由です。そうする必要はありませんでした。どうもありがとう、Martin SUSTRIK と Pieter HINTJENSのチーム)
このテーマの全体像を見るには>>>より多くの議論、単純なシグナリング プレーンの図、およびPieter HINTJENS の必読の本への直接リンクを使用してください。
の妹に興味がある場合はZeroMQ
、nanomsg
Martin SUSTRIK のより軽量なフレームワークをチェックしてくださいnanomsg.org >>>
。
速い、速い、最速...
最小オーバーヘッド (速度の可能性が高いと読む) ゼロコピー (効率的なオーバーヘッド回避と読む) のインスピレーションについては、inproc://
スレッド間メッセージングのトランスポート クラスについて読んでください。
IPC
。IPC
それ自体がトランスポートクラスです。再ラップ/アライン/アセンブル/CRC/カプセル化/ディスパッチ|デコード\CRC-再チェック\デマップ...の必要はありません... 生データIPC
をより高い抽象化パケットに -チャネルを介してプロセスTCP
間で直接転送される場合、それは...ですか?localhost
IPC
ZeroMQ のようなメッセージ キューを使用すると、複数のマシンにスケールアウトできますが、子プロセスの通信はローカルのみであり、そのマシンのハードウェアを利用するためにのみスケールアウトできます。
メッセージブローカーを持つと、子プロセス通信がパイプまたは標準 I/O を使用する TCP に依存するため、遅くなります。TCP とネットワーク スタックのオーバーヘッドが回避されるため、どちらの方が高速です。ここでの速度の利点は、特に複数のマシンへのスケールアウトを計画している場合は無視できると思います.
また、ZeroMQ は unix_sockets を使用でき、child_process
コア モジュールによって提供されるものとほぼ同様の他の形式の IPC を提供することも注目に値します。それはおそらくもっと使いにくいでしょうが。
おそらく、複数のマシンにまたがるスケールアウトが必要になるまで、ZeroMQ を unix_sockets またはパイプで使用することは悪い考えではないでしょう。