Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pub/sub cmd #122

Open
jasonjoo2010 opened this issue Apr 6, 2017 · 6 comments
Open

pub/sub cmd #122

jasonjoo2010 opened this issue Apr 6, 2017 · 6 comments

Comments

@jasonjoo2010
Copy link
Contributor

Is there any plan on this kind of commands supporting?
They are available when a redis node is in a cluster.

@doyoubi
Copy link
Contributor

doyoubi commented Apr 7, 2017

I think it's not appropriate to use corvus as a pub-sub middleware.
Corvus is just a stateless redis cluster protocol proxy which shouldn't maintain the state in pub-sub.
For availability consideration, we should use multiple corvus for a single redis cluster with something like haproxy for load balancing of corvus. If a client publish some messages to one corvus, or a corvus receive some published messages from redis cluster, this corvus should be able to notify others in order to push the messages to all clients. This violates the current design.

@jasonjoo2010
Copy link
Contributor Author

The implementation of pub/sub in cluster mode is node-equal. So the msg would be received through any connection to any node of the cluster by publishing it to any node of the cluster. So the mainly function is just like a plugin which it should not effect the performance of normal function. And it could keep stateless.

The purpose of the feature is that we may use HA or lvs to connect to any node of the real cluster to use the pub/sub commands. It is separated from normal operations for clients. So i think whether it is possible to support it in proxy. (PSUB is not in the collection)

@doyoubi
Copy link
Contributor

doyoubi commented Apr 7, 2017

Oh, sorry for not understanding the pub/sub in cluster mode properly.
From my understanding, it's not just a plugin. Now we parse each response from redis for their corresponding request. But SUBSCRIBE is different, it has only one request but receives multiple response.
Now corvus use only one connection to redis for each thread. To implement SUBSCRIBE, we should be able to distinguish whether the response is from SUBSCRIBE or to use a separate connection for each client using SUBSCRIBE.

@jasonjoo2010
Copy link
Contributor Author

@doyoubi
Thanks for responding.

So whether there is a possible plan or just a plan to add it into?
We are planning to add it into our branch in production. We can put a PR when we have finished and tested if so.

@doyoubi
Copy link
Contributor

doyoubi commented Apr 7, 2017

We just use corvus and redis cluster as a cache system and want to keep them simple, so we are not going to add this.
And I still don't recommand using corvus this way. Forwarding SUBSCRIBE and other commands are almost completely different.

@jasonjoo2010
Copy link
Contributor Author

Yes, it's different. So we should keep this kind of connections separately.

Maybe we should get some results first and let's discuss it later if it's really quite simple.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants