动态新增namesrv节点，导致客户端消息发送失败，No route info of this topic

[Silencesk]

背景

• rocketmq：4.9.4，master-slave架构部署
• 在客户端Producer使用WSAddr（rocketmq.namesrv.domain/rocketmq.namesrv.domain.subgroup）来进行namesrv地址的动态刷新，这样可以发现新增的namesrv节点
• 客户端Producer以2000 tps发送消息
• namesrv节点node1、node2。需要增加一个node3节点，并且要将node1移除

问题

• 当我新增node3、并且移除掉node1之后
• 此时Producer出现了消息发送失败，异常为 No route info of this topic

原因

• 排查过程中，发现在我新增node3、并且移除掉node1之后，正在运行的Producer连接的namesrv节点为node3，即连接到了新增的namesrv节点
• 同时观测到topic route info changed信息
  2023-10-11 11:01:29.839 INFO [] [Share_MQClientFactoryScheduledThread_1] RocketmqClient 100: the topic[dev%fake-topic] route info changed, old[TopicRouteData [orderTopicConf=null, queueDatas=[QueueData [brokerName=dev%dev, readQueueNums=4, writeQueueNums=4, perm=6, topicSysFlag=0]], brokerDatas=[BrokerData [brokerName=dev%dev, brokerAddrs={0=10.1.1.1:10911, 405=10.1.1.2:10911}]], filterServerTable={}]] ,new[TopicRouteData [orderTopicConf=null, queueDatas=[QueueData [brokerName=dev%dev, readQueueNums=4, writeQueueNums=4, perm=6, topicSysFlag=0]], brokerDatas=[BrokerData [brokerName=sz-sk%dev%dev, brokerAddrs={405=10.1.1.2:10911}]], filterServerTable={}]]
• 从路由变更日志可以看到，新的route info只有broker从节点（405=10.1.1.2:10911），并没有broker主节点（0=10.1.1.1:10911）
• 这意味着，在从新增node3获取路由时，broker master还没有成功注册到namesrv，但slave已经注册了
• 客户端路由信息比对，是认为发生变化的，便进行了路由信息替换，此时的路由信息实际上是不可用的，因为就只有从节点
• 最终导致了消息发送失败，影响可用性

建议

考虑增强客户端Producer现有路由信息的推空保护能力

• 目前rocketmq-client定时更新topic route info逻辑，有对从namesrv返回null值做特别处理，但对于上述无主节点broker的topic并没有保护措施
• 可以考虑对namesrv返回的topicRouteData再做一次校验，如果发现topicRoute为无效数据（验证是否存在有效的messageQueue），则不进行替换，只作用到Producer。

如果该建议被采纳，我会提交PR。

[cserwen]

确实存在这种场景，由于 broker 定时向namesrv上报路由，namesrv重启或者刚上线时都有可能出现上述的case。

能否在namesrv进行优化，比如一个namesrv刚启动30s内不提供服务，对于客户端的请求全部拒绝，待30s后（路由全部注册）再响应请求，这样不需要推动客户端升级，比较省时省力。

[Silencesk]

谢谢你的回答，且赞同你的观点。

我们可以尝试优先在namesrv进行优化

• 关于你提到增加服务就绪状态控制的处理思路，我看到社区已经有提交PR，see [improving SDK topic route availability]。
• 这种处理方式基本上已经可以解决重启或刚上线时的路由可用性问题
• 但如果broker或者客户端都是通过WSAddr进行动态发现namesrv地址这个场景时，这种处理逻辑可能并不好使
• 新的namsrv节点被发现最坏情况下需要2min钟，因默认是每2min钟进行一次namerv地址更新
• 如果仅通过指定一个延时时间（启动后30s）来判定namesrv不可用，那为了兼容上述场景，可能就需要设置一个较长值比如（2min+1.5*30s=2min45s），即namesrv在上线后需要2min45s之后才能正常提供客户端路由服务，这对于namesrv集群第1个节点提供服务时很不友好
• 感觉除了最短服务就绪时间外，仍需要其他机制去交叉验证当前namesrv服务就绪的时机，这样也能保证namesrv路由服务就绪的时效性
• 请帮忙再想想^_^

再回到客户端侧

• 通过控制namesrv服务就绪之后，理论上已经可以做到路由信息的有效性了，但仍有可能存在一些其他未知情况。客户端做个兜底保护会更稳妥
• 所以客户端进行路由信息可用性的校验保护，仍有必要

[figuewang]

一般做这种操作前，系统先停机最好

[gaoyf]

先增加node3，2分钟后，再移除node1，按照这个顺序不会有问题的，因为默认客户端只跟一个ns节点通信，新增的节点对客户端没影响。
一直这么操作的，很多年一直没遇见过你说的问题，俗话说约定大于配置，其实经验大于代码。
但我并没有否认你说的这个问题哈，如果ns或broker甚至proxy，controller等组件随随便便的就加减或启停节点，那么势必会有很多防御性代码，复杂性和可维护性需要权衡。