1

ほとんどの Websocket エンジンを試してみた結果、Primus (リアルタイム フレームワークのユニバーサル ラッパー) を使用して、機能を変更せずに Websocket フレームワークをテストできるようにするのが最善の方法であると結論付けました。

そのプリムスはそれが言うことをしますが、私は自分がスケールしたい状況にいることに気づきました.

Primus には多くのプラグインがあり、そのうちの 2 つは primus-cluster と primus-redis-rooms です。これら 2 つは、多数のノード プロセスがある場合にスケーリングするために Redis pub-sub を使用するものです。私が両方のプラグインで直面した問題は、メッセージを個々のソケット - spark に送信できないことです。つまり、スパークは保存されず、Redis に渡されるため、各プロセスはスパークの合計数を認識します。

誰もこれを実装する方法について考えを持っていますか?

4

1 に答える 1

1

primus-redis ルームと primus-redis ルームの問題は、ブロードキャストのみを実装し、1 つのサーバーからではなく、別のサーバーのメッセージングでスパークを実装することです。

あなたが提案する部屋のハックは「OK」の代替手段ですが、それは間違いなくハックであり、多くのオーバーヘッドを提供します。次のようなプラグインを作成するのはそれほど難しいことではないと思います。

  • 受け入れる接続ごとに、spark.id を redis (spark.id -> サーバーアドレス) に追加します。
  • 接続が切断されたときに、spark.id を redis から削除します。
  • メッセージを受信できるように、サーバーの pub/sub チャネル (サーバー アドレス) を追加します。
  • このチャネルで spark.ids を使用してメッセージをリッスンし、Primus サーバーでスパークを見つけてメッセージを書き込みます。
  • redis で spark.id を見つけるメソッドを作成して、サーバー アドレスを認識し、spark.id と一緒に書き込む必要があるメッセージでチャネルに PUBLISH を実行します。
  • モジュールを npm に公開して、たくさんの無料のビールを受け取りましょう ;-)

あなたが提案したハックよりも書くのに少し時間がかかるかもしれませんが、おそらく努力する価値があるでしょう.

于 2014-06-02T11:41:36.580 に答える