Add custom Redis socket.io adapter

[GaryWilber]

Alfred currently uses the socket.io-redis adapter for fluid operation pubsub. Each socket.io server (Alfred) subscribes to a Redis pattern subscription called "socketio#/fluid#*”. For every op, the broadcaster lambda publishes messages to a topic that looks like “socketio#/fluid#{tenantId}/{documentId}#op”.

This means that a single broadcast will be received by every single machine that subscribed for socketio#/fluid#*. If we have a region with 100 instances of Alfred and have 2 users connected to the same document on 2 different machines, their ops will be received by 98 other Alfred’s – this is terrible when horizontally scaling the service. It also has a significant impact on the performance of Redis.

This custom adapter introduces a subscription per “room” (tenant/document id pair). This means that in the above scenario with 100 instances and 2 clients connected to a document, their ops would only be broadcasted to the 2 Alfred instances that actually had clients connected for that document.

Differences between this and socket.io-redis:

• Creates per room subscriptions which significantly reduces Redis server load for Fluid scenarios when running a large amount of fluid frontend servers.
• Contains a health checker that verifies each room is works
• Disables rooms for the default "/" namespace to reduce memory usage (Connecting to custom namespace connects to default namespace, too socketio/socket.io#3089)
• Callbacks for telemetry logging

This PR only adds the implementation for this new socket.io adapter. It does not integrate it into Alfred's socket.io server. That will be done in a separate PR.

References:

• https://github.com/socketio/socket.io-redis
• https://github.com/socketio/socket.io-emitter
• https://github.com/socketio/socket.io-adapter

[hedasilv]

It looks like queueRoomHealthCheck() calls runRoomHealthCheck(), which in turn calls queueRoomHealthCheck() again - it looks recursive. If that's the case, is there any chance the recursion never ends and we run out of resources or something similar? Apologies if I'm missing something obvious :)

[GaryWilber]

It is recursive but it will eventually end. When all clients leave a room, it triggers an unsubscribe call for that channel. And so the queueRoomHealthCheck method will stop because RedisSocketIoAdapter.options.subConnection.isSubscribed(room) will return false