总结⼀下最近rocketMQ踩过的坑，以及它的⼀个解决办法汇总。
1.解决RocketMQ报No route info of this topic：异常
近⽇在做RocketMQ的时候，mqnamesrv和mqbroker都正常启动了，但是在运⾏⽣产者的时候，报了个No route info of this topic的异常，让我很是郁闷。上⽹了⼀些资料，现把解决办法记录如下，如果还有其他的原因导致这个问题的，后续会补充。
解决⽅法⼀：
Linux系统下：
在启动mqbroker的时候需要指定 autoCreateTopicEnable=true。例如：
nohup sh mqbroker -n 192.168.180.133:9876
fastjson常用方法autoCreateTopicEnable=true > ~/logs/rocketmqlogs/broker.log 2>&1 &
window系统下：
在window系统下需要在cmd中启动mqbroker才⾏。命令格式如下：
< -n localhost:9876autoCreateTopicEnable=true
有⽹友在下⾯评论说缺少fastjson jar包也会导致此问题。
解决⽅法⼆：
rocketmq运⾏时提⽰ No route info of this topic 异常产⽣的原因可能是
①Broker禁⽌⾃动创建Topic，且⽤户没有通过⼿⼯⽅式创建Topic
②Broker没有正确连接到Name Server
③Producer没有正确连接到Name Server
⾸先解决①这种情况，启动顺序要先启动nameserver，再启动broker，启动broker时加上autoCreateTopicEnable=true
例如 nohup sh mqbroker -n localhost:9876 autoCreateTopicEnable=true &
启动没有异常检查下nameserver中是否成功注册了broker，有两种⽅式
第⼀种、看broker的⽇志 如果出现形如
2018-02-28 16:21:35 INFO BrokerControllerScheduledThread1 - register broker to name server 192.168.192.129:9876 OK
2018-02-28 16:22:05 INFO BrokerControllerScheduledThread1 - register broker to name server 192.168.192.129:9876 OK
证明已经连接到nameserver上
第⼆种、 在bin⽬录下执⾏命令sh mqadmin clusterList -n localhost:9876 如果看到
#Cluster Name #Broker Name #BID #Addr #Version #InTPS(LOAD) #OutTPS(LOAD) #PCWait(ms) #Hour #SPACE DefaultCluster DEFAULT_BROKER 0 192.168.192.129:10911 V4_2_0_SNAPSHOT 0.00(0,0ms) 0.00(0,0ms) 0
422168.55 -1.0000
也是证明已经连接到nameserver上。
如果按前两步检查没有问题，但启动还是报错，那么剩下的可能原因是producer⽆法连接到nameserver，很可能是防⽕墙的原因 ，要检验猜测只需要关闭防⽕墙，命令为systemctl stop firewalld.service
然后再次验证，应该已经可以使⽤了。
2.关于RocketMQ消息收不到的问题
3.mqnameserver 或者 mqbroker 没有启动成功。
要在 /distribution/target/apache-rocketmq/bin 下的2个脚本中设置内存占⽤⼤⼩。
vim bin/runserver.sh　（调整nameserver启动的内存，不调整此⽂件，可能导致⽆法启动。）
JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn512m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"　
vim bin/runbroker.sh    JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m"
4.把内⽹ip改成公⽹ip
解决⽅案：
1.修改f，内容如下：
brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH
namesrvAddr=47.101.167.214:9876
listenPort=10911
brokerIP1=47.101.167.214
这⾥的47.101.167.214是公⽹IP
2. 启动Name Server：
nohup sh bin/mqnamesrv &
3. 启动Broker：
nohup sh bin/mqbroker -n 47.101.167.214:9876 -c f &
=======
定位问题的过程：
⽽测试代码使⽤的是RocketMQTemplate玩的，⽆法直接操作setVipChannelEnabled，所以不妨顺着第⼆条路⾛（开放10911、10909这两个端⼝）
然⽽，我发现在本机telnet 10911、10909这两个端⼝是通的，说明端⼝开放没问题。
====
陷⼊僵局后，我就分析nohup⽇志，发现有类似如下的⽇志：
The broker[iZuf6h6yzsw5uybsq1y7w8Z, 172.19.172.31:10911] boot success. serializeType=JSON and name server is 47.101.167.214:9876
也就是说，broker启动时，往Name Server注册的是个内⽹地址（172.19.172.31），⽽我们希望是公⽹地址。所以，修改下f，设置下IP；并在启动broker时，⽤-c f 指定读取配置⽂件。
此时，会打印类似如下的⽇志，和预期相符。
The broker[broker-a, 47.101.167.214:10911] boot success. serializeType=JSON and name server is 47.101.167.214:9876
=====
注意点：
需要开放10911、10909这两个端⼝
需修改f，设置公⽹IP
启动broker时，需⽤-c f，读取配置⽂件
其他参考：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。