服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

一、凌晨三点的告警 凌晨 03:15，手机突然震动。 【告警】服务 CPU 使用率达到 99.8% 实例：order-service-01 时间：2026-07-11 03:15:32 持续：已超过 5 分钟 我猛地从床上坐起来，打开笔记本电脑。凌晨三点，应该是定时任务在跑。登录到服务器，看到监控面板上 CPU 红线像心电图一样笔直。 问题已经发生了，现在需要冷静分析。 二、Arthas 排查：定位热线程 登录服务器，启动 Arthas： $ java -jar arthas-boot.jar * [1]: 12345 order-service.jar 选择进程 1，进入 Arthas 控制台。 2.1 dashboard：全局视图 $ dashboard ID NAME STATE %CPU TIME INTERRUPTED DAEMON 1 main RUNNABLE 0.0 0:01 false true 2 GC task thread#0 RUNNABLE 0.0 0:00 false true ... 25 pool-1-thread-1 BLOCKED 0.0 0....

凌晨两点，报警群里炸了。 "订单服务三台机器磁盘使用率全部超过 95%，其中一台已经 99%。下单接口开始超时，用户付不了款了。" 我迷迷糊糊掏出手机看了一眼，心头一紧。这是线上大促前夕，每秒几千单的交易量，磁盘满了意味着日志写不进去、服务随时可能挂掉。 赶紧登上服务器一看，/data/logs 目录占了整整 230G。顺着 du 一层层摸下去： /data/logs/slow-sql/ ├── 2026-06-20.log 68G ├── 2026-06-19.log 61G ├── 2026-06-18.log 55G └── ... 好家伙，慢 SQL 日志每天能写六七十 G。 我们慢 SQL 阈值设的 500ms，全量记录每一条慢查询的完整 SQL、执行时间、调用堆栈。业务高峰期每秒几千个查询，大促期间并发一上来，哪怕只有 5% 的 SQL 超过 500ms，每天就是几百万条记录。 那一刻我突然意识到一个问题：我们到底需要记录这么多慢 SQL 吗？ 一、全量记录的代价，不光是磁盘 回过头来看，全量慢 SQL 日志的代价远比磁盘空间要大： 磁盘 IO 争抢。 每一条慢 SQL....