阅读全文

一次自己修出来的线上事故

上一篇复盘了插件内存泄漏的修复。修完打包、安装、验证——一切正常。两天后用户反馈：插件的 i18n Inlay 功能整体消失了，一个都不剩。

更迷惑的是：功能是”全有或全无”式消失，不是部分失效。这种症状通常指向初始化链路被拦腰截断，而不是散点的功能 bug。

这篇文章复盘这次自己引入的事故：一个后台线程上的 read-action 断言异常，如何静默杀掉整个功能域——以及为什么这类异常在开发时根本看不见。

阅读全文

需求：让框架式调用也能双向跳转

业务代码里大量存在这种框架式调用——方法名藏在字符串字面量里：

1
2
3
4

// MyBatis 风格：字符串 = Dao 接口方法名
bizCommonService.queryDaoDataT(iOrderDao.getClass(), iOrderDao, "getOrderScheduleList", params, builder);
// MOC 风格：字符串 = XML 定义名
bizCommonService.insertMocData("OrderMoc", data);

IDE 原生对这种字符串无能为力。插件的诉求是四向导航：

这篇文章记录实现过程中的三次架构演进——每一次都是被真实现象（选择框不弹、进度条死循环、几万文件搜索）逼出来的重新设计。

阅读全文

背景：装了插件的 IDEA 卡到不能用

团队自研的 IDEA 插件更新后，出现了一个很诡异的症状：什么都没做，只是打开了几个文件，IDEA 就卡得不行。CPU 风扇狂转、界面掉帧、时不时冻结几秒。

比”卡”更有价值的是手里的 GC 数据。连续抓了几轮 jstat -gcutil：

1
2
3
4
5

S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
-  97.51  64.81  80.44  98.34  95.20     87    3.696     2    1.680    5.376
-  97.51  80.00  81.08  98.34  95.20     87    3.696     2    1.680    5.376
-  93.79  34.87  77.83  98.34  95.20     88    3.710     2    1.680    5.391
-  96.33   6.67  77.70  98.34  95.18     92    3.781     3    2.320    6.101   ← FGC 2→3

只看数字就能拆出三层信号。这篇文章完整复盘这次排查：从 jstat 解读、到沿执行路径找代码证据、到三类修复的设计与验证。

阅读全文

老 MES 系统里”导出”大概是最容易被低估的功能：早期数据量小，一个同步接口把数据查出来写成 Excel 直接回传，皆大欢喜。等到单表日志类数据涨到千万行、报表动辄几十万行时，这条链路开始连环爆雷。本文记录一次完整的导出链路改造：从同步超时丢文件，到「提交即返回 + 游标流式读取 + 异步写入 + 桌面通知取件」的全套架构，包括关键实现细节、踩过的每一个坑，以及清楚留着的优化债。

一、同步导出的四宗罪

改造前的链路是典型的”一把梭”：

1

用户点导出 → 请求线程分页循环查全量 → 攒成大 List → 写 Excel → HTTP 响应回传

数据量上来后暴露的问题按出现频率排序：

1. 网关超时：内部走 Ribbon/Zuul 网关，读超时默认 10 秒，导出耗时一超，连接被网关掐断——用户拿到半个文件或一个报错页；
2. 内存压力：全量行同时驻留 JVM 堆（List<Map> + 写缓冲），几个人并发导出大报表，堆直接见顶；
3. 体验差：用户必须挂着页面等，手一抖刷新就前功尽弃；
4. 不可回溯：一旦超时，服务端即便把文件写出来了也没法交给用户，白白浪费一次全量查询。

期间打过一层补丁：同步导出超时后转后台继续写，完成后上传文件、发通知。这解决了一部分问题，但”用户先同步等 30 秒”的体验和分页翻页式读取的额外开销还在。于是有了这次彻底的改造。

阅读全文

背景

MES 系统的预警发送日志表 biz_notify_send_log 长到了 28GB。它记录每条预警消息的发送流水，只增不减，而业务实际只需要查询最近一段时间的数据。表太大带来一串连锁问题：

• 磁盘空间告急；
• 带全表扫描的查询越来越慢；
• 之前分析过的一次服务假死事故里，多级预警任务扫这张表的日志表 biz_notify_send_level_log 也是内存压力的来源之一——日志类的表就该保持”瘦”。

目标很明确：只保留近 30 天 + 当天的数据，扔掉历史包袱，并且全程不停机（生产库，7×24 有预警在写入）。

阅读全文

事故背景

下午两点半左右，本地开发环境的 MES 辅助服务（app-assist）”挂了”——接口无响应、日志停更。但排查发现：进程根本没死，端口还在监听。它陷入的是一种比崩溃更迷惑的状态——假死。

这篇文章完整复盘这次诊断，并借机把涉及的 JVM 基础概念（堆、分代、GC、晋升、物化）融会贯通地讲一遍。读完你会发现，所有现象都能用同一套逻辑串起来。

阅读全文

仅修改某个类的实现逻辑或修复bug而不重新编译构建整个项目时，可以使用命令行工具手动替换class文件。

阅读全文

事故直接原因

1

pv dengqimes_20250519_144357.sql | mysql --database=dengqimes-test --user=zy_mes -pr4UQBwBV --host=127.0.0.1 --port=3306  --default-character-set=utf8mb4

使用 pv | mysql的组合，老版mysql在shell命令处理参数时，会忽略 dengqimes-test 中的 -，导致实际上mysql将备份还原到了数据库 dengqimes 上。而正式环境和测试环境数据库名恰好仅用-加后缀进行区分。

• “pv | myslq 版本演示”

阅读全文

要实现的效果

要实现 所有客户端请求路径 最终在后端统一映射到 /J5BfNtYvHW/api，可以通过以下两种方案实现：

1. 双路径代理（无重写）
2. 路径重写

方案一：路径重写（推荐）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

server {
    listen 443 ssl http2;
    server_name 3xui2.vaetech.uk;
    ssl_certificate /etc/nginx/ssl/origin/vaetech.uk.pem;
    ssl_certificate_key /etc/nginx/ssl/origin/vaetech.uk.key;

    # 处理 /J5BfNtYvHW 路径的请求
    location /J5BfNtYvHW/ {
        # 重写路径：保留原始请求路径
        proxy_pass http://127.0.0.1:54321/J5BfNtYvHW/;  # 末尾斜杠是关键
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # 处理根路径的请求
    location / {
        # 重写路径：强制添加前缀 /J5BfNtYvHW
        rewrite ^/(.*)$ /J5BfNtYvHW/$1 break;  # 通过 rewrite 添加前缀
        proxy_pass http://127.0.0.1:54321;      # 直接转发到后端根路径
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

路径映射效果：

方案二：双路径代理（无重写）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

server {
    listen 443 ssl http2;
    server_name 3xui2.vaetech.uk;
    ssl_certificate /etc/nginx/ssl/origin/vaetech.uk.pem;
    ssl_certificate_key /etc/nginx/ssl/origin/vaetech.uk.key;

    # 处理 /J5BfNtYvHW 路径的请求
    location /J5BfNtYvHW/ {
        proxy_pass http://127.0.0.1:54321/J5BfNtYvHW/;  # 保留原始路径
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # 处理根路径的请求
    location / {
        proxy_pass http://127.0.0.1:54321/J5BfNtYvHW/;  # 强制添加前缀
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

路径映射效果