Thanks for your reply~


There are two points I will briefly explain:



1.In addition to the problem of not being able to obtain the latest routing 
data of the topic in time, it also faces the following problems:

If the client frequently accesses a topic that does not exist, the path of each 
access will become lengthy and require two network requests

send request to nameServer to get topic route data

send default topic TBW102 request to nameServer

In some applications, the client will access many topics. After these topics 
are accessed once, they may no longer be accessed or very infrequent, but the 
client will still pull routing information from the NameServer each time during 
round-robin training, which increases network overhead. Zombie Topic also 
occupies more memory

Related issues

https://github.com/apache/rocketmq/issues/3207

https://github.com/apache/rocketmq/issues/3858

https://github.com/apache/rocketmq/issues/3870



2.The purpose of this modification is to supplement the current rotation 
training strategy, and the notification strategy will be adjusted according to 
the busy degree of the machine. Therefore, this complexity will not bring 
stability pressure






????????????



??????????????????????



1??????????????client????????????Topic????????????????????????????????

Client????????????????????????Topic??????????????????Topic??????????????????????????????????????????????????????????

send request to nameServer to get topic route data

send default topic TBW102 request to nameServer

?????????????????????????? Topic?????? Topic 
?????????????????????????????????????????? client ???????????????????????? 
NameServer ?????????????????????????????????????? Topic ??????????????

????????????issues??

https://github.com/apache/rocketmq/issues/3207

https://github.com/apache/rocketmq/issues/3858

https://github.com/apache/rocketmq/issues/3870




2????????????????????????????????????????????????????????????????????????????????????????????????load????????????????????????????????????????????????????????????







------------------ ???????? ------------------
??????:                                                                         
                                               "dev"                            
                                                        
<[email protected]&gt;;
????????:&nbsp;2022??3??2??(??????) ????9:00
??????:&nbsp;"dev"<[email protected]&gt;;

????:&nbsp;Re: [VOTE][RIP-36] Optimize topic routing mechanism



I read the whole plan, it is beneficial for the nameserver to actively push
changes to the client, but this benefit also brings complexity. I
personally think this benefit is not very big. Unless there is a better
explanation, I will reject this proposal.

Best regards,

Xiaorui Wang ??????
Apache RocketMQ PMC Chair


xijiu <[email protected]&gt; ??2022??3??2?????? 19:42??????

&gt; Hi, RocketMQ Community,
&gt;
&gt; As discussed in the previous email, we launched a new RIP to optimize
&gt; topic routing mechanism. Now the shepherds @dongeforever and @yukon are
&gt; willing to support the RIP, so I think it is time to start an email thread
&gt; to enter the voting process.
&gt;
&gt;
&gt; The vote will be open for at least 72 hours or until a necessary number of
&gt; votes are reached.
&gt;
&gt; Please vote accordingly:
&gt;
&gt; [ ] +1 approve
&gt; [ ] +0 no opinion
&gt; [ ] -1 disapprove with the reason
&gt;
&gt;
&gt; Best Regards!
&gt; xijiu
&gt;
&gt; links:
&gt; https://shimo.im/docs/vVAXVrDNnoSrMBqm/

Reply via email to