We are using socket i/o for lots of live data. User sends/receive the data using sockets. As we are using load balancer, we cannot use socket i/o's namespace model and instead using redis' pub/sub within socket.
Till now, we were creating a separate redis conection for subscription per user per channel. But recently we faced an issue that of max connection reached (Error: Ready check failed: ERR max number of clients reached) on redis and we figured out that it is because of having too many redis connections through pub sub.
To counter that, it occurred to me that instead of using multiple subscribe redis connections per user, why not have a one publish redis connection and one subscribe redis connection which will listen to all channels and can be achieved by:
var pub = redis.createClient();
var sub = redis.createClient();
sub.psubscribe('*');
sub will listen to all channels. Also, we can store information about channels to which user is subscribe in socket object and handle data accordingly.
Hopefully, I am clear with the problem statement and would like to understand how will be the performance using this design pattern?
Performance-wise it is much better to use a single connection, it's much less stress on the redis-server and when publishing data, it won't have to loop through all the connections. The "pattern" does create some overhead but it's very negligible, make sure to be more specific about your patterns, you might be publishing other event on that server in the future.
sub.psubscribe('someprefix_*');
By the way, if your problem is broadcasting to socket.io within the context of multiple NodeJS instances, you could check out this module: https://github.com/socketio/socket.io-redis
It leverages redis to provide a scale,multi-node experience with socket.io