1. 项目概述为什么在 WSL2 里部署 MySQL、Redis 和 RocketMQ 是当前最务实的开发中间件方案如果你正在 Windows 上做后端开发、微服务架构验证或者准备面试 Java/Go/Python 的中高级岗位大概率已经卡在这样一个现实困境里本地想跑一套完整的中间件环境——MySQL 存业务数据、Redis 做缓存和会话管理、RocketMQ 处理异步解耦与流量削峰——但直接装在 Windows 上要么服务启动失败比如 RocketMQ 的 nameserver 启动报java.io.IOException: Unable to establish loopback connection要么配置路径混乱Redis 的redis.windows.conf和 Linux 版本行为差异极大更别说后续要对接 Spring Boot 或 Node.js 项目时Docker Desktop WSL2 混合模式下网络互通性差、端口映射反复失效这些“经典玄学”。我去年带三个校招新人做电商秒杀 Demo光是解决 Windows 下 RocketMQ 控制台无法连上本地 nameserver 就花了整整两天最后发现根本不是配置问题而是 Windows 原生 TCP 栈对 RocketMQ 自定义 remoting 协议的兼容性缺陷。而当你把整套中间件全迁到 WSL2 的 Ubuntu 22.04 里所有问题瞬间消失MySQL 的 socket 文件路径统一、Redis 的bind 127.0.0.1不再被 Windows 防火墙误拦截、RocketMQ 的brokerIP1可以稳定指向 WSL2 虚拟网卡地址如172.28.16.1更重要的是——你获得了一个无限接近生产环境的 Linux 运行时systemd 管理服务、apt 包管理器一键安装、bash 脚本可直接复用线上部署逻辑。这不是“为了用而用”的技术炫技而是把开发环境的“可信度”从 60 分拉到 95 分的关键一跃。标题里的“WSL2 核心中间件部署实战”核心就落在“核”字上它不教你怎么点开图形化安装向导而是带你亲手编译 RocketMQ 的 broker 配置、手写 MySQL 的 my.cnf 安全加固参数、用 systemd service 文件让 Redis 开机自启——每一步都直指真实产线运维的最小闭环。适合谁三类人必须看一是正在准备中间件相关面试题比如“RocketMQ 如何保证消息不丢失”“Redis AOF 重写触发条件”却缺乏实操环境的开发者二是团队已用 Spring Cloud Alibaba 架构但本地调试总卡在消息收发环节的工程师三是刚从 Mac 转 Win11 开发、怀念 Terminal 里brew install redis那种丝滑体验的用户。关键词 WSL2、MySQL、Redis、RocketMQ 不是并列关系而是层级依赖WSL2 是土壤MySQL/Redis 是基础养分RocketMQ 是需要精细灌溉的高价值作物——这篇内容就是给你一套可直接抄作业的耕作手册。2. 整体设计思路与方案选型逻辑为什么放弃 Docker Desktop 直接走原生 WSL2很多人看到“WSL2 部署中间件”第一反应是“那我直接用 Docker Desktop WSL2 启动容器不就行了”——这个想法很自然但实际踩坑率极高。我统计过过去半年团队内部提交的 37 个 WSL2 相关故障工单其中 21 个明确指向 Docker Desktop 与 WSL2 的协同问题。根本矛盾在于Docker Desktop 在 WSL2 模式下本质是“在 Linux 子系统里再跑一层虚拟化”它通过docker-desktop-data这个特殊 distro 管理镜像层而你的主 distro比如 Ubuntu-22.04和它之间存在文件系统隔离、网络命名空间割裂、systemd 支持残缺三大硬伤。举个具体例子当你用docker run -p 6379:6379 redis启动 RedisWindows 主机确实能通过localhost:6379访问但你的 Spring Boot 应用如果运行在 WSL2 的 Ubuntu 里比如用./gradlew bootRun启动它默认连接的是127.0.0.1:6379而这个地址指向的是 Ubuntu 自身的 loopback 接口并非 Docker Desktop 的容器网络。你得手动改成host.docker.internal:6379但这个 DNS 名在 WSL2 的/etc/hosts里并不自动解析需要额外执行echo 127.0.0.1 host.docker.internal | sudo tee -a /etc/hosts。更麻烦的是 RocketMQ它的 nameserver 和 broker 必须跨进程通信Docker Desktop 下你得分别启动两个容器并用--network host模式但这又会导致端口冲突nameserver 默认 9876broker 默认 10911最终不得不改源码重新编译。而原生 WSL2 方案彻底绕开这些弯路所有中间件直接安装在 Ubuntu 的 rootfs 里共享同一套网络栈和进程空间。MySQL 的 socket 文件/var/run/mysqld/mysqld.sock、Redis 的 pid 文件/var/run/redis/redis-server.pid、RocketMQ 的日志目录/opt/rocketmq/logs全部按 Linux 标准路径存放systemd 可以精准控制启停顺序比如要求 MySQL 启动成功后再启动 RocketMQ broker。工具链也回归简洁apt install mysql-server替代下载.msi安装包wget https://archive.apache.org/dist/rocketmq/4.9.4/rocketmq-all-4.9.4-bin-release.zip替代在官网翻找 Windows 版本systemctl enable redis-server替代写一堆.bat批处理脚本。最关键的是性能我们用 sysbench 对比过相同配置下 MySQL 的 OLTP 测试结果在 WSL2 原生部署场景QPS 稳定在 3200±50而 Docker Desktop 容器模式下波动剧烈2400~2900原因在于容器网络层多了一次 NAT 转发和 iptables 规则匹配。所以本方案的底层逻辑非常清晰用 WSL2 提供的轻量级 Linux 内核兼容层换取最接近物理机的中间件运行环境牺牲的是“一次构建到处运行”的幻觉换来的是开发调试阶段 90% 以上问题的可预测性与可复现性。这不是反 Docker而是分场景Docker 适合交付和测试环境WSL2 原生适合开发环境——就像你不会用 Kubernetes 集群跑单元测试一样。2.1 WSL2 发行版选择Ubuntu 22.04 LTS 是当前最优解发行版选择不是随便挑个最新版就行它直接决定后续中间件的兼容性和维护成本。我们排除了几个常见选项CentOS Stream 9 因为 EOLEnd of Life时间太短2024 年底且dnf包管理器对 MySQL 8.0 的依赖解析经常出错Debian 12 虽然稳定但其默认内核版本6.1.x对 WSL2 的AF_UNIXsocket 支持有已知 bug会导致 RocketMQ 的 remoting 框架在高并发下偶发连接重置Alpine Linux 则因 musl libc 与 glibc 的 ABI 不兼容让 MySQL 的某些存储过程函数如JSON_EXTRACT返回空值。最终锁定 Ubuntu 22.04 LTSJammy Jellyfish理由有三第一官方对 WSL2 的适配最完善微软文档明确标注其为“推荐发行版”内核补丁如wsl2-linux-kernel更新及时第二APT 仓库中 MySQL、Redis、OpenJDK 的版本组合最成熟mysql-server (8.0.33-0ubuntu0.22.04.2)、redis-server (6:7.0.15-1ubuntu0.22.04.1)、openjdk-11-jdk (11.0.227-0ubuntu2~22.04.1)全部经过 Canonical 工程师 QA 测试无已知冲突第三社区支持密度最高遇到冷门问题比如 RocketMQ 的brokerIP1自动识别失败时GitHub Issues 和 Stack Overflow 上的解决方案平均响应时间小于 2 小时。安装步骤严格遵循微软官方流程先在 PowerShell管理员权限执行wsl --install这会自动启用 WSL 功能、安装最新内核、设置默认发行版为 Ubuntu-22.04然后重启系统最后在 Microsoft Store 搜索 “Ubuntu 22.04” 并安装。注意一个关键细节不要用wsl --install -d Ubuntu-20.04这类命令指定旧版本因为 Ubuntu-20.04 的内核模块特别是wsl2-linux-kernel在 Win11 23H2 更新后存在内存泄漏 Bug实测连续运行 48 小时后 WSL2 进程占用宿主机内存超 3GB。安装完成后首次启动会要求设置用户名和密码这里建议用户名用dev避免用root安全规范密码设为强密码至少 8 位含大小写字母数字因为后续 MySQL 和 RocketMQ 的管理账户都会基于此用户派生。验证是否成功在 Ubuntu 终端执行cat /proc/version输出应包含Microsoft和WSL2字样执行ip a | grep inet确认eth0网卡获取到172.x.x.x段 IP这是 WSL2 虚拟交换机分配的地址后续 RocketMQ 配置要用到。2.2 中间件选型依据为什么是 MySQL 而非 PostgreSQL为什么是 RocketMQ 而非 Kafka中间件不是堆砌功能而是按需裁剪。标题里明确列出 MySQL、Redis、RocketMQ背后有严格的业务场景映射。先说 MySQL vs PostgreSQL虽然 PostgreSQL 在 JSONB、地理空间索引等高级特性上更强但国内互联网公司 80% 以上的 OLTP 场景仍以 MySQL 为主流。招聘 JD 中“熟悉 MySQL 索引优化”出现频率是“PostgreSQL 分区表”的 4.7 倍数据来源BOSS 直聘 2024 Q1 技术岗关键词分析。更重要的是MySQL 8.0 的caching_sha2_password插件与 WSL2 的 PAM 认证模块兼容性极佳而 PostgreSQL 的scram-sha-256在 WSL2 下偶发 handshake timeout这个问题在 Ubuntu 22.04 的postgresql-14包中仍未完全修复。Redis 的选择毫无争议它是唯一同时满足“高性能键值存储”“发布订阅模式”“Lua 脚本原子执行”三大需求的开源中间件且redis-server的二进制包在 Ubuntu APT 仓库中开箱即用无需编译。至于 RocketMQ vs Kafka标题里特意强调“音视频集群服务器中间件是否可行”这直指核心痛点。Kafka 的设计哲学是“高吞吐、弱一致性”其副本同步机制ISR在音视频直播场景下容易因网络抖动导致消息积压而 RocketMQ 的SYNC_MASTER刷盘策略和WAIT_STORE_MSG_OK发送模式能确保每条消息在主从 Broker 都落盘后才返回 ACK这对弹幕实时性、订单状态变更等强一致场景至关重要。另外RocketMQ 的 NameServer 架构比 Kafka 的 ZooKeeper 依赖更轻量——NameServer 本身无状态可水平扩展至百节点而 Kafka 集群规模超过 50 broker 时ZooKeeper 的 ZNode 数量爆炸式增长运维复杂度陡增。因此本方案的中间件组合是经过生产环境验证的“最小可行集”MySQL 解决结构化数据持久化Redis 解决高频读写与会话共享RocketMQ 解决异步解耦与事务最终一致性——三者叠加足以支撑一个中等规模电商后台的全部中间件需求。3. 核心细节解析与实操要点每个中间件的安装、配置与安全加固部署不是复制粘贴命令而是理解每个参数背后的业务含义。下面拆解三个中间件最关键的配置项它们决定了系统能否稳定运行、是否符合安全基线、能否顺利对接上层应用。3.1 MySQL 8.0.33 安全加固配置从默认安装到生产就绪Ubuntu 22.04 的apt install mysql-server默认安装的是 MySQL 8.0.33但它开箱即用的配置远未达到开发环境安全标准。首要问题是 root 用户的认证插件默认使用auth_socket这意味着 root 只能通过 Unix socket 登录即sudo mysql -u root而你的 Java 应用或 Python 脚本必须用密码登录这就需要切换为caching_sha2_password。操作分三步先用sudo mysql进入 root shell执行ALTER USER rootlocalhost IDENTIFIED WITH caching_sha2_password BY YourStrongPass123!;然后刷新权限FLUSH PRIVILEGES;最后退出。但这只是开始真正的安全加固在/etc/mysql/mysql.conf.d/mysqld.cnf文件里。重点修改四个参数第一bind-address 127.0.0.1必须保留禁止 MySQL 监听外部网络WSL2 的 eth0 网卡 IP 是给其他中间件用的不是给 MySQL 开放的第二max_connections 200这是根据 WSL2 默认内存约 2GB计算得出的合理值公式为max_connections ≈ (RAM_in_MB * 0.8) / 8避免因连接数过多触发 OOM Killer第三sql_mode STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION开启严格模式防止隐式类型转换导致的数据污染第四default_authentication_plugin caching_sha2_password确保新建用户默认使用强加密。还有一个易被忽略的细节MySQL 8.0 默认禁用local_infile防止恶意 SQL 注入读取宿主机文件但某些 ETL 工具需要它。如需启用必须在[mysqld]段添加local_infileON并在客户端连接时显式指定--local-infile1。最后创建一个专用开发用户CREATE USER devuserlocalhost IDENTIFIED BY DevPass456!; GRANT ALL PRIVILEGES ON *.* TO devuserlocalhost WITH GRANT OPTION;。注意WITH GRANT OPTION仅用于开发环境生产环境必须按最小权限原则授权。验证是否生效在终端执行mysql -u devuser -p输入密码后应成功进入执行SELECT USER(), CURRENT_USER();确认返回devuserlocalhost执行SHOW VARIABLES LIKE max_connections;确认值为 200。3.2 Redis 7.0.15 高可用配置单机模式下的伪集群实践Redis 在 WSL2 里通常以单机模式运行但这不意味着可以忽略高可用设计。标题中的“Redis”不是指简单起个服务而是要模拟生产环境的哨兵Sentinel或集群Cluster行为。我们采用“伪集群”方案在同一台 WSL2 实例中启动三个 Redis 实例端口 6379/6380/6381并配置 Sentinel 监控。这样做的好处是既避免了多 VM 的资源开销又能完整验证JedisPool或Lettuce客户端的故障转移逻辑。配置文件生成脚本如下保存为gen_redis_conf.sh#!/bin/bash for port in 6379 6380 6381; do cat /etc/redis/redis-$port.conf EOF port $port bind 127.0.0.1 ::1 protected-mode yes daemonize no pidfile /var/run/redis/redis-$port.pid logfile /var/log/redis/redis-$port.log dir /var/lib/redis dbfilename dump-$port.rdb requirepass YourRedisPass789! masterauth YourRedisPass789! EOF done执行sudo bash gen_redis_conf.sh生成三个配置文件。关键参数解读protected-mode yes强制开启保护模式防止未授权访问daemonize no是因为 WSL2 使用 systemd 管理进程Redis 必须以前台模式运行requirepass和masterauth设置统一密码这是 Sentinel 故障转移时主从切换的认证凭证。接着配置 Sentinel创建/etc/redis/sentinel.conf核心内容为port 26379 sentinel monitor mymaster 127.0.0.1 6379 2 sentinel auth-pass mymaster YourRedisPass789! sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 180000这里mymaster是主节点别名2表示需要 2 个 Sentinel 节点同意才触发故障转移我们只启一个 Sentinel所以设为 2 是为了强制它自己决策。启动顺序至关重要先sudo systemctl start redis-server6379主节点再sudo systemctl start redis-server6380从节点最后sudo redis-sentinel /etc/redis/sentinel.conf。验证执行redis-cli -p 26379 -a YourRedisPass789! SENTINEL get-master-addr-by-name mymaster应返回127.0.0.1 6379手动 kill 主节点sudo kill \$(cat /var/run/redis/redis-6379.pid)等待 5 秒后再次执行该命令应返回127.0.0.1 6380证明故障转移成功。3.3 RocketMQ 4.9.4 集群化部署Nameserver 与 Broker 的网络拓扑设计RocketMQ 是本方案中最复杂的中间件其难点不在安装而在网络配置。标题中“RocketMQ”特指能支撑“音视频集群服务器”的部署形态这意味着必须配置多节点 Broker 并正确设置brokerIP1。WSL2 的网络模型是关键它为每个 distro 分配一个独立的虚拟网卡eth0IP 地址属于172.16.0.0/12私有网段如172.28.16.1而 Windows 宿主机通过172.28.16.1访问 WSL2。因此RocketMQ 的brokerIP1必须设为这个地址否则 Windows 上的 Producer/Consumer 无法连接。部署步骤先下载rocketmq-all-4.9.4-bin-release.zip并解压到/opt/rocketmq然后创建两个 Broker 配置文件/opt/rocketmq/conf/broker-a.properties和/opt/rocketmq/conf/broker-b.properties。以broker-a.properties为例核心参数为brokerClusterName DefaultCluster brokerName broker-a brokerId 0 deleteWhen 04 fileReservedTime 48 brokerRole ASYNC_MASTER flushDiskType ASYNC_FLUSH brokerIP1 172.28.16.1 namesrvAddr 172.28.16.1:9876注意brokerIP1必须与ip a命令查到的 eth0 地址完全一致namesrvAddr指向同一个地址的 9876 端口Nameserver 默认端口。启动 Nameservernohup sh /opt/rocketmq/bin/mqnamesrv 启动 Broker Anohup sh /opt/rocketmq/bin/mqbroker -n 172.28.16.1:9876 -c /opt/rocketmq/conf/broker-a.properties 启动 Broker B配置文件中brokerName broker-b,brokerId 1。验证执行curl http://172.28.16.1:9876/namesrv/state返回{status:OK}执行sh /opt/rocketmq/bin/mqadmin clusterList -n 172.28.16.1:9876应显示DefaultCluster下有两个 Broker。此时Windows 上的 Java 应用只需配置namesrvAddr172.28.16.1:9876即可正常收发消息无需任何代理或端口转发。4. 实操过程与核心环节实现从零开始的完整部署流水线现在把前面所有细节串联成一条可重复执行的部署流水线。整个过程分为五个阶段环境初始化、MySQL 部署、Redis 部署、RocketMQ 部署、跨中间件联调。每个阶段都提供可直接复制的命令和参数解释。4.1 环境初始化WSL2 基础配置与依赖安装这一步是所有后续操作的前提必须严格按顺序执行。首先检查 WSL2 版本wsl -l -v确认 Ubuntu-22.04 的状态为Running且版本为WLS 2如果不是执行wsl --set-version Ubuntu-22.04 2。然后更新系统sudo apt update sudo apt upgrade -y。关键依赖安装有三项openjdk-11-jdkRocketMQ 运行必需java -version应输出11.0.22、net-tools用于ifconfig查看 IP、curl验证服务状态。特别注意 JDK 的环境变量配置编辑~/.bashrc在末尾添加export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH执行source ~/.bashrc生效。接下来创建统一工作目录sudo mkdir -p /opt/{mysql,redis,rocketmq}并赋予dev用户所有权sudo chown -R dev:dev /opt/*。这一步看似简单但能避免后续因权限问题导致服务启动失败比如 RocketMQ 日志目录不可写。最后为 WSL2 设置合理的内存限制防止它吃光宿主机资源。在 Windows 的%USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\wsl.conf文件中添加[wsl2] memory2GB processors2重启 WSL2wsl --shutdown然后重新打开 Ubuntu 终端。验证内存free -h应显示总内存约 2GB。这步至关重要因为 RocketMQ 的 JVM 堆内存默认是 4GB不调整会直接 OOM。4.2 MySQL 部署自动化配置与用户权限体系构建手动修改配置文件效率低且易出错我们用sed命令批量注入安全参数。执行以下命令# 备份原始配置 sudo cp /etc/mysql/mysql.conf.d/mysqld.cnf /etc/mysql/mysql.conf.d/mysqld.cnf.bak # 注入安全配置 sudo sed -i /^bind-address/c\bind-address 127.0.0.1 /etc/mysql/mysql.conf.d/mysqld.cnf sudo sed -i /^\[mysqld\]/a max_connections 200 /etc/mysql/mysql.conf.d/mysqld.cnf sudo sed -i /^\[mysqld\]/a sql_mode STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION /etc/mysql/mysql.conf.d/mysqld.cnf sudo sed -i /^\[mysqld\]/a default_authentication_plugin caching_sha2_password /etc/mysql/mysql.conf.d/mysqld.cnf # 重启服务 sudo systemctl restart mysql接着创建开发用户并授权。这里有个经验技巧不要用GRANT ALL ON *.*而是按模块精细化授权。例如为电商 Demo 创建ecommerce_db数据库并只授予devuser对该库的全部权限CREATE DATABASE ecommerce_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER ecommerce_applocalhost IDENTIFIED BY EcomAppPass001!; GRANT SELECT, INSERT, UPDATE, DELETE ON ecommerce_db.* TO ecommerce_applocalhost; FLUSH PRIVILEGES;这样即使应用代码存在 SQL 注入漏洞攻击者也无法跨库操作。验证mysql -u ecommerce_app -p -D ecommerce_db成功进入即表示授权正确。4.3 Redis 部署Systemd 服务文件编写与多实例管理Ubuntu 的redis-server包自带 systemd 模板但默认只支持单实例。我们要启用多实例需创建自定义 service 文件。以端口 6379 为例创建/etc/systemd/system/redis-server.service注意符号表示模板[Unit] DescriptionAdvanced key-value store %I Afternetwork.target [Service] Typenotify Userredis Groupredis ExecStart/usr/bin/redis-server /etc/redis/redis-%I.conf Restartalways RestartSec10 LimitNOFILE10032 [Install] WantedBymulti-user.target然后启用实例sudo systemctl daemon-reloadsudo systemctl enable redis-server6379sudo systemctl start redis-server6379。同理启用 6380 和 6381。检查状态sudo systemctl status redis-server6379应显示active (running)。这里的关键是LimitNOFILE10032它设置了 Redis 进程的最大文件描述符数避免高并发下Too many open files错误。计算依据是每个 Redis 连接占用 1 个 fd加上日志、RDB 文件等200 连接需约 300 fd10032 是留足余量的安全值。4.4 RocketMQ 部署Nameserver 与 Broker 的启动脚本封装手动执行nohup命令难以管理我们用 systemd 封装。创建/etc/systemd/system/rocketmq-nameserver.service[Unit] DescriptionRocketMQ Nameserver Afternetwork.target [Service] Typesimple Userdev WorkingDirectory/opt/rocketmq ExecStart/bin/sh -c sh /opt/rocketmq/bin/mqnamesrv Restartalways RestartSec10 [Install] WantedBymulti-user.target创建/etc/systemd/system/rocketmq-broker-a.service[Unit] DescriptionRocketMQ Broker A Afterrocketmq-nameserver.service [Service] Typesimple Userdev WorkingDirectory/opt/rocketmq ExecStart/bin/sh -c sh /opt/rocketmq/bin/mqbroker -n 172.28.16.1:9876 -c /opt/rocketmq/conf/broker-a.properties Restartalways RestartSec10 [Install] WantedBymulti-user.target启用并启动sudo systemctl daemon-reloadsudo systemctl enable rocketmq-nameserversudo systemctl start rocketmq-nameserversudo systemctl enable rocketmq-broker-asudo systemctl start rocketmq-broker-a。验证sudo journalctl -u rocketmq-nameserver -f实时查看日志出现The Name Server boot success.即成功。4.5 跨中间件联调Spring Boot 应用集成验证最后一步是验证整个链路是否打通。创建一个极简 Spring Boot 项目pom.xml关键依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.apache.rocketmq/groupId artifactIdrocketmq-spring-boot-starter/artifactId version2.2.3/version /dependencyapplication.yml配置spring: redis: host: 127.0.0.1 port: 6379 password: YourRedisPass789! datasource: url: jdbc:mysql://127.0.0.1:3306/ecommerce_db?useSSLfalseserverTimezoneAsia/Shanghai username: ecommerce_app password: EcomAppPass001! rocketmq: name-server: 172.28.16.1:9876 producer: group: demo-producer-group编写一个测试 ControllerRestController public class TestController { Autowired private StringRedisTemplate redisTemplate; Autowired private JdbcTemplate jdbcTemplate; Autowired private RocketMQTemplate rocketMQTemplate; GetMapping(/test) public String test() { // 写 Redis redisTemplate.opsForValue().set(test_key, test_value); // 查 MySQL String count jdbcTemplate.queryForObject(SELECT COUNT(*) FROM information_schema.tables WHERE table_schemaecommerce_db, String.class); // 发 RocketMQ rocketMQTemplate.convertAndSend(test_topic, Hello from WSL2!); return OK: Redis redisTemplate.opsForValue().get(test_key) , MySQL tables count; } }启动应用访问http://localhost:8080/test返回OK: Redistest_value, MySQL tables0即表示全部中间件联通。注意Windows 浏览器访问的是宿主机 localhost而 Spring Boot 应用运行在 WSL2 里所以127.0.0.1对它而言就是自身无需任何网络桥接。5. 常见问题与排查技巧实录那些官方文档不会写的血泪教训实际部署中90% 的问题都集中在网络、权限、配置三类。以下是我在 12 个不同客户现场踩过的坑附带一针见血的排查命令。5.1 MySQL 连接被拒绝不是密码错是 bind-address 搞鬼现象mysql -u devuser -p提示ERROR 2003 (HY000): Cant connect to MySQL server on localhost (111)。新手第一反应是密码错了但其实 80% 是bind-address配置问题。检查命令sudo ss -tlnp | grep :3306如果输出是127.0.0.1:3306说明只监听本地回环如果输出是*:3306说明监听所有接口不安全。正确状态应是127.0.0.1:3306。但如果这时还是连不上执行sudo tail -20 /var/log/mysql/error.log查找Aborted connection关键词。常见原因是max_connections设得太小日志会显示Too many connections。解决方案临时增大连接数sudo mysql -u root -p -e SET GLOBAL max_connections300;然后永久修改配置文件。5.2 Redis Sentinel 不切换masterauth 配置遗漏的连锁反应现象kill 主节点后SENTINEL get-master-addr-by-name mymaster仍返回原地址。执行redis-cli -p 26379 -a YourRedisPass789! SENTINEL masters发现num-slaves为 0。根源在于从节点配置文件中漏写了masterauth。排查命令redis-cli -p 6380 INFO replication | grep masterauth如果返回空说明没配置。修复编辑/etc/redis/redis-6380.conf添加masterauth YourRedisPass789!然后sudo systemctl restart redis-server6380。经验masterauth必须和requirepass值完全一致大小写敏感。5.3 RocketMQ Producer 连接超时brokerIP1 与 WSL2 网络的终极博弈现象Windows 上的 Producer 报org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to 172.28.16.1:10911 failed。这是 WSL2 最经典的网络谜题。根本原因是RocketMQ Broker 启动时会主动向 Nameserver 注册自己的 IP而默认注册的是127.0.0.1因为brokerIP1未设置。解决方案分两步第一步确认brokerIP1已正确设置见 3.3 节第二步检查 WSL2 的防火墙sudo ufw status如果显示Status: active执行sudo ufw allow 9876和sudo ufw allow 10911。但更隐蔽的问题是Windows 防火墙可能拦截了 WSL2 的出站连接。临时关闭 Windows 防火墙测试控制面板
