feat: RedisServerAffinity RFC: Lock one document to one server

[mattkrick]

Follow-up to #983

Yes, in general the way to go is make sure that users working on the same document are connected to the same server
#983 (comment)

This extension guarantees that 1 document is only open on a single server at any given time. If a client attempts to access a document that is already opened on a different server, their messages get proxied to that server via Redis.

If a server needs to lock a document (e.g. before calling openDirectConnection), it can call the lockDocument method. Alternatively, it may use this extension like an event emitter that emits to the owning server via customEvents and the handleEvent method.

May be of interest to @0xb4lamx @janthurau

[mattkrick]

@janthurau would love some feedback if this is something you'd consider

[janthurau]

Hi @mattkrick, sorry for the long silence.

We don't have any real issues (even on really large instances with 100k connections) with documents being open on multiple servers, apart from the known fact that it creates the cpu / memory load multiple times. I am not sure if proxying solves all issues or even creates some new ones, because if you load-balance with different regions to keep latency short, proxying to another region would even increase latency. I had a concept of just maintaining the cluster somehow and then creating a.collab.yourdomain.com, b.collab.yourdomain.com, etc. which each routes to a single instance. If a request comes in at the "wrong" instance, it could return a 301 to the new hostname. However, this is more complex to maintain and also has the same latency issue.

Are you currently running this in production? Do you face issues without / with it?

Right now I think this is nothing that I want to maintain :) Obviously feel free to publish the extension and we can link to it from the README.

[mattkrick]

Wow! If it's working with 100k connections, then I completely understand not wanting to change strategies.
For us, we were constantly seeing high CPU & memory + lock contention across a high availability (3 server) deployment with < 100 active users, albeit the documents were being concurrently edited by a few dozen users.

We're currently running this in production both in a cloud SaaS (~10k active connections) as well as a handful of airgapped HA deployments and it's worked well!