從 gRPC 端口到 Topic 配置的完整踩坑實(shí)錄

關(guān)鍵詞：RocketMQ 5.x、Spring Boot、gRPC、Producer FAILED、No topic route info
適用版本：RocketMQ 5.3.x + rocketmq-client-java 5.x

一、問(wèn)題背景

在使用 RocketMQ 5.3.3 搭配 Spring Boot 開(kāi)發(fā)消息生產(chǎn)者時(shí)，服務(wù)啟動(dòng)正常、控制臺(tái)可訪問(wèn)、Topic 也“看似”已經(jīng)創(chuàng)建，但在真正發(fā)送消息時(shí)卻頻繁失敗，典型報(bào)錯(cuò)如下：

Expected the service ProducerImpl-0 [FAILED] to be RUNNING

或：

No topic route info in name server for the topic: rewre

更讓人困惑的是：

• RocketMQ Console 可以正常訪問(wèn)
• NameServer 和 Broker 都已啟動(dòng)
• Topic 在控制臺(tái)里“存在”
• Producer 代碼沒(méi)有明顯錯(cuò)誤

但消息就是發(fā)不出去。

本文將完整復(fù)盤這個(gè)問(wèn)題，并給出 RocketMQ 5.x 下的正確使用姿勢(shì)。

二、RocketMQ 5.x 與 4.x 的本質(zhì)差異（很多坑從這里開(kāi)始）

1?? 通信協(xié)議發(fā)生了根本變化

?? RocketMQ 5.x 的 Java Client 完全基于 gRPC

這意味著：

• NameServer
• Broker
• Client（Producer / Consumer）

三者之間必須能通過(guò) gRPC 端口通信

2?? RocketMQ 5.x 新增的關(guān)鍵端口

以 RocketMQ 5.3.3 為例：

NameServer

Broker

?? 如果只暴露 9876 / 10911，而沒(méi)暴露 8081 / 8080：

• Console 能用
• Topic 能看
• Producer 一發(fā)消息就失敗

三、問(wèn)題一：Producer FAILED —— 實(shí)際是 gRPC 不通

典型異常

org.apache.rocketmq.shaded.io.grpc.StatusRuntimeException:
UNAVAILABLE: Network closed for unknown reason

本質(zhì)原因

RocketMQ 5.x Client 通過(guò) gRPC 連接 Broker，但 Broker 的 gRPC 端口未暴露或不可達(dá)

解決方式

在 Docker / 容器環(huán)境中，必須顯式暴露 gRPC 端口：

# NameServer
ports:
  - "9876:9876"
  - "8081:8081"
# Broker
ports:
  - "10911:10911"
  - "8080:8080"

四、問(wèn)題二：No topic route info —— 真正的大坑

在 gRPC 問(wèn)題解決后，緊接著會(huì)遇到第二個(gè)錯(cuò)誤：

No topic route info in name server for the topic: rewre

表面含義

NameServer 中沒(méi)有該 Topic 的路由信息

但問(wèn)題并不只是“沒(méi)建 topic”這么簡(jiǎn)單。

五、致命配置錯(cuò)誤：Producer 默認(rèn) Topic + 代碼顯式 Topic 混用

1?? 錯(cuò)誤示例（問(wèn)題根源）

rocketmq:
  producer:
    endpoints: 127.0.0.1:8081
    group: dromara-producer-group
    topic: rewre   # ? Producer 級(jí)別默認(rèn) topic

demo:
  rocketmq:
    normal-topic: normal-topic

rocketMQClientTemplate.syncSendNormalMessage(normalTopic, message);

日志打印的是：

發(fā)送普通消息到主題: normal-topic

但異常卻是：

No topic route info for topic: rewre

2?? 為什么會(huì)這樣？

這是 RocketMQ 5.x Client 的一個(gè)“隱式行為”：

如果在 rocketmq.producer.topic 中配置了 topic，
Producer 初始化和首次發(fā)送時(shí)，會(huì)優(yōu)先拉取該 topic 的路由信息

即使你在 send() 時(shí)傳入了別的 topic：

syncSendNormalMessage("normal-topic", ...)

?? Client 仍然會(huì)先去 NameServer 查詢 rewre 的路由

如果 rewre 不存在：

40402 No topic route info

六、正確姿勢(shì)：兩種方案，只能選一種

? 方案一（強(qiáng)烈推薦）：刪除 Producer 默認(rèn) topic

正確配置

rocketmq:
  producer:
    endpoints: 127.0.0.1:8081
    group: dromara-producer-group
    timeout: 10000
    max-retry-times: 2
    enable-ssl: false

Topic 全部由代碼控制

syncSendNormalMessage(normalTopic, message);
syncSendDelayMessage(delayTopic, message);
syncSendFifoMessage(fifoTopic, message);

手動(dòng)創(chuàng)建 topic（必須）

mqadmin updatetopic -n rmqnamesrv:9876 -c DefaultCluster -t normal-topic

?? 這是官方示例和生產(chǎn)環(huán)境最推薦的方式

?? 方案二（不推薦）：只使用一個(gè)固定 topic

如果配置了：

rocketmq:
  producer:
    topic: rewre

那么你必須：

• 代碼中 只能發(fā) rewre
• NameServer 中 必須存在 rewre

syncSendNormalMessage("rewre", message);

? 不適合多 topic、延時(shí)、事務(wù)、順序消息場(chǎng)景

七、RocketMQ 5.x 的幾個(gè)重要認(rèn)知糾正

1?? RocketMQ 5.x不會(huì)自動(dòng)創(chuàng)建 Topic

和 4.x 不同：

Topic 必須提前創(chuàng)建，否則必定 40402

2?? Console 看到 ≠ Client 能用

• Console / mqadmin：走舊協(xié)議
• Producer / Consumer：走 gRPC

?? 兩個(gè)世界

3?? 日志不一定可信，異常才是真相

日志打印 topic ≠ Client 實(shí)際拉取路由的 topic

八、最終 Checklist（上線前必查）

• NameServer 暴露 8081
• Broker 暴露 8080
• 使用 rocketmq-client-java 5.x
• 未配置 rocketmq.producer.topic
• 所有 topic 已通過(guò) mqadmin updatetopic 創(chuàng)建
• Producer group 唯一

九、總結(jié)

RocketMQ 5.x 并不是“不能用”，
而是 思維模型已經(jīng)完全不同于 4.x。

真正的三大坑只有：

1. gRPC 端口
2. Topic 不自動(dòng)創(chuàng)建
3. Producer 默認(rèn) topic 與 send topic 混用

只要理解了這三點(diǎn)，
RocketMQ 5.x + Spring Boot 會(huì)非常穩(wěn)定、清晰、現(xiàn)代化。

你這次踩的坑，非常值得被更多人看到。

到此這篇關(guān)于RocketMQ 5.x + Spring Boot 發(fā)送消息失敗全解析的文章就介紹到這了,更多相關(guān)RocketMQ 5.x Spring Boot 發(fā)送消息失敗內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論