描述
Currently SS multiplexes all events over a single redis channel. If an app were to scale large enough, it's easily possible for 100,000's of messages to be sprayed to every SS instance - taking up bandwidth and burdening the local SS instance with determining if each message should be propagated locally or not.
I spent a few hours today creating a version of the Redis publish transport that properly uses Redis' pub/sub to route messages only to the servers that can use them. Hopefully this will allow more flexibility when it's necessary to scale Redis.
I modified two files:
src/publish/transports/redis.coffee
src/utils/unique_set.coffee
Since it's more of a working proof-of-concept rather than something that's pull-able, here's a gist of the files: https://gist.github.com/2779421
I've done very basic testing and everything works as expected with multiple clients connected to several SS servers and a common Redis server. There may be a little bit of leaking where redis channels associated with socketIDs may not be unsubscribed when the socket disconnects. I didn't see it happening via MONITOR, but if they're ever removed from the unique_set, then the events should fire and the channel for the socketId will be unsubscribed.