This repository was archived by the owner on Apr 26, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Lay some foundation work to allow workers to only subscribe to some kinds of messages, reducing replication traffic. #12672
Merged
Merged
Changes from 1 commit
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
7467a56
Listen to more Redis channels so we can split up traffic later
reivilibre f7ee5a8
Test that we listen to the right channels on the right workers (for now)
reivilibre 25698fa
Newsfile
reivilibre f97cf42
Skip Redis test if Redis not installed
reivilibre 4bc2ab1
Add channel support to Fake Redis
reivilibre cfa55ed
Restructure RedisSubscriber and the factory
reivilibre 33702fa
Restructure the way we subscribe to channels
reivilibre 15c08e5
Migrate tests to new way of doing things
reivilibre 55c9efe
Skip tests if no Redis
reivilibre 3b0a1d0
Remove obsolete file
reivilibre 8f362fb
Fix comments
reivilibre 79983c9
Fix up the Redis tests
reivilibre File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a huge fan of hardcoding the list of streams here. Can we either:
RDATA
on the main channel for now; orRDATA/*
and usePSUBSCRIBE
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd prefer this (mind you, it's still transmitting on the main channel). How do you suggest this work without specifying a list of streams here?
I guess we could have them be subscribed on-demand somewhere else, but I was sort of keen to subscribe them all in one place to be sure we're not sending
REPLICATE
before we are listening on all the desired channels.I am somewhat reluctant to do this because it's not really sorting us out to be able to unsubscribe from select streams in the future (and not to mention that it seems like it's more work for Redis to do pattern matches on each receiver rather than having a concrete set of listeners per channel; not sure how it's implemented in practice though).
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sort of depends on what we want the final code to look like. One option that I've been considering is have it so that every handler that wants to listen to a stream has to call something like
ReplicationSubscriber.subscribe_to_stream(Stream.NAME, func)
in the handler's__init__
. Then, when we come to connect to Redis theReplicationSubscriber
has the list of streams the worker is interested in.What I really want to avoid is to have to manually list these stream names, its a recipe for it getting out of date and its very non-obvious how it all fits together.
Using
PSUBSCRIBE
would allow us to set up the channels and write to those channels before putting all the logic in for doingReplicationSubscriber
. OTOH, you could implement theReplicationSubscriber
logic before adding the streamsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll give that a go. Otherwise it may be worth cutting out any mention of RDATA in this PR and leaving that rewiring for another PR.
yeees. That can be said about much of the replication stuff, I don't want to make it much worse though, so will give this a try
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool. I think its worth time boxing the RDATA stuff, as just getting the
UserIP
stuff split out will provide a bunch of value.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've de-scoped the RDATA stuff a bit for now (mostly because I'd appreciate a few thoughts on where exactly to hook it in; the code processing RDATA commands is a bit convoluted and I thought it was going to take a while to untangle), but I've restructured things in a way that I think makes it a bit more approachable to do cleanly.