本地啟動RocketMQ未映射主機名產(chǎn)生的超時問題最新解決方案

更新時間：2024年02月26日 08:54:20 作者：nuccch

這篇文章主要介紹了本地啟動RocketMQ未映射主機名產(chǎn)生的超時問題,本文給大家分享最新解決方案，感興趣的朋友跟隨小編一起看看吧

問題描述

參考RocketMQ官方文檔在本地啟動一個驗證環(huán)境的時候遇到超時報錯問題。

本地環(huán)境OS：CentOS Linux release 8.5.2111

首先，進入到RocketMQ安裝目錄，如：~/opt/rocketmq-all-5.2.0-bin-release。

執(zhí)行如下命令啟動NameServer：

$ sh bin/mqnamesrv

該命令執(zhí)行很慢，但是最終還是顯示啟動NameServer成功了，輸出日志如下：

Java HotSpot(TM) 64-Bit Server VM warning: Using the DefNew young collector with the CMS collector is deprecated and will likely be removed in a future release
Java HotSpot(TM) 64-Bit Server VM warning: UseCMSCompactAtFullCollection is deprecated and will likely be removed in a future release.
The Name Server boot success. serializeType=JSON, address 0.0.0.0:9876

執(zhí)行jps命令也能看到相應(yīng)進程：

$ jps
13730 NamesrvStartup

執(zhí)行如下命令啟動Broker + Proxy：

$ sh bin/mqbroker -n localhost:9876 --enable-proxy

該命令執(zhí)行非常漫長，差不多要90s左右才會輸出如下日志：

Sat Feb 24 19:48:03 CST 2024 rocketmq-proxy startup successfully

在~/logs/rocketmqlogs/proxy.log日志中也能看到broker啟動成功的日志：

2024-02-24 19:47:53 INFO main - The broker[broker-a, 192.168.88.135:10911] boot success. serializeType=JSON and name server is localhost:9876

注意：日志中的broker-a是在broker.conf文件中配置的brokerName參數(shù)，如下所示：

brokerClusterName = DefaultCluster
brokerName = broker-a # 配置的默認brokerName參數(shù)
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH

再次執(zhí)行jps命令確認相應(yīng)進程是否已經(jīng)啟動：

$ jps
jps
13730 NamesrvStartup
14410 ProxyStartup

一切似乎看起來都正常，從~/logs/rocketmqlogs/namesrv.log和~/logs/rocketmqlogs/proxy.log日志中也看不出明顯的異常。

但是在創(chuàng)建Topic時就會報錯：

$ sh bin/mqadmin updatetopic -n localhost:9876 -t TestTopic -c DefaultCluster

該命令在執(zhí)行大約40s左右就會輸出如下報錯日志：

org.apache.rocketmq.tools.command.SubCommandException: UpdateTopicSubCommand command failed
at org.apache.rocketmq.tools.command.topic.UpdateTopicSubCommand.execute(UpdateTopicSubCommand.java:198)
at org.apache.rocketmq.tools.command.MQAdminStartup.main0(MQAdminStartup.java:164)
at org.apache.rocketmq.tools.command.MQAdminStartup.main(MQAdminStartup.java:114)
Caused by: org.apache.rocketmq.remoting.exception.RemotingTimeoutException: invokeSync call the addr[127.0.0.1:9876] timeout
at org.apache.rocketmq.remoting.netty.NettyRemotingClient.invokeSync(NettyRemotingClient.java:549)
at org.apache.rocketmq.client.impl.MQClientAPIImpl.getBrokerClusterInfo(MQClientAPIImpl.java:1961)
at org.apache.rocketmq.tools.admin.DefaultMQAdminExtImpl.examineBrokerClusterInfo(DefaultMQAdminExtImpl.java:577)
at org.apache.rocketmq.tools.admin.DefaultMQAdminExt.examineBrokerClusterInfo(DefaultMQAdminExt.java:318)
at org.apache.rocketmq.tools.command.CommandUtil.fetchMasterAddrByClusterName(CommandUtil.java:94)
at org.apache.rocketmq.tools.command.topic.UpdateTopicSubCommand.execute(UpdateTopicSubCommand.java:171)
... 2 more

從報錯信息看似乎是無法連接127.0.0.1:9876，但是經(jīng)過驗證發(fā)現(xiàn)該地址是一定可以連通的，再幾經(jīng)嘗試之后依然報錯。

于是換了一臺Windows機器繼續(xù)驗證，奇怪的是在Windows機器上一切正常，而且我注意到在Windows環(huán)境啟動RocketMQ的時候brokerName使用是主機名，如下日志：

# zhangsan是主機名
The broker[zhangsan, 20.5.133.188:10911] boot success. serializeType=JSON and name server is localhost:9876

于是腦袋中突然閃現(xiàn)一個疑問，是不是因為沒有在CentOS的/etc/hosts文件中映射主機名與127.0.0.1地址導(dǎo)致的。

驗證后果然就正常的。

原因追蹤

根據(jù)相關(guān)報錯日志梳理RocketMQ的源代碼，報錯是因為在NettyRemotingClient.invokeSync()方法中做了超時判斷。

@Override
public RemotingCommand invokeSync(String addr, final RemotingCommand request, long timeoutMillis)
    throws InterruptedException, RemotingConnectException, RemotingSendRequestException, RemotingTimeoutException {
    long beginStartTime = System.currentTimeMillis();
    final Channel channel = this.getAndCreateChannel(addr);
    String channelRemoteAddr = RemotingHelper.parseChannelRemoteAddr(channel);
    if (channel != null && channel.isActive()) {
        long left = timeoutMillis; // 默認超時時長是5000ms
        try {
            long costTime = System.currentTimeMillis() - beginStartTime;
            left -= costTime;
            if (left <= 0) { // 當(dāng)執(zhí)行時長超過5s時直接拋出異常
                throw new RemotingTimeoutException("invokeSync call the addr[" + channelRemoteAddr + "] timeout");
            }
            RemotingCommand response = this.invokeSyncImpl(channel, request, left);
            updateChannelLastResponseTime(addr);
            return response;
        }
        //其他代碼省略...
    }
    //其他代碼省略...
}

由于是做了超時檢查拋出的異常，所以單純從日志信息看就會認為是無法連接127.0.0.1:9876，實際上該地址是可以連通的。

進一步追蹤發(fā)現(xiàn)，是在執(zhí)行Netty的ReflectiveChannelFactory.newChannel()方法耗時較長，約10s左右。

@Override
public T newChannel() {
    try {
        // constructor是NioSocketChannel.class
        // 所以本質(zhì)上這里是要通過反射的方式實例化一個NioSocketChannel對象
        T t = constructor.newInstance();
        return t;
    } catch (Throwable t) {
        throw new ChannelException("Unable to create Channel from class " + constructor.getDeclaringClass(), t);
    }
}

驗證代碼如下：

long start = System.currentTimeMillis();
Constructor constructor = NioSocketChannel.class.getConstructor();
constructor.newInstance();
System.out.println(String.format("%s ms", System.currentTimeMillis() - start));

執(zhí)行后輸出日志：