本地 WMS 看似误连生产：拆解 JDBC、Dubbo、Redis 与多 Tomcat 环境

一个本地 WMS 实例的 JDBC 配置明确指向测试数据库，但登录用户、权限和部分页面行为却像来自另一套环境。单看配置文件，很容易得出“应用偷偷连错数据库”的结论。

排查后发现，这类现象通常不是一个连接串覆盖了另一个连接串，而是同一个 Web 应用同时依赖多种数据来源：

• 业务数据通过 JDBC 访问数据库；
• 登录、用户和权限通过远程 UPM 服务取得；
• Dubbo 服务地址由注册中心或缓存决定；
• Redis 保存会话、权限或服务发现相关缓存；
• 本机还可能同时运行多个 Tomcat，每个实例加载不同的配置目录。

因此，业务列表来自测试库，并不代表权限也来自测试环境。

先确认真正处理请求的进程

第一步不是继续改配置，而是把端口、PID、Tomcat 基目录和 Java 命令行对应起来。浏览器访问的端口可能属于另一个仍在运行的实例；IDE 中刚启动的进程也可能并不是当前页面请求的接收者。

我把监听端口与进程逐一对应，并检查每个 Java 进程实际加载的 catalina.base、配置目录和外部连接。这个过程暴露出多实例并存：Web 入口和后台服务不是同一个 Tomcat，停止错误的进程只会让页面无法访问，并不会修复环境混用。

不要只检查 JDBC

确认 Web 入口后，排查范围转向运行时依赖。需要分别核对：

1. JDBC URL 和当前数据库中的业务数据；
2. 注册中心地址以及实际解析出的 Dubbo provider；
3. Redis 地址、命名空间和遗留缓存；
4. UPM 或单点登录服务的远程地址；
5. IDE 启动配置传入的系统属性和环境变量；
6. Tomcat 工作目录中是否残留旧配置或展开后的应用。

网络连接同样是证据。进程连接到哪些远端地址，比某个源码目录里的配置文件更能说明运行时事实。

恢复路径与可复用结论

正确做法是保留真正提供页面入口的 Web 实例，然后修正它加载的注册中心、Redis 和权限服务配置。重启前清理或隔离会影响服务发现的缓存，再用端口、进程命令行和实际远端连接验证结果。

这次排障让我再次确认：分布式系统中的“环境”不是一个数据库地址，而是一组必须保持一致的依赖。遇到数据与权限表现不一致时，应先画出请求经过的 JDBC、RPC、缓存和认证路径，再逐段证明当前连接到了哪里。只修改最显眼的配置文件，往往会掩盖真正的运行时分裂。