Skip to content

[FEATURE] Keyspace based pubsub #8029

@madolson

Description

@madolson

What’s the problem?
The current pubsub implementation works poorly with Redis key space functionality since it was built to exist in its own space. The two notable problems I’ve see are ACLs (#7923) and cluster scaling (#2672). I saw suggestions that were very tactical, but I think it’s really a fundamental problem with how the API was designed that should be addressed. I propose we implement a new type of publish mechanism that directly and explicitly maps to a key. New commands:

Kpublish key-channel message, publish to a channel key space and optionally a sub channel. Drop in replacement for publish if you already use that.
Ksubscribe key-channel [key-channel] …
Kunsubscribe key-channel [key-channel] …

Publishing will only be accepted on masters, and replicated normally to replicas, this prevents having two separate mechanisms for replicating the data for cluster mode/cluster disabled. It will not be propagated throughout the cluster, but will do validation to make sure the command was sent to the right shard.

Is this really a key? No, it shouldn’t be a key because:

  1. It has no internal state, you can’t touch it, miss it, look it up, etc.
  2. Replicas would need to set the state to subscribe, which can cause divergence if we blocked an incoming write on it.
  3. How do you copy/move/rename something with no state.

But, we need to treat it kind of like a key for cluster mode, namely:

  1. On migration, we need to disconnect all the clients using it.
  2. Send re-directions when trying to publish/subscribe to the wrong shard.
  3. As a side effect, ACLs can also applied to the channel key normally.

Notable limitations:

  1. Invalidations and key space notifications can’t be migrated, since they rely on the notation that channels are entities of the cluster. Publish messages are still emitted locally in those cases too, so the problem is really just ACLs.
  2. Patterns are intentionally omitted, since I think they’re very inefficient and scale poorly. If you still want them, you have to use the old mechanism.

We could also solve the issues with pubsub individually, but I think we should kind of ignore the old mechanism and move to a more forward thinking mechanism. I just wanted to post this thought here for feedback.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions