Socket.io/node.jsとredis pub/subを結合して、複数のトランスポートを処理できるサーバーイベントによって駆動されるリアルタイムWebブロードキャストシステムを作成しようとすると、3つのアプローチがあるようです。
'createClient'はredis接続を作成し、チャンネルをサブスクライブします。 socket.ioクライアント接続で、クライアントをsocket.ioルームに参加させます。 redis.on( "message"、...)イベントで、io.sockets.in(room).emit( "event"、data)を呼び出して、関連する部屋のすべてのクライアントに配信します。 socket.ioでredis接続を再利用する方法
「createClient」redis接続。 socket.ioクライアント接続で、クライアントをsocket.ioルームに参加させ、関連するredisチャネルにサブスクライブします。 redis.on( "message"、...)をクライアント接続のクロージャ内に組み込み、メッセージの受信時にclient.emit( "event"、data)を呼び出して、特定のクライアントでイベントを発生させます。 socket.ioでRedisStoreを使用する例 の回答のように
Socket.specプロトコルに従って、Redisの単一の「ディスパッチ」チャネルからsocket.ioにベイクされたRedisStoreと「ブロードキャスト」を使用します。
番号1では、すべてのクライアントに対してRedisサブと関連イベントを1回処理できます。番号2は、Redisのpub/subへのより直接的なフックを提供します。番号3は簡単ですが、メッセージングイベントをほとんど制御できません。
ただし、私のテストでは、すべてが1つ以上の接続クライアントで予想外に低いパフォーマンスを示しています。問題のサーバーイベントは、できるだけ早くredisチャネルに発行される1,000のメッセージであり、できるだけ早く配信されます。パフォーマンスは、接続されたクライアントでのタイミングによって測定されます(socket.io-clientは分析のためにRedisリストにタイムスタンプを記録します)。
私が推測するのは、オプション1でサーバーがメッセージを受信し、接続されているすべてのクライアントにメッセージを順番に書き込むことです。オプション2では、サーバーは各メッセージを複数回(クライアントサブスクリプションごとに1回)受信し、関連するクライアントに書き込みます。いずれの場合も、サーバーは、接続されているすべてのクライアントに通信されるまで、2番目のメッセージイベントに到達しません。並行性の増加により状況は明らかに悪化しました。
これは、スタック機能の知恵とは相反するようです。信じたいのですが、苦労しています。
このシナリオ(大量のメッセージの低遅延配信)は、これらのツールのオプションではありませんか(まだですか?)、またはトリックがありませんか?
これは妥当な質問だと思い、しばらく前に簡単に調査しました。役に立つヒントを見つけることができるかもしれない例を探すのに少し時間を費やしました。
私は簡単な例から始めるのが好きです:
ライトサンプルは1ページです(redis-node-clientを node_redis Matt Ranneyのようなものに置き換えてください:
/*
* Mclarens Bar: Redis based Instant Messaging
* Nikhil Marathe - 22/04/2010
* A simple example of an IM client implemented using
* Redis PUB/SUB commands so that all the communication
* is offloaded to Redis, and the node.js code only
* handles command interpretation,presentation and subscribing.
*
* Requires redis-node-client and a recent version of Redis
* http://code.google.com/p/redis
* http://github.com/fictorial/redis-node-client
*
* Start the server then telnet to port 8000
* Register with NICK <nick>, use WHO to see others
* Use TALKTO <nick> to initiate a chat. Send a message
* using MSG <nick> <msg>. Note its important to do a
* TALKTO so that both sides are listening. Use STOP <nick>
* to stop talking to someone, and QUIT to exit.
*
* This code is in the public domain.
*/
var redis = require('./redis-node-client/lib/redis-client');
var sys = require('sys');
var net = require('net');
var server = net.createServer(function(stream) {
var sub; // redis connection
var pub;
var registered = false;
var nick = "";
function channel(a,b) {
return [a,b].sort().join(':');
}
function shareTable(other) {
sys.debug(nick + ": Subscribing to "+channel(nick,other));
sub.subscribeTo(channel(nick,other), function(channel, message) {
var str = message.toString();
var sender = str.slice(0, str.indexOf(':'));
if( sender != nick )
stream.write("[" + sender + "] " + str.substr(str.indexOf(':')+1) + "\n");
});
}
function leaveTable(other) {
sub.unsubscribeFrom(channel(nick,other), function(err) {
stream.write("Stopped talking to " + other+ "\n");
});
}
stream.addListener("connect", function() {
sub = redis.createClient();
pub = redis.createClient();
});
stream.addListener("data", function(data) {
if( !registered ) {
var msg = data.toString().match(/^NICK (\w*)/);
if(msg) {
stream.write("SERVER: Hi " + msg[1] + "\n");
pub.sadd('mclarens:inside', msg[1], function(err) {
if(err) {
stream.end();
}
registered = true;
nick = msg[1];
// server messages
sub.subscribeTo( nick + ":info", function(nick, message) {
var m = message.toString().split(' ');
var cmd = m[0];
var who = m[1];
if( cmd == "start" ) {
stream.write( who + " is now talking to you\n");
shareTable(who);
}
else if( cmd == "stop" ) {
stream.write( who + " stopped talking to you\n");
leaveTable(who);
}
});
});
}
else {
stream.write("Please register with NICK <nickname>\n");
}
return;
}
var fragments = data.toString().replace('\r\n', '').split(' ');
switch(fragments[0]) {
case 'TALKTO':
pub.publish(fragments[1]+":info", "start " + nick, function(a,b) {
});
shareTable(fragments[1]);
break;
case 'MSG':
pub.publish(channel(nick, fragments[1]),
nick + ':' +fragments.slice(2).join(' '),
function(err, reply) {
if(err) {
stream.write("ERROR!");
}
});
break;
case 'WHO':
pub.smembers('mclarens:inside', function(err, users) {
stream.write("Online:\n" + users.join('\n') + "\n");
});
break;
case 'STOP':
leaveTable(fragments[1]);
pub.publish(fragments[1]+":info", "stop " + nick, function() {});
break;
case 'QUIT':
stream.end();
break;
}
});
stream.addListener("end", function() {
pub.publish(nick, nick + " is offline");
pub.srem('mclarens:inside', nick, function(err) {
if(err) {
sys.debug("Could not remove client");
}
});
});
});
server.listen(8000, "localhost");
ドキュメントは山ほどあり、APIはこのタイプのスタックで急速に変化しているため、各ドキュメントの時間関連性を検討する必要があります。
いくつかの関連する質問、これはスタックのホットトピックです。
ソケットプーリングをオフにするか最適化し、効率的なバインディングを使用し、レイテンシを監視し、作業を重複させないようにします(つまり、すべてのリスナーに2回公開する必要はありません)。