系统越做越大后，我才明白为什么大厂都离不开RocketMQ

前言刚接触消息队列的时候我一直觉得它离自己很远。毕竟大多数小项目里一个接口调另一个接口数据库直接读写功能照样能跑。直到有一天系统访问量慢慢上来各种问题开始集中爆发订单创建变慢、短信发送超时、日志写入拖垮接口甚至一个下游服务出问题整个业务链路都跟着受影响。那时候我才发现很多系统性能问题其实并不是服务器不够强而是服务之间耦合得太紧。本来用户下单只需要写数据库却还要同步发送短信、同步更新库存、同步记录日志、同步推送通知。任何一个环节变慢整个请求都会跟着变慢。而消息队列解决的恰恰就是这种问题。后来在学习消息中间件时我选择了 RocketMQ。作为 Apache 顶级项目它不仅支撑过大规模业务场景还具备高吞吐、高可靠和分布式扩展能力。很多互联网公司在订单、支付、库存和异步任务场景中都能看到它的身影。而相比直接使用 Docker 镜像我更希望真正理解 RocketMQ 的运行机制。所以这次选择从 Linux 原生部署开始亲手搭建 NameServer 和 Broker把整个消息链路跑通。1.前提条件首先需要安装jdkjava-version下载RocketMQ的源码包以及运行包RocketMQ建议的运行环境需要至少12G的内存。关于RocketMQ的版本 我们这里采用最新的5.3.4版本这里需要小伙伴注意一下4.x的系列版本已经停止了维护。这意味着目前已经不建议使用4.x的版本了。2.安装RocketMQ将下载后的文件上传到/app/rocketmqmkdir-procketmqcdrocketmq/解压该文件unziprocketmq-all-5.3.4-bin-release.zip修改rocketmq文件名mvrocketmq-all-5.3.4-bin-release/ rocketmq3.配置RocketMQ3.1修改runserver.sh和runbroker.sh启动脚本修改runserver.sh脚本vi/app/rocketmq/rocketmq/bin/runserver.sh将原来的参数就改为红框内参数如果你的机器内存够大这一步可以不配置jdk路径必须修改为自己的jdk路径whichjava修改runbroker.sh脚本vi/app/rocketmq/rocketmq/bin/runbroker.sh将原来的参数就改为红框内参数如果你的机器内存够大这一步可以不配置jdk路径必须修改为自己的jdk路径3.2新增broker.conf配置信息编辑broker.conf配置文件vi/app/rocketmq/rocketmq/conf/broker.conf namesrvAddrlocalhost:9876 brokerIP1localhost3.3启动关闭rocketmq创建日志目录mkdir-p/data/logs/rocketmq启动命令#启动namesrv服务nohupsh/app/rocketmq/rocketmq/bin/mqnamesrv/data/logs/rocketmq/nameserver.log#启动broker服务nohupsh/app/rocketmq/rocketmq/bin/mqbroker-nlocalhost:9876autoCreateTopicEnabletrue/data/logs/rocketmq/broker.log验证是否启动成功jps关闭命令:#关闭namesrv服务/app/rocketmq/rocketmq/bin/mqshutdown namesrv#关闭broker服务/app/rocketmq/rocketmq/bin/mqshutdown broker4.配置开机自启动编写namesrv服务#创建配置文件vi/etc/systemd/system/rocketmqnamesrv.service#添加如下内容[Unit]Descriptionrocketmq - nameserverDocumentationrocketmq_nameserverAfternetwork.target[Service]TypesampleUserrootExecStart/app/rocketmq/rocketmq/bin/mqnamesrvExecReload/bin/kill-sHUP$MAINPIDExecStop/bin/kill-sQUIT$MAINPIDRestart0LimitNOFILE65535[Install]WantedBymulti-user.target编写broker服务#创建配置文件vi/etc/systemd/system/rocketmqbroker.service#添加如下内容[Unit]Descriptionrocketmq - brokerDocumentationrocketmq_brokerAfternetwork.target[Service]TypesampleUserrootExecStart/app/rocketmq/rocketmq/bin/mqbroker-nlocalhost:9876 /app/rocketmq/rocketmq/conf/broker.confExecReload/bin/kill-sHUP$MAINPIDExecStop/bin/kill-sQUIT$MAINPIDRestart0LimitNOFILE65535[Install]WantedBymulti-user.target此时rocketmq是关闭状态使用systemctl 方式启动测试:#依次执行启动namesrvsystemctl daemon-reload systemctlenablerocketmqnamesrv.service systemctl start rocketmqnamesrv.service systemctl status rocketmqnamesrv.service#依次执行启动brokersystemctl daemon-reload systemctlenablerocketmqbroker.service systemctl start rocketmqbroker.service systemctl status rocketmqbroker.service你已在内网Linux服务器上部署了Apache RocketMQ执行mqnamesrv和mqbroker成功启动了消息服务。但默认情况下这些服务仅监听本地或局域网外网客户端无法连接——即使你只是想从公司网络外发送一条测试消息也会因网络隔离而失败。此时无需申请公网IP或配置复杂端口映射只需借助cpolar内网穿透工具将RocketMQ的关键端口安全暴露到公网。一旦隧道建立任何外网设备都能像在内网一样直接连接并使用你刚刚启动的RocketMQ服务。5.安装cpolar内网穿透工具cpolar 可以将你本地电脑中的服务如 SSH、Web、数据库映射到公网。即使你在家里或外出时也可以通过公网地址连接回本地运行的开发环境。❤️以下是安装cpolar步骤使用一键脚本安装命令sudocurlhttps://get.cpolar.sh|sh安装完成后执行下方命令查看cpolar服务状态如图所示即为正常启动sudosystemctl status cpolarCpolar安装和成功启动服务后在浏览器上输入虚拟机主机IP加9200端口即:【ip:9200】访问Cpolar管理界面使用Cpolar官网注册的账号登录,登录后即可看到cpolar web 配置界面,接下来在web 界面配置即可打开浏览器访问本地9200端口使用cpolar账户密码登录即可,登录后即可对隧道进行管理。6.配置公网地址通过配置你可以在本地 WSL 或 Linux 系统上运行 SSH 服务并通过 Cpolar 将其映射到公网从而实现从任意设备远程连接开发环境的目的。隧道名称可自定义本例使用了:rocketmq注意不要与已有的隧道名称重复协议tcp本地地址9876端口类型随机临时TCP端口地区China Top创建成功后打开左侧在线隧道列表,可以看到刚刚通过创建隧道生成了公网地址接下来就可以在其他电脑或者移动端设备异地上使用任意一个地址在终端中访问即可。tcp 表示使用的协议类型2.tcp.cpolar.top是 Cpolar 提供的域名11242是随机分配的公网端口号现在我们用另一台虚拟机启动一下我们的rocketmqnohupsh/app/rocketmq/rocketmq/bin/mqbroker-n2.tcp.cpolar.top:11242autoCreateTopicEnabletrue/data/logs/rocketmq/broker.log如图可见 启动成功7.保留固定TCP公网地址使用cpolar为其配置TCP地址该地址为固定地址不会随机变化。选择区域和描述有一个下拉菜单当前选择的是“China Top”。右侧输入框用于填写描述信息。保留按钮在右侧有一个橙色的“保留”按钮点击该按钮可以保留所选的TCP地址。列表中显示了一条已保留的TCP地址记录。登录cpolar web UI管理界面点击左侧仪表盘的隧道管理——隧道列表找到所要配置的隧道rocketmq点击右侧的编辑。修改隧道信息将保留成功的TCP端口配置到隧道中。端口类型选择固定TCP端口预留的TCP地址填写保留成功的TCP地址点击更新。创建完成后打开在线隧道列表此时可以看到随机的公网地址已经发生变化地址名称也变成了保留和固定的TCP地址。这样我们的地址就永远不会发生变化啦总结体验下来RocketMQ 最大的价值并不是提升性能而是提升系统的容错能力。很多开发者第一次接触消息队列时关注的往往是高并发。但真正进入生产环境之后你会发现更重要的是解耦。原本互相依赖的系统通过消息队列连接之后即使某个服务短暂异常也不会立即影响整个业务流程。尤其是在订单、支付、库存同步、消息通知等场景下RocketMQ 的异步处理能力能够明显降低系统压力。当流量突然上涨时它还能承担削峰填谷的作用避免请求直接冲垮后端服务。而通过本文的部署实践从 NameServer、Broker 到服务启动和远程访问配置已经能够搭建起一个完整可运行的 RocketMQ 环境。后续无论是接入 Spring Boot、扩展集群架构还是引入监控体系都有了继续演进的基础。再结合 cpolar 提供的公网 TCP 地址能力后即使 RocketMQ 部署在内网环境中也能够实现跨网络访问和远程测试大幅降低开发和验证成本。很多人学习 RocketMQ是因为面试会问。但真正把它部署起来之后你会发现消息队列最大的意义从来不是让系统跑得更快。而是让系统在复杂业务场景下依然能够稳稳地跑下去。