web-dev-qa-db-ja.com

Cソケットへの数千のメッセージを処理する方法

現在、次のような設定があります。

 __________________      _________      ________      ___________
| Front end server |----| Varnish |----| NodeJS |----| C-service |
 ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾      ‾‾‾‾‾‾‾‾‾      ‾‾‾‾‾‾‾‾      ‾‾‾‾‾‾‾‾‾‾‾

NodeJSとCサービスは同じ仮想サーバー上で実行されます。

フロントエンドサーバーには数百のクライアントが接続されている可能性があります。これらのクライアントのそれぞれがCサービスへの数百の同時要求を生成できるため、Cサービスへの要求は数千にのぼります。

以前の経験から、ソケットは待機中の接続(バックログ)の限界までしか処理できないことを知っています。これを処理するために、NodeJSにメッセージキューを実装しました(HTTPメッセージをCサービスが理解できるメッセージに変換しますが、これはCサービスで実行できるマイナーなことです)。

問題:

  • Varnishは何千ものリクエストを簡単に処理します
  • Cサービスは、キューに入れられている限り、何千もの要求に対応できます。
  • NodeJS ...それほどではありません。 (私はクラスタリングを試みましたが、他の実装の問題のため、これはオプションではありません。)

つまり、スループットを大幅に制限しているNodeJSサーバーがありますが、それだけ多くの同時要求を処理する他の方法がわかりません。

私はKafka/RabbitMQ/ZeroMQなどのメッセージブローカーを調査してきましたが、HTTPサービス(ワニス)をメッセージキューを使用して、基になるTCP/Unixドメインソケットに接続するという私の基本的な問題を処理していないようです。同期操作にも適しているかどうかはわかりません。

これは間違ったアプローチですか?他に何ができますか?

応答を同期的に送信する必要がありますが、ワニスから送信されるのと同じ順序である必要はありません(Cサービスの複数のインスタンスを実行してCPU使用率を向上させることができます。この場合、応答を順番に送信すると処理が遅くなります)。 。

5
Woodgnome

私は確かに仕事のために間違ったツールを探していたようです。まあ、多分メッセージブローカーは仕事をすることができますが、より簡単な解決策があります: HAProxy

HAProxyには、そのバックエンドサーバー用の組み込み最大接続設定があり、バックエンドサーバーが応答できるまでメッセージをキューに入れます。また、Unixドメインソケットへの接続もサポートしています(バージョン1.5以降)。

バックエンドサーバー定義にmaxconn [limit]を追加します。次に例を示します。

backend backend-server
    server backend 127.0.0.1:8080 maxconn 5

何千もの着信リクエストをサポートするには、configのmaxconnセクションとglobalセクションの両方にfrontendを追加する必要があるようです。次に例を示します。

global
    maxconn 10000

frontend http-in
    bind *:80
    maxconn 10000
0
Woodgnome

C側では、 mq のようなメッセージライブラリの使用を検討できます。

[〜#〜] jsonrpc [〜#〜] または [〜#〜] json [〜#〜] ライブラリ jansson (おそらく上記で使用される0mq...)、それは node.js がJSONフレンドリーである可能性が高いためです。