Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
Description
our current implementation of Publish and Subscribe use a list of Subscription objects to maintain state.
@doevans noticed that native redis is using 2 maps to maintain state
in an effort to mimic native redis data structures and hopefully improve performance, our publish and subscribe commands should also use maps 1) (channel -> all subscribers). 2) subsrciber(client) -> all subscribed channels
Updated 08/20/2021:
Redis handles subscriptions as follows:
- Each client object maintains a set of channels to which it is subscribed
- Each client object maintains a list of patterns to which it is subscribed
- The server maintains a map of channels -> subscribed clients
- The server maintains a list of all Pattern objects
- Each Pattern object knows which client is subscribed to it and the byte[] pattern associated with it
On subscribe:
- Add the channel to the client's set of subscribed clients
- Add the channel to the server's map of channels -> subscribed clients
- Respond with the total number of subscribed channels and patterns for the client (sum the sizes of the client's channel set and pattern list)
On psubscribe:
- Add the byte[] pattern to the client's list of patterns
- Create a Pattern object and add it to the server's list of Patterns
- Respond with the total number of subscribed channels and patterns for the client (sum the sizes of the client's channel set and pattern list)
On publish:
- Notify all clients subscribed to the channel using the server's channels -> subscribed clients map
- Notify all clients subscribed to matching channels by comparing the channel to the server's list of all patterns using Glob-style matching
- Respond with the number of notifications sent
For our implementation, a similar approach can be used, but this will entail significant refactoring of PubSub classes
Attachments
Issue Links
- links to