1. 这类问题到底是怎么冒出来的1.1 RocketMQ 的路由机制决定了地址只有一个RocketMQ 的寻路逻辑其实不复杂broker 启动时会把自己的地址注册到 NameServer客户端在发消息或收消息之前先连 NameServer 拿路由信息再拿着返回的 broker 地址去建立真正的通信连接。整个链路里客户端拿到的是 broker 注册时写进去的那个地址NameServer 本身不做任何转发也不做地址改写。问题就出在这个“注册地址”上。默认情况下broker 会从本机网卡里挑一个 IP 当成自己的地址。如果机器只有一张网卡那没有任何分歧一旦机器处于多网卡环境比如云服务器上既有内网 IP 又有公网 IP默认选中的很可能是内网地址。内网客户端拿这个地址自然没问题但外网客户端拿到一个 172.16.x.x 或者 10.x.x.x 的地址在公网上根本路由不到连接直接超时。这就是内外网同时访问 RocketMQ 的核心矛盾点broker 只能往 NameServer 上注册地址但这个地址如果只适合内网外网就废了如果只适合公网内网客户端虽然也能连但要绕公网走一圈延迟暴涨而且一旦安全组限制公网入口内网请求也会被一起拦掉。1.2 内外网同时访问的核心矛盾很多人第一反应是“我能不能注册两个地址让 NameServer 根据客户端来源返回不同结果”。答案是否定的。NameServer 是个轻量级的路由中心它不会去判断请求来自内网还是外网也没有“按来源返回不同路由”这种精细化策略。它保存的就是一个 broker 对应一个地址严格说是 brokerId 对应一个地址返回给所有客户端都是同一份路由数据。所以“同时访问”这个需求本质上不是让 NameServer 做智能分发而是让 broker 把自己暴露成“两个身份”内网用的身份和公网用的身份并且这两个身份都能被客户端正确拿到、正确尝试。RocketMQ 从 4.x 中后段版本开始官方就支持了这种玩法。核心就是brokerIP1和brokerIP2这两个配置项配合客户端 SDK 的连接探测机制让同一套 broker 既能让内网客户端走内网 IP 直连又能让外网客户端走公网 IP 接入。顺便说一句这个问题也经常出现在 RocketMQ 面试题里。面试官问你“broker 在公网环境下如何让内外网客户端同时访问”本质上就是想看你知不知道brokerIP1/brokerIP2这个双地址注册机制。理解了 1.1 和 1.2 这两节这个知识点基本就吃透了。2. 官方解法brokerIP1 brokerIP2 组合配置2.1 关键配置项逐条拆解在 broker.conf 里和网络地址相关的配置项就三个但别小看它们配置项作用默认值适用场景brokerIP1broker 主动注册到 NameServer 的主地址内网客户端主要通过它访问自动探测本机 IP内网/生产环境brokerIP2broker 附加注册到 NameServer 的第二个地址外网客户端主要通过它访问空多网卡、内外网隔离、云服务器公网直连listenPortbroker 对外提供 Remoting 服务的端口10911不需要改除非端口冲突brokerIP1和brokerIP2之间不是主备关系它们是“同一端口、两个可路由 IP”的关系。也就是说brokerIP2不会占用新的监听端口它只是告诉 NameServer“除了内网那个地址我这个 broker 还有一个公网地址你也记一下客户端要是连不上第一个可以试试第二个”。这里需要特别强调一下brokerIP2对应的端口和brokerIP1是相同的。比如 broker 监听 10911那么brokerIP1:10911和brokerIP2:10911必须都能访问到同一个 broker 进程。云服务器上一般通过安全组同时放行内网和公网方向的 10911 端口来实现。2.2 为啥 NameServer 能记住两个地址broker 启动时会通过RegisterBroker请求把地址信息上报给 NameServer。请求体里会同时携带两个地址字段对应关系大致如下brokerAddr由brokerIP1生成格式为brokerIP1:listenPortbrokerAddr2由brokerIP2生成格式为brokerIP2:listenPortNameServer 收到注册请求后会把两个地址都存下来。之后客户端来拉取路由信息时返回的BrokerData结构里会同时包含这两组地址。客户端在建立实际连接时会先尝试默认地址如果连不上再尝试第二个地址。这个“先主后次、失败自动切换”的行为已经封装在最新几代客户端 SDK 里了不需要业务代码额外处理。这也是为什么brokerIP2方案能同时满足内外网内网客户端拿到路由后默认地址brokerIP1直连可达直接成功外网客户端拿到同样的路由信息先尝试brokerIP1失败随后自动切换到brokerIP2完成连接。这里透露一个排查经验如果你配了brokerIP2但外网客户端还是连不上优先检查 NameServer 里存的路由信息是否真的包含两个地址。用mqadmin topicRoute或直接查集群状态就能看出来具体命令我在后面 3.3 节给出来。2.3 版本约束与选型建议brokerIP2这个配置项不是 RocketMQ 开天辟地就有的需要 broker 和客户端都达到一定版本才能稳定工作。从我实际用下来的经验看RocketMQ 4.5.0 之前这个能力还不太成熟不建议在生产环境依赖它。RocketMQ 4.8.0、4.9.x 是目前存量项目里用得最多的版本双地址注册和客户端自动切换已经很稳定网上的踩坑案例也基本都能搜到相关解决方案。RocketMQ 5.x 继续保留了这套配置方式同时引入了 Proxy 模式。如果你想用 5.x 的新特性网络规划会比 4.x 稍微复杂一点因为 Proxy 模式多了一个 gRPC 端口内外网同时访问需要额外考虑这个端口的放行和转发。如果你是 Windows 本地装了 RocketMQ 4.8.0 做测试或者 Linux 服务器上装了 RocketMQ 5.5.0 跑生产配置思路完全一样区别主要在防火墙和端口放行方式上。Windows 的防火墙弹窗容易挡住外网访问Linux 一般要先看安全组再看 iptables/firewalld我把这些细节放到第 4 章排查部分细说。3. 从零实操让内外网都能连上同一套 broker3.1 环境准备与网络规划动手之前先把网络拓扑理清楚。以最常见的云服务器场景为例服务器内网 IP172.16.0.10服务器公网 IP121.40.xx.xxNameServer 和 broker 部署在同一台机器上NameServer 监听端口9876Broker 监听端口10911VIP 通道端口10909我们需要保证三条链路都通内网客户端 - NameServer 内网地址172.16.0.10:9876拉取路由内网客户端 - Broker 内网地址172.16.0.10:10911收发消息外网客户端 - NameServer 公网地址121.40.xx.xx:9876拉取路由外网客户端拿到的路由里需要包含公网 broker 地址也就是121.40.xx.xx:10911然后由客户端 SDK 自动完成“先试内网地址、失败就切公网地址”的动作。NameServer 本身不需要额外配置内外网它默认监听0.0.0.0:9876只要安全组把 9876 端口同时放行给内网网段和公网来源内外网客户端就都能访问它。关键在于 broker 的注册地址也就是brokerIP1和brokerIP2必须按下面的方式配。3.2 修改 broker.conf 的完整配置示例我给出一个可以直接复制的broker.conf配置假设 broker 部署在 Linux 服务器上# broker 集群名称按实际环境填写 brokerClusterNameDefaultCluster # broker 名称同一个集群里建议用有业务含义的名字 brokerNamebroker-a # 0 表示 Master0 表示 Slave brokerId0 # NameServer 地址多个用分号隔开 namesrvAddr172.16.0.10:9876 # 内网访问地址 brokerIP1172.16.0.10 # 公网访问地址 brokerIP2121.40.xx.xx # broker 监听端口 listenPort10911 # 数据存储路径按实际目录调整 storePathRootDir/data/rocketmq/store storePathCommitLog/data/rocketmq/store/commitlog # 自动创建 Topic测试环境可以开生产建议关了 autoCreateTopicEnablefalse # 刷盘方式ASYNC_FLUSH 性能好SYNC_FLUSH 更安全 flushDiskTypeASYNC_FLUSH有几处容易踩坑我专门提一下第一brokerIP1不要靠默认值最好手动指定。有些机器多网卡环境下broker 默认探测出来的 IP 根本不是你想用的内网地址一旦注册错内网客户端全连不上。第二brokerIP2必须填公网 IP不能填域名。RocketMQ 的地址解析按 IP 处理填域名可能出现解析失败或者客户端拿到域名后无法路由的情况。第三如果你把brokerIP2配成了空字符串甚至可以不配这个属性。但既然你的需求是内外网同时访问就一定不要漏掉它。3.3 重启与验证用 mqadmin 看路由是否正常修改配置之后需要重启 broker。如果 NameServer 是独立进程建议先确保 NameServer 在运行再启动 broker。完整命令参考如下# 先启动 NameServer nohup sh bin/mqnamesrv /data/rocketmq/logs/namesrv.log 21 # 再启动 broker指定配置文件 nohup sh bin/mqbroker -c /data/rocketmq/conf/broker.conf /data/rocketmq/logs/broker.log 21 RocketMQ 5.x 的启动命令和 4.x 基本一致如果你的安装目录下有bin/mqbroker或者bin/mqserver对应启动即可。Windows 环境下就是双击或命令行执行mqnamesrv.cmd和mqbroker.cmd参数用法一样。启动完成后第一步验证 broker 有没有注册成功# 查看集群列表确认 broker 状态正常 mqadmin clusterList -n 172.16.0.10:9876第二步验证指定 Topic 的路由信息# 查看路由重点看 BrokerAddr 和 BrokerAddr2 两个字段 mqadmin topicRoute -n 172.16.0.10:9876 -t TestTopic如果brokerIP2配置生效路由信息里应该能看到两组地址。内网地址作为主地址公网地址作为附加地址。如果只看到一组地址大概率是 broker 没加载到最新配置或者 broker 版本不支持brokerIP2。创建 Topic 的命令也顺便列出来后面测试的时候会用# 按 broker 维度创建 mqadmin updateTopic -n 172.16.0.10:9876 -b 172.16.0.10:10911 -t TestTopic # 按集群维度创建 mqadmin updateTopic -n 172.16.0.10:9876 -c DefaultCluster -t TestTopic3.4 两端客户端实测内网和外网分别验证路由验证通过之后我们用客户端实测一下。内网客户端和外网客户端的name-server配置可以不一样内网填172.16.0.10:9876外网填121.40.xx.xx:9876这是正常的因为 NameServer 本身是同一套只是入口地址不同。如果是 Spring Boot 项目application.yml里大致这样配rocketmq: # 内网客户端用内网 Nameserver 地址外网客户端用公网地址 name-server: 172.16.0.10:9876 producer: group: test-producer-group配好之后写一个简单的生产者发一条普通消息RestController RequestMapping(/mq) public class MQTestController { Autowired private RocketMQTemplate rocketMQTemplate; GetMapping(/send) public String send() { rocketMQTemplate.convertAndSend(TestTopic, hello rocketmq); return ok; } }外网客户端同样跑起来只要它能拿到路由、能连上公网 broker 地址消息就能正常发出去。这里如果想要更严谨可以把生产者部署在内网消费者部署在外网或者反过来验证两端都能收发。其实 RocketMQ 的消息类型比较丰富普通消息、顺序消息、延迟消息、事务消息都有各自的适用场景。内外网访问的问题主要发生在连接通道层面和消息类型没有直接关系但如果你在实测时发现某一种消息类型特别慢或者发送失败还是要回头确认是不是网络链路某个端口被安全组挡了。4. 常见问题与排查技巧4.1 外网连不上报错怎么办外网客户端最常见的报错是RemotingConnectException比如org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to 172.16.0.10:10911 failed看到这个报错第一反应不用慌这是外网客户端拿到了内网地址去连 broker走不通。排查顺序按下面来确认 broker.conf 里brokerIP2是否真的配置了公网 IP并且 broker 是否已经用新配置重启过。用mqadmin topicRoute看路由信息里是否包含公网地址。确认公网 10911 端口是否放行云服务器安全组、iptables、firewalld 都要查。确认外网客户端 SDK 版本是否过低。4.4 及之前的客户端对brokerIP2的支持不够好建议至少用到 4.8.0 之后的客户端版本。这里有个很容易被忽略的点如果外网客户端报错的地址一直是内网 IP说明它拉到的路由里根本没有公网地址问题大概率出在 broker 配置或 NameServer 缓存上而不是安全组。先看路由再查防火墙顺序不要反。4.2 端口放行清单与安全组配置内外网同时访问 RocketMQ需要放行的端口比单纯内网访问多不少列成一个清单方便对照端口用途内网是否放行公网是否放行9876NameServer 服务端口是是10911Broker 主端口是是10909Broker VIP 通道端口是建议放行8080RocketMQ Dashboard按需不建议公网开放10909这个端口很多老手都会忘。RocketMQ 客户端默认会优先使用 VIP 通道端口访问 broker也就是listenPort - 2。如果只放行 10911 忘了 10909外网客户端在发送时会报“connect to 公网IP:10909 failed”之类的错误。安全组放行时建议公网方向配合来源 IP 白名单别把0.0.0.0/0全放。尤其是 broker 的 10911 端口一旦完全暴露公网等于把 RocketMQ 集群直接挂到公网上任何知道 IP 的人都能尝试连接风险很高。4.3 客户端版本太老导致 brokerIP2 不生效这是一个非常典型的隐蔽问题。broker 端已经正确配置了brokerIP2路由信息里也能看到公网地址但运行中的消费者客户端始终只连内网地址日志里反复报连接超时却看不到切换的动作。我遇到过类似情况最后定位到是客户端 SDK 版本停留在 4.4.x。这个版本的客户端在解析路由时对BrokerData里第二组地址的支持还不完善压根不会尝试公网地址。后来把客户端依赖升级到 4.9.4问题立刻消失。所以如果你的客户端是 Spring Boot 项目不要只看 spring-boot-starter 版本要看里面实际传递的rocketmq-client版本。建议统一用 4.8.0 以上最好直接用到 4.9.x 最新补丁版既稳定又对双地址支持最好。多 Topic 的场景也顺带说一句多 Topic 不需要额外做网络配置因为 Topic 路由本来就挂在同一个 broker 上内网外网访问的通道一致。只要一个 Topic 验证通过其他 Topic 正常创建就能走同样的链路。4.4 其他细碎但必须注意的坑namesrvAddr里的地址是给 broker 注册用的也是给客户端拉路由用的。broker 往 NameServer 注册时如果namesrvAddr填成内网地址也没问题因为这是 broker 和 NameServer 之间的通信不涉及外网客户端。如果用 Docker 或 Kubernetes 部署 RocketMQbroker 的brokerIP1不能随便填容器内部 IP否则客户端根本路由不到。一般填宿主机内网 IPbrokerIP2填宿主机公网 IP同时容器端口要映射到宿主机。broker 日志里能看到注册是否成功。如果启动日志中出现“register broker to name server failed”之类的提示先查 NameServer 地址有没有写错再看 broker 到 NameServer 的网络是否通。修改配置后光重启 broker 不够过量缓存了旧路由信息的客户端可能要等一段时间才能刷新。测试时最好把客户端进程也重启一下避免旧连接干扰判断。5. 几个值得留意的进阶思路5.1 不想直接暴露 broker 公网端口用转发层兜底直接通过brokerIP2暴露公网端口是最省事的方案但不是唯一方案。如果安全要求高可以考虑在 broker 前面加一层 TCP 转发比如用 Nginx 的 stream 模块或者云服务商提供的四层负载均衡。转发层的作用是把公网流量导到 broker 的 10911 端口但 broker 本身只监听内网地址公网客户端拿到的地址是转发层的公网 IP。这样的话brokerIP2可以配成转发层的公网 IP而不是 broker 真实的公网地址。好处是 broker 不会直接接触公网流量出问题的面小一些。坏处是链路多了一跳延迟会略微上升而且转发层本身也要高可用不然转发层挂了外网就全部不可用。我的建议是团队人力充足、安全要求严格用转发层个人服务器、测试环境直接用brokerIP2最省心。5.2 多 broker 架构下如何分内外网生产环境一般不会只部署一个 broker通常会搭多 Master 或者 Master-Slave。多 broker 架构下每台 broker 机器上的broker.conf都按同样的思路配置brokerIP1填本机内网 IPbrokerIP2填本机公网 IP。需要注意的一点是同一个集群里每个 broker 的brokerName、brokerId不能重复否则注册到 NameServer 时会互相覆盖。这个问题在单 broker 环境里不存在但多 broker 环境里很常见。另外如果 broker 分布在不同的物理机房或者不同的云服务器上内网和公网的 IP 规划可能不一样比如 A 机器有公网 IPB 机器没有公网 IP那外网客户端只能访问 A。这时候就不用强行给 B 配brokerIP2否则外网客户端即使拿到了 B 的公网地址也连不上。提前做好拓扑梳理很重要。5.3 RocketMQ 5.x Proxy 模式下的新变量RocketMQ 5.x 主推 Proxy 模式客户端可以通过 gRPC 协议连接 RocketMQ这带来了一个新的端口维度。除了传统的 9876NameServer、10911Broker 主端口、10909VIP 通道还有 Proxy 暴露的 gRPC 端口默认 8081。如果用的是 5.x 且启用了 Proxy内外网同时访问时这些端口都要考虑放行。brokerIP1/brokerIP2的配置思路依然适用但 gRPC 入口的地址选择机制跟 Remoting 协议不完全一样排障时要分开看日志。如果你是刚从 4.x 升级到 5.x建议先在测试环境把 Remoting 模式跑通再考虑切到 Proxy 模式。一步到位切换网络问题和新特性问题叠加在一起很难定位。我自己在实际项目里大多数客户还是选择 4.9.x 的 Remoting 模式为主简单可靠brokerIP1加brokerIP2就能解决问题。5.x 的新模式适合新项目尤其是想用 gRPC 生态或者多语言客户端的团队但需要接受的网络复杂度也确实更高。最后再分享一个实操中的小体会配置brokerIP2之后一定要同时验证“内网客户端收发正常”和“外网客户端收发正常”这两个方向只验证一头很容易漏掉问题。我自己就踩过只配了brokerIP2、内网走了公网回环导致延迟暴涨的坑后来把brokerIP1明确指定成内网地址才彻底解决。先看路由再查端口最后看客户端版本这套顺序基本能覆盖绝大多数内外网访问问题。