Finalize Redis scaleout design and implementation

[muratg]

No description provided.

[muratg]

@davidfowl @mikaelm12 @moozzyk @BrennanConroy we'll need a design meeting.

[davidfowl]

The current redis design is optimized for to have a single connection per server and a minimal number of connections per subscription. This means that we have:

• A subscription per connection
• A subscription per user id
• A subscription per hub
• A subscription per group

A few things that are implemented but need to be solidified:

• Today we use JSON serialization (with type name handling) as the internal format to pass data between servers. Should we pick something more efficient?
• We don't support reconnecting to redis. Do we queue if the connection dies and data is sent or should we fail?
• We need to support adding connections to groups for connection that don't exist on the local server.
• Today we always publish through redis even if the connection is on the local machine, we don't need to do this any more since we require stickiness.

[abergs]

since we require stickiness.

Do you mean that the client connection is required to be sticky (e.g. when load balancing several front end servers)? @davidfowl

[abergs]

Just watched the NDC London video, i now understand what you mean with stickiness @davidfowl

[muratg]

We plan to do #584 in alpha.

[ThatRendle]

I was all set to go "WHAT? STICKINESS?" but then I checked whether you can do that running in a Docker Swarm with the Traefik LB/proxy, and it turns out you absolutely can, so OK, as you were.

[moozzyk]

@markrendle - try long polling.

[BrennanConroy]

A few things that are implemented but need to be solidified:

• Today we use JSON serialization (with type name handling) as the internal format to pass data between servers. Should we pick something more efficient?
• We don't support reconnecting to redis. Do we queue if the connection dies and data is sent or should we fail?
• We need to support adding connections to groups for connection that don't exist on the local server.
• Today we always publish through redis even if the connection is on the local machine, we don't need to do this any more since we require stickiness.

• Reconnecting is enabled by default now, we don't do anything special so if you lose connection and try to publish then it will throw from your invocation. And when you reconnect publishes work again.
• Adding connections to groups for connections that don't exist on the local server is supported, and waits for an ACK before completing.
• We have to publish through redis in all scenarios except when invoking on a specific connection that is on the local server and when adding or removing a local connection from a group, we handle those scenarios.

[davidfowl]

Today we use JSON serialization (with type name handling) as the internal format to pass data between servers. Should we pick something more efficient?

I think this is the last thing we need to look over before closing this issue. Everything else looks good. We should do some initial performance work to see what a certain application scenarios look like with redis (many groups, many connections, etc).

[muratg]

Closing per triage. This is done.