drpmma commented on issue #5690:
URL: https://github.com/apache/rocketmq/issues/5690#issuecomment-1345983603
The queue mapping idea had been considered before, but it's not easy to
maintain the queue mapping rule.
First of all, the storage of queue mapping rules is a problem. If it's
stored in the broker, then the broker needs to be upgraded. So let's suppose
the proxy maintains the queue mapping relationship in memory.
Let's take your example, there is a topic TopicTest, which contains
broker-a{0,1,2,3} and broker-b{0,1,2,3} are mapping to
broker-gateway{0,1,2,3,4,5,6,7}.
How does proxy deal with the case that the broker-a{0,1,2,3} scale to
broker-a{0,1,2,3,4,5,6,7}? If the mapping is append-only, which means {
broker-a{0,1,2,3}, broker-b{0,1,2,3}, broker-a{4,5,6,7} }, the rule will be
different and inconsistent when proxy restart. If the mapping is {
broker-a{0,1,2,3,4,5,6,7}, broker-b{0,1,2,3} }, then the specified mapping will
be changed and cause inconsistent pull behavior.
If the mapping rules are stored in the broker or even other storage like a
database. The brokers' scale or offline behavior will also be a big challenge
in maintaining the rules which need be correct when broker scale or offline.
So IMO, supporting the new version client is the simplest way to keep the
original protocol semantics.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
