一套 Spring Cloud 微服务 MES 里，一个”检验暂存”接口突然全量报错。报错很吓人：MyBatis 抛 BadSqlGrammarException，底层是 MySQLSyntaxErrorException: You have an error in your SQL syntax——语法错误，直指 mapper 写错了。但这条 SQL 在代码库里已经跑了很久，一行没改，而且”之前测试都是正常的”。

事后看，SQL 本身没有任何问题，问题出在 JDBC 连接串：换数据库时给 database.url 加了一个 ?sslMode=DISABLED 参数，和公共配置里追加的 ?allowMultiQueries=true 拼出了两个问号。驱动解析 URL 时只认第一个问号，第二个问号后面的整段参数被吞进前一个参数的值里——allowMultiQueries 这个键从未存在过，静默回退默认值 false，所有多语句 SQL 集体阵亡。

这个坑的迷惑性在于三层错位：报错在 mapper 层，根因在配置层；丢失的参数只有一个，其余功能全部正常；配置改完不会立刻炸，等到服务重启那天才引爆。这篇复盘把三层错位逐一拆开，重点讲清楚多语句 SQL 为什么天生依赖连接参数、双问号是怎么静默废掉它的。

阅读全文

本地开发环境的 MES（Spring Boot + EasyUI 微服务架构，部署在内网）突然报错：基础数据页点「下载导入模板」，接口抛 jcifs.smb.SmbAuthException: Access is denied.（jcifs 1.3.17）。模板存在文件服务器的 SMB 共享里，这行异常有两种完全不同的解读——“你的凭据我认了，但你不能进来”（授权问题），还是”你根本不是你”（认证问题）。两种解读指向的修法天差地别。

这类报错最怕一步跨错：看到 Access denied 就去改密码、重置账号、怀疑 NTLM 版本，改一圈发现方向全错。这次排查没有赌任何一个”想当然”的修复，而是用一个 20 行的 Java 探针把三种假设（账号密码错 / NTLM 协商不兼容 / 单共享 ACL 漏授权）逐一拆开，最后锁定第三种——文件服务器上单个共享目录漏了给服务账号授权，一条 icacls 修完当场生效，服务重启都不用。

这篇复盘完整定位过程，重点讲三个可复用的手法：denied 与 absent 的语义区分、同账号跨共享对比、修复后验证到与报错完全相同的操作层。

阅读全文

上一篇排查实录里（订单同步5分钟还锁死邻居接口），为了定位一个多语句大事务里到底哪条 UPDATE 吃掉了 300 秒，我用的第一步工具是 MySQL 内置的 profiling——一段 SET profiling = 1 加 SHOW PROFILES，给脚本里的每条 SQL 单独计时。有读者说从没接触过这个东西，这篇就把它从零讲透：五分钟上手、逐列读懂输出、以及几条不踩不知道的边界——包括它为什么测得出语句耗时、却测不到我最终要找的锁。

阅读全文

生产环境的数据同步服务连续报了三件事：ERP 订单同步单个任务跑了 317 秒；任务执行期间，产品同步接口直接 Lock wait timeout（等锁 50 秒超时）；再往前翻，还有一次 200 秒级别的死锁，innodb 状态转储里躺着 95 万行锁。三件事指向同一片代码，但三次现场的长尾耗时各不相同——130 秒、305 秒、317 秒，波动大得像玄学。

排查下来是两层问题叠在一起，彼此掩护：

1. 代码里满屏的 @Async 是个摆设——整个模块没有 @EnableAsync，所有”异步任务”实际同步跑在 Tomcat 的 HTTP 请求线程里；
2. 一张 2000 行的小表没有二级索引，让一条多表 JOIN 的 UPDATE 走了全表锁定读，3000 行的批次锁了 9.3 万行。

最终修复只有两条 DDL 和一个配置类，本地实测单步耗时 48.9 秒 → 0.33 秒（约 150 倍），生产 7568 单全量同步从 317 秒回到 15.2 秒。这篇完整复盘两层问题的发现过程——尤其是中间那次”所有 EXPLAIN 都是毫秒级”的证据反转，差点让排查拐进死胡同。

阅读全文

“服务挂了为什么 Eureka 页面上还显示 UP？”、”自我保护的 85% 到底是怎么算出来的？”、”一个服务下线了，调用方最长要多久才感知到？”——这几个问题在面试和线上排查里出现频率极高，但多数回答停在”心跳续约、默认 30 秒”这一层。这篇直接拆开 Eureka 的源码（Netflix eureka-client / eureka-core 1.9.8，对应 Spring Cloud Greenwich 版本线，本地 maven 仓库的 sources 包就是最好的阅读材料），把注册、心跳、下线、剔除、自我保护、多级缓存、增量拉取、集群复制这条完整链路全部走一遍，每个结论都落到具体的类与方法上。

先给一个能贯穿全文的坐标系：Eureka Server 本质上是一个纯内存的租约登记表 + 一组围绕它运转的定时任务。理解了”注册表数据结构、租约的过期语义、缓存的刷新节奏”这三件事，所有”灵异现象”都能对号入座。

阅读全文

个人项目发版本这件事，很容易一直停留在手工作坊阶段：改完代码本地跑一遍打包脚本、手动改名带版本号、开浏览器传 GitHub Release、版本号在 package.json、标签、产物文件名里各写一遍——忘了哪处就漂移。本文以一个真实项目为例，把发版动作收敛成两条 git 命令：任意分支 git push 自动构建出产物（artifact 下载），git push --tags 推一个 v* 标签自动校验版本、构建并创建 GitHub Release。项目形态是 Node 全栈（Vue 3 前端 + Express 后端，Node 22 SEA 打包成 Windows 单文件 exe），但流水线设计与语言无关，照搬即可。

阅读全文

上一篇文章复盘了一次备份链静默断裂 33 天的事故，并给出了翻修后的自动备份脚本全文。但复盘解决的是"为什么这么写"，真正落地时还有一整串问题：生产环境是**离线的 CentOS 7**，装不了公网仓库；XtraBackup 必须和 MySQL 5.7 严格配套；压缩备份的解压依赖 qpress；脚本在 Windows 上编辑过带着 CRLF；定时任务怎么和已有的维护窗口错峰……本文是姊妹篇，从一台裸机开始，把整套物理备份体系装起来：**RPM 离线安装 → qpress → 脚本部署与配置 → 钉钉告警 → 首跑验证 → 定时任务 → 恢复演练**，照着走一遍，半小时落地。

阅读全文

凌晨两点的定时备份，天天在跑、日志天天在写、备份目录天天生成——直到需要恢复的那一刻，才发现最后一个能用的恢复点停在 33 天前。

这是一套跑了很久的 CentOS 7 + MySQL 5.7 + Percona XtraBackup 2.4 组合：每周一次全量、每日增量、qpress 压缩、凌晨 cron 自动执行，看上去是教科书级的配置。但从 8 月 7 日起的每一次备份都失败了，而失败只安静地躺在日志文件里——没有任何推送、任何告警。根因是备份窗口撞上了 MySQL 5.7 免 redo 的在线 DDL，XtraBackup 主动中止；旧备份脚本的几个设计缺陷，又把”一次本可以重试的自中止”放大成了”静默断裂一个月”。

本文完整复盘这次事故，并给出一套翻修后的生产级备份脚本：基准有效性校验、DDL 窗口自动重试、半成品清理、链式维护、钉钉结果推送、本机防呆——外加一个很多人不知道的大坑：xtrabackup 的 --host 参数只是”协调端”，要备份的数据永远从本机磁盘复制。

阅读全文

本地开发环境用一键脚本把整套微服务拉起来：网关、注册中心、认证、门户、几个业务服务。打开首页，能正常出登录页、能登录、主框架渲染出来——然后页面上的数据接口开始报错，字典、多语言资源全部拉取失败。直觉说”看网关日志”，打开一看：

网关日志从启动到现在，零 ERROR、零 Exception，干干净净。

日志无罪、配置没改过、代码没动过，这种”环境性灵异故障”最考验排查方法论。最终根因落在一个完全意料之外的地方：网关进程带着 JRebel agent 启动，导致 Zuul 路由表的绑定顺序被打乱，兜底路由抢走了所有通配子路由。整场排查没有看一行 Zuul 源码仓库、没有重启大法、没有玄学，靠的是判别实验、字节码反编译和一个很多人没用过的 JDK 自带工具——jdb。这篇完整复盘整个过程，并把用到的工具逐一讲透。

阅读全文

有东西被加密了, 请输入密码查看.

阅读全文