3

クライアントからの RPC (要求/応答) タイプの要求を処理する TCP サーバーを構築しましたが、サービスがアドホック時にイベントをプッシュすることもできます。

将来拡張する必要が生じた場合、RPC は非常に簡単です。Web インフラストラクチャと同様に、ノードを追加して負荷を分散するだけです。

プッシュ メッセージをスケーリングするには、イベントにサブスクライブするクライアントが任意のサーバー上にある可能性があるため、すべてのサーバーを調整する必要があります。

私のオプションは次のとおりです。

  1. UDP マルチキャスト/ブロードキャスト (emcaster など) を使用して、すべてのサーバーにイベントをブロードキャストします。
  2. TCPを使用してサーバーを相互に完全に相互接続します
  3. すべてのイベントが送信される中央サーバー、およびすべてのワーカー サーバーがそのサーバーに接続する
  4. [3]しかし、ツリーを形成するためにいくつかのレイヤーがあります

[1] はシンプルで、おそらく最大 20 ～ 30 ノードでうまく機能するため、[1] を使用するように誘惑されます。N がノードの数である場合、N のさまざまな範囲に対する最良の戦略は何かについてコンセンサスはありますか?

4

5 に答える 5

4

zeromq ガイドを確認してください。失われたパケットを補うために udp ブロードキャストが必要な場合は、zeromq が適しています。これは、効率化のために構築された軽量のメッセージ パッシング インターフェイスです。C (ライブラリ言語) と python のイントロ ガイドは次のとおりです。

C: http://zguide.zeromq.org/page:all
Python: http://zguide.zeromq.org/py:all

サンプルは、C++、C#、CL、Erlang、F#、Felix、Haskell、Java、Objective-C、Ruby、Ada、Basic、Clojure、Go、Haxe、Node.js、ooc、Perl、Scala のラッパーにも変換されています。 、Lua、Haxe、および PHP。

- - アップデート - -

申し訳ありませんが、リンクはすべてのコード例を C から python に変更するわけではないようですが、別の言語への翻訳を入手できます...

特にプッシュ トポロジについては、zeromq で pub/sub を実装する方法に関するページがあります: http://www.zeromq.org/whitepapers:0mq-3-0-pubsub

于 2012-09-28T02:05:36.823 に答える
1

クライアントは一意に識別可能ですか? その場合、それらをさまざまなサーバーに分割し、どのサーバーに接続するか (UNIQUE_ID mod N?) のロジックを各クライアント/サーバーに統合できます。

于 2012-09-28T01:32:02.033 に答える
1

途中で、すでに発明されている車輪付きのオープン ソース ソフトウェアを使用してみてください。その時点で思いつくのは 1 つだけですが、市場には模倣品のテントが存在することは 900% 確信しています。

Redis は良い例で、スケーラブルで高速で、すでに多くのおもちゃ、プラグイン、およびクライアントがあります。ほぼ 3 行のコードで、パブリッシャー/サブスクライバーのものを実装できます。

于 2012-09-27T20:12:04.010 に答える
1

詳細を知らずに、どれが最良の戦略であるかをアドバイスするのは難しい. おそらく、各項目について考慮すべき事項をいくつかリストアップすると、役立つ場合があります。

  1. UDP ブロードキャスト

    • おっしゃる通り、これが一番実装しやすいです。
    • 制限が 20 ～ 30 ノードなのはなぜですか? その制限は要件に適合しますか? もしそうなら、それで行きます。
    • UDP ブロードキャスト メッセージは、ファイアウォールなどの NW 要素の影響を受ける可能性がありますか?

  2. 相互接続されたTCP NW

    • このオプションは、IP アドレスの一貫したリストを構成および維持するためのメンテナンスの悪夢のように思えます。
    • 特定のサーバーは、次にメッセージを送信するサーバーをどのように知るのでしょうか? このロジックは複雑になる可能性があります。

  3. 中央サーバー

    • 個人的には、これは [1.] に続く 2 番目の解決策であると考えています。
    • この中央サーバーは、メッセージの送信先を知るために非常に複雑な処理を必要とする場合があります。

  4. ツリーのある中央サーバー

    • 構成とメンテナンスの悪夢
    • 4 で述べた複雑なロジックは、このソリューションではさらに悪化します。

個人的には、それぞれの長所と短所を見て、各ソリューションが要件にどのように対処するかについても検討します。そのレッスンが決定を容易にすることを願っています。

于 2012-09-19T14:43:30.467 に答える
0

#3 - 中央サーバーを選択します。他のオプションよりもはるかに優れた拡張性があり、ルーター テーブルのように機能するように設計して、トラフィックが必要な場合にのみサーバーに生成されるようにすることができます。追加のサーバー ノードをオンザフライで追加できます。

好奇心から、どの言語でサーバーを開発しましたか?

于 2012-09-28T01:20:56.547 に答える