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

去年大促前一晚，我们做例行发布。CI/CD 流水线一把梭：kubectl rollout restart，30 个 Pod 滚动更新，5 分钟搞定。 结果第二天复盘时，运维同学甩过来三张截图： 网关日志：滚动更新期间 472 个 502 Bad Gateway，全是打在被重启的实例上 业务日志：3 笔订单状态更新了一半，扣了库存没写流水，DBA 手工对账到凌晨两点 MQ 后台：某 Topic 出现 2000+ 条重复消费，下游幂等兜底差点没扛住 根因说起来特别简单：K8s 给 Pod 的默认宽限期是 30 秒，超时后直接 SIGKILL。我们的应用既没开优雅停机，也没配 preStop，JVM 收到 SIGTERM 后根本没机会"把手头的事做完"——在途请求直接断、定时任务跑一半、MQ 消息没提交 offset。 这不是个例。只要你的服务跑在 K8s 上，滚动更新、扩缩容、节点驱逐，每一刻都可能触发"杀进程"。优雅停机就是给应用一个"临终遗嘱"的执行机会：先摘流量 → 再处理完在途请求 → 然后停任务 → 最后释放资源，全程 30 秒内干净退出。 这篇文章把我们踩过的坑和最终落地的....

引言 凌晨 3 点，值班手机第 137 次震动。迷迷糊糊划开一看，还是那条「磁盘使用率超过 80%」——同一块盘，Prometheus 每 30 秒评估一次，没人处理就一直报。 第二天早上复盘，最讽刺的一幕来了：真正的大故障恰恰发生在凌晨 4 点，一条 P0「订单服务全部实例下线」，被 137 条 P2 的重复轰炸彻底淹没。值班同学后来承认："我把告警群设成免打扰了，反正是磁盘告警。" 这不是个例。我们统计了自己环境的 30 天告警数据，结果触目惊心： 指标数值 日均告警条数24,187 条 单人单夜被通知次数平均 9.2 次 有效告警占比（需要人介入的）2.7% P0 告警平均响应时间11 分钟（且漏报 2 次/月） 97% 的告警是噪音。而噪音的代价不是"烦"，是把真正致命的告警稀释掉——这就是告警疲劳（Alert Fatigue）。 这篇文章把我们从 2.4 万条/天优化到 362 条/天的完整方案讲一遍，覆盖四块内容： 告警分级设计：P0（服务挂了）→ P1（P99 > 1s）→ P2（磁盘 > 80%），不同级别不同响应策略 AlertManager....

最近接触了几个面试，问到 "MySQL 怎么优化慢 SQL"，回答基本就一句话："加索引呗。" 再追问 "你怎么确定加哪个索引？Explain 的 type 字段有哪些取值？什么是 Using filesort？" 要么含糊其辞，要么干脆答不上来。 说实话，只会 EXPLAIN + SQL 然后盯着 key 字段看"有没有走索引"，这不算会用 Explain。Explain 输出的 12 个字段里藏着优化器的全部决策细节：SQL 先执行哪一部分、联合索引用了几个字段、排序走没走索引、临时表有没有产生——这些才是判断 SQL 性能瓶颈的关键。 今天这篇文章，把 Explain 的 12 个字段拆开来逐个讲，文末再放一道真实的 SQL 优化案例，带大家把学到的字段串起来用一遍。 一、执行计划长什么样？先有个整体印象 在任意一条 SELECT/UPDATE/DELETE/INSERT 语句前加上 EXPLAIN，MySQL 不会真的执行 SQL，而是返回优化器评估后的"执行计划"： EXPLAIN SELECT e.emp_name, d.dept_name FROM t_employe....

去年底团队把订单系统从 Spring Boot 2.7 升到 3.2，顺手加上了 spring.threads.virtual.enabled=true。 Release Note 写着"Tomcat 支持虚拟线程，吞吐提升 10 倍不是梦"，压测环境跑了几轮 QPS 确实从 800 干到了 6000+，高高兴兴上线。 结果上线第三天，下午 3 点高峰期： 监控看到数据库连接池疯狂告警（HikariPool-1 - Connection is not available, request timed out after 3000ms） 老年代 GC 从 2s 一次飙升到 30s 一次，P99 从 80ms 飙到 4 秒 某个支付接口报 OutOfMemoryError: Direct buffer memory 回滚 + 紧急排查，最后定位下来全是虚拟线程的"典型坑"。有的是旧代码换虚拟线程后隐性问题显性化，有的是思维没转过来还按平台线程那套写。 这篇文章把 5 个我们线上踩过、且社区反复有人问的坑逐一展开，每个坑都有：症状 → 根因 → 复现步骤 → 修复方案 → 生产数据对比。....

引言 打开你们项目的 git log，大概率是这样： a3f2b1c fix bug 7c8d9e1 update 2b4f5a6 修改 9e1c3d7 xxx 5d6a7b8 修复订单问题 3f8c9d0 2024-01-15 update 这种 commit message 有什么问题？ "fix bug" —— 修的哪个 bug？怎么修的？ "update" —— 更新了什么？文档还是代码？ "修改" —— 改的哪里？ "xxx" —— ？ 半年后排查线上问题，需要 git bisect 定位是哪次提交引入的 bug，看到一堆 "fix bug" 直接崩溃。 commit message 不是写给自己的，是写给团队和未来的自己看的。 这篇文章从规范到自动化，讲透一套完整的 commit message 方案： Conventional Commits 规范：feat/fix/chore 等类型含义 commitlint：自动校验，不规范不让提交 husky：把校验挂到 git hook commitizen：交互式生成规范 message standard-version....

引言 面试题：为什么不用本地缓存？答：分布式系统都用 Redis。 但现实是——很多场景本地缓存仍然是刚需： 配置数据、字典数据——QPS 高但极少变更，每次走 Redis 多一跳网络 热点商品信息——Redis 也会被打爆，本地缓存兜底 计算结果缓存——复杂的统计结果，本地存一份避免重复计算 Java 生态里三大本地缓存各有拥趸： Guava Cache——老牌选手，曾经的王者 Ehcache——老牌中的老牌，功能最全 Caffeine——新生代，号称"Guava Cache 的替代品" 到底选谁？社区争论很多，但缺少实测数据支撑。 这篇文章从 6 个维度做实测对比：读写吞吐、内存占用、过期策略、淘汰算法、Spring Cache 集成、异步加载。每个维度都有压测数据，看完你心里就有答案了。 一、三巨头简介 1.1 Guava Cache 出身：Google Guava 工具库的一部分，2010 年左右推出。 定位：简单易用的进程内缓存，API 设计优雅。 特点： API 简洁，CacheBuilder 链式调用 支持 TTL、TTI、基于引用的回收 支持 CacheLo....

引言 现在一说 IDEA 插件，第一反应都是 GitHub Copilot、Cursor 这些 AI 补全工具。但 AI 再强，也只是替你写代码——真正卡效率的，往往是那些"机械重复"的小事： Mapper 接口和 XML 来回切，找半天对不上 想找某个 REST 接口，全局搜索搜出一堆无关代码 字段名驼峰转下划线，手动改一行改一次 Maven 依赖冲突报错，看 dependency:tree 看到眼花 同事写的代码括号嵌套五层，根本看不清配对 这些事 AI 帮不上忙，但下面这 8 个 IDEA 插件能。每个都是装上立刻见效、用过就回不去的类型。 一、MyBatisX：Mapper 和 XML 一键跳转 痛点 MyBatis 开发最烦的事： OrderMapper.java ← 接口 OrderMapper.xml ← 实现 写代码时来回切： 接口里写 selectById → 切到 XML 写 SELECT * FROM ... → 切回接口看参数类型 → 切到 XML 看字段名 原生 IDEA 没有这俩文件的关联，全靠肉眼对齐方法名。 MyBatisX 能做什么 1. 一键....

引言 社区都说虚拟线程（Virtual Threads）是"性能革命"，JDK 21 GA 后无数文章吹爆： "Virtual Threads 让你的吞吐提升几十倍！" "线程池要被淘汰了！" "100 万并发不是梦！" 但真到自己落地时，发现一堆疑问： 我们的业务场景到底能不能提升？ CPU 密集场景到底有没有用？ 线程池调到 500 够不够，虚拟线程真的完爆它吗？ 高并发短任务和长连接场景表现一样吗？ 光看官方 Benchmark 没用，得自己压一遍。这篇文章我用 10,000 并发，在 5 个真实业务场景下，对三种方案做横向对比： 传统线程池（200 线程） 传统线程池（500 线程） Virtual Threads 每种场景压 10 分钟，记录 QPS、P99 延迟、CPU、内存。看完这篇，你会清楚知道你的场景该不该上虚拟线程。 一、压测方案设计 1.1 测试环境 项目配置 CPU8 核 16 线程（Intel i7-12700H） 内存32GB DDR4 JDKOpenJDK 21.0.2 应用Spring Boot 3.2 + Virtual Thre....

引言 线上事故复盘： OrderMapper.xml 中有一行 SQL： SELECT * FROM order WHERE user_id = #{userId} 半夜上线后报错：You have an error in your SQL syntax 原因：`order` 是 MySQL 关键字，应该加反引号 `order` 这种错误你大概率遇到过。MyBatis 把 SQL 写在 XML 里，本质上还是字符串拼接——表名错了、字段名错了、参数类型错了，只有运行时才暴露。 有没有办法在写代码时就发现这些错误？有——用 jOOQ。 jOOQ（Java Object Oriented Querying）把数据库表映射成 Java 类，用 DSL（领域特定语言）写 SQL，编译期就能检查表名、字段名、类型。IDE 自动补全，重构跟着改，错字段直接红线。 本文对比 MyBatis 和 jOOQ，从代码生成到实战 CRUD、复杂联表、动态条件、事务，最后附 Spring Boot 集成配置和常见坑。 一、MyBatis 的痛点：SQL 是字符串 1.1 字符串拼接的代价 <!-- ....

引言 线上告警炸了： [P1] MySQL CPU 100% [P1] 应用接口 P99 5s [P1] 数据库连接池打满 打开 Grafana一看： Redis 命中率从 95% 掉到 30% MySQL QPS 从 2 千飙到 8 万 应用线程池全满 典型的缓存失效问题。但具体是哪种？ 缓存失效有三种典型形态——穿透、雪崩、击穿，每个都能让数据库瞬间崩溃，但原因和解决方案完全不同。 这篇文章把三个真实事故合并在一起复盘，每个坑附事故场景、排查过程、代码方案。看完这篇，下次再遇到你能 5 分钟定位是哪一种。 一、先搞清三个坑的区别 很多人把这三个概念搞混。一张表说清： 概念现象根因典型场景 穿透查的数据在缓存和 DB 都没有数据不存在恶意攻击、爬虫乱查 ID 雪崩大量缓存同时失效过期时间相同批量预热后统一过期 击穿单个热点 Key 失效瞬间热点 + 过期秒杀商品、首页推荐 记忆口诀： 穿透：查没有的 → DB 被"打穿" 雪崩：集体失效 → DB 被"压塌" 击穿：热点失效 → DB 被"击穿" 二、事故一：缓存穿透——压垮 DB 的隐形杀手 2.1 事故复盘 ....

引言 性能优化是后端开发永恒的命题。从 GC 停顿到内存诊断，从缓存到向量计算，每一项技术进步都直接影响着线上服务的稳定性。 本周性能优化领域有 3 件事值得每个服务端开发者关注：JDK 23 把 ZGC 停顿压到了亚毫秒级、Redis 8.0 引入向量搜索、async-profiler 3.0 终于能看懂 Virtual Threads 了。每件事背后都是性能优化方法论的一次升级。 一、JDK 23 早期构建版发布，ZGC 停顿压缩至亚毫秒级 1.1 事件概览 JDK 23 早期构建版（EA Build）发布，最值得关注的是 ZGC（Z Garbage Collector） 的进一步优化： 停顿时间压缩至亚毫秒级（< 1ms） 即使堆内存达到 16TB，GC 停顿仍稳定在亚毫秒 STW（Stop-The-World）阶段更少 1.2 为什么值得关注 GC 停顿是 Java 应用最大的性能痛点之一： 场景传统 GC 的影响 高 QPS 接口单次 200ms GC 停顿 → 瞬间丢几千请求 实时推荐系统GC 停顿导致响应抖动，用户体验下降 金融交易系统GC 停顿直接卡....

引言 JDK 21 把虚拟线程（Virtual Threads）正式 GA 了，社区里一片"革命""颠覆""未来已来"的声音。 但你可能还有疑问： 虚拟线程不就是 Go 的 goroutine 吗？Java 抄作业而已？ 它和原来的 Thread 有什么本质区别？ 为什么都说 IO 密集场景能提升几十倍吞吐？凭什么？ 要讲清这些，必须从操作系统的线程模型说起。这篇文章不堆源码，用图解 + 伪代码讲透三件事： 传统 Java 线程为什么贵 虚拟线程是怎么"凭空"造出几百万个的 Continuation + ForkJoinPool 是怎么把 IO 等待变成免费的 看完这篇，你会真正理解为什么这是一次"革命"，而不是"小修小补"。 一、操作系统线程模型：1:1 不是 Java 的选择，是历史包袱 1.1 三种线程模型 操作系统理论上支持三种线程模型： ① 1:1 模型（Kernel-level Thread，内核线程） ┌──────────┐ ┌──────────┐ ┌──────────┐ │ User T1 │ │ User T2 │ │ User T3 │ └────┬....

引言 运营小妹发来消息："帮我导出最近半年的订单数据，要 Excel 格式，有 1000 多万条。" 你自信满满："小意思，十分钟搞定。" 启动导出任务，看了一眼进度条，2 分钟后接口直接挂了。 查看日志： java.lang.OutOfMemoryError: Java heap space 堆内存飙到了 4G，GC 把 CPU 跑满，服务假死。 你又试了试加 -Xmx8g——这次撑了 5 分钟，还是挂了。 这就是大数据导出的典型坑：MyBatis 默认一次性把结果加载到内存，1000 万条订单 × 每条 50 个字段 ≈ 5-8 个 G，直接爆。 本文从踩坑的代码出发，一步步演进到最终方案： MyBatis 流式查询 → ResultHandler 逐条处理 → CSV 分片 → SXSSF 流式 Excel 内存：4G → 200M。 一、踩坑现场：传统导出为什么 OOM 1.1 传统写法 @Service public class OrderExportService { @Autowired private OrderMapper orderMapper; /** * 运....

引言 凌晨两点告警炸了，打开 ELK 想查日志： Loading... Loading... Loading... Timeout. Kibana 加载 30 秒才出结果，ES 节点 CPU 100%，磁盘又满了。 每次扩容都是加节点、加磁盘、加内存，运维成本高到离谱。 ELK 是好东西，但对中小团队来说太重——Elasticsearch 索引全部日志内容，光存储就是一笔大开销，再加上 JVM 调优、集群维护，运维同学直呼"养不起"。 有没有更轻量的方案？有。Loki + Promtail + Grafana——Grafana Labs 出品的"日志版 Prometheus"，只索引标签不索引全文，存储成本直接砍 80%，还能和 Grafana 无缝集成，在同一面板看 Metric + Trace + Log。 本文从零搭建一套完整的日志平台，附 docker-compose 一键部署 + Spring Boot 接入 + LogQL 查询实战。 一、为什么选 Loki 不选 ELK 1.1 ELK 的痛点 ELK = Elasticsearch + Logstash + Kiba....

引言 面试现场，面试官抛出经典问题："分布式事务怎么保证一致性？" 90% 的候选人脱口而出："2PC 和 TCC。" 面试官追问："你项目里用的哪个？" 候选人："……了解过原理，没用过。" 这篇文章不讲理论，只讲实战。从一个转账场景出发，带你走完 2PC 的坑、TCC 的重、最后落地 Seata AT 模式——对业务零侵入，自动回滚，这才是生产环境真正在用的方案。 一、问题背景：跨服务转账 1.1 场景描述 用户 A 向用户 B 转账 100 元，涉及两个服务： 转账服务（Transfer Service） ├── 账户服务 A（Account Service A）：扣减 A 的余额 └── 账户服务 B（Account Service B）：增加 B 的余额 两个服务连的是不同的数据库，本地事务管不了跨库操作。 1.2 问题在哪 @Service public class TransferService { @Autowired private AccountServiceA accountServiceA; // RPC 调用 @Autowired private Acco....