corvus
corvus copied to clipboard
eleme
pub/sub cmd
Is there any plan on this kind of commands supporting? They are available when a redis node is in a cluster.
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.
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)
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.
@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.
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.
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.