0

2つのノードが頻繁に通信する設定があります。ノードAには、ノードBのサービスにアクセスするための数千のプロセスがあります。2つのノード間で大量の要求と応答が発生します。2つのノードは、それぞれ独自のハードウェアサーバー上の2つの異なるサーバーで実行されます。

HTTP / 1.1、rpc：call / 4、ノードBの登録済みgen_serverに直接メッセージを送信する3つのオプションがあります。各オプションについて説明します。

HTTP / 1.1

ノードAにのようなHTTPクライアントがIbrowseあり、ノードBにのようなWebサーバーがYaws-1.95あり、Webサーバーが無制限の接続を処理でき、オペレーティングシステムの設定が調整されてyawsがすべての接続を処理できるようになっているとします。 。次に、ノードAでプロセスを作成してHTTPを使用して通信します。この場合、各メソッド呼び出しは、単一のHTTPリクエストとレスポンスを意味します。ここにはオーバーヘッドがあると思いますが、ここでオプションを評価しています。と呼ばれるerlangの組み込みメカニズムはwebtool、この種の目的のために構築される場合があります。

rpc：call / 4

ノードAからノードBに直接rpc呼び出しを行うことができます。基盤となるrpcメカニズムがどのように機能するかについてはあまり確信がありませんが、2つのerlangノードがを介して接続するnet_adm:ping/1と、作成された接続は閉じられませんが、すべてのrpc呼び出しはこのパイプを使用すると思いますリクエストを送信し、レスポンスを渡します。これで訂正してください。

ノードAからノードB

へのメッセージの送信ノードAのプロセスを作成して、登録済みのプロセスまたはノードBのプロセスのグループにメッセージを送信することができます。これもクリーンなオプションのようです。

Q1。上記のオプションのどれをお勧めしますか、そしてその理由は、2つのerlangノードが常にそれらの間で膨大な通信を行うアプリケーションの場合です。2つのerlangノードがルーターであるメッセージングシステムを想像してみてください:)？

Q2。上記の方法のうち、よりクリーンで問題が少なく、フォールトトレラント性が高いのはどれですか（つまり、この方法には単一障害点があってはならず、ノードAのすべてのプロセスがブラインドになる可能性があります）。

Q3。選択したメカニズム：フォールトトレラントまたは冗長性をさらに高めるにはどうすればよいですか？

前提条件：ノードは常に稼働しており、ダウンすることはありません。ノード間のネットワーク接続は常に利用可能で混雑していません（2つのノード専用）。オペレーティングシステムはこれら2つのノードに最大のリソースを割り当てています。

評価ありがとうございます

4

3 に答える 3

3

HTTPは間違いなく出ています。新しい接続を作成するための往復のオーバーヘッドだけが問題になります。

Erlang接続とPidの使用に関しては、ノードダウンメッセージをサブスクライブして、ノードがダウンした場合に対処できるという利点があります。単一のTCP接続で非常に高速になりますが、長いパイプのように機能することに注意してください。メッセージはパイプ上で多重化および分離され、回線の遅延に影響を与える可能性があります。また、大きなメッセージは小さなメッセージの通過をブロックすることを意味します。

どのくらいの帯域幅を目指しており、どのくらいの遅延がありますか？メッセージに応答する95パーセンタイルと99パーセンタイルはどれくらいですか？「できるだけ速く」するよりも、大まかな数字をいくつか挙げてから、それらをターゲットにすることをお勧めします。最初に成功基準を設定します。

于 2012-11-08T13:45:17.540 に答える
2

Q1：HTTPは追加のオーバーヘッドを追加し、私の意見では何も与えません。HTTPは、RESTAPIを設計する場合に役立ちます。メッセージとrpc：callを直接送信することは、オーバーヘッドが考慮される限り、ほぼ同じように見えます。

Q2：メッセージの送信がはるかに明確になりました。それがerlangの設計方法です。RPC呼び出しでは、どの呼び出しがどこでどのような状況で実行されるかを常に追跡する必要があります。これは、2つのサーバーに状態がある場合に大きな問題になる可能性があります。また、RPC呼び出しは同期的です。

Q3：わずかなオーバーヘッドがあればUBFを使用します。それ以外の場合は、erlangノード間で直接メッセージを送信します。帯域幅が問題になる場合は、他のトリックも必要になります。同じ方法でメッセージをエンコードしてから、圧縮アルゴリズムを使用してメッセージのサイズを縮小するのと同じように、代わりに、erlangメッセージの受け渡しを完全に破棄してUDPソケットを使用することもできます。

于 2012-11-08T10:08:58.370 に答える
1

それは明らかではありません！行くための最良の方法です。間違いなく、それは最も簡単で、コードは最もエレガントになります。

スケーラビリティの観点から、rpc /！を使用することを考慮してください。erlangクラスターを維持する必要があります。プライベートクラウドでもノードが10〜20個しかないのは辛いです。io /レイテンシー/ネットワークが決定論的ではないEC2などで、より大きなデプロイを推奨することは決してありません。

将来的にコミュニケーションエンジンを交換できるようにプロジェクトを構成することをお勧めします。また、HTTPはかなり重いですが、オプションがあります。

  • ソケット-ソケット（tcp / udp / sctp）
  • amqp（負荷分散に関連する多くの利点）
  • zeromq（amqpよりも優れています）

！/rpcとOTPクラスターに賭けるのは危険です。フルメッシュオーバーヘッド、マスター選挙アルゴ、クォーラム/パーティション検出で戦います。

于 2012-11-08T18:24:42.933 に答える