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

公司一个微服务，启动一次要两分多钟。每次发布都是煎熬——CI/CD 等两分钟，滚动更新每起一个新 Pod 又是两分钟，发个版十分钟起步。他们以为是 Spring Boot 就这样，直到有一天我在控制台加了一行 -Dspring-startup-analyzer，发现有个 Bean 的 @PostConstruct 里竟然在同步加载全量字典数据，光它一个就花了 40 秒。 Spring Boot 启动慢这件事，大多数时候不是你 Bean 太多，而是有几个 Bean 初始化的时候干了不该干的活。今天聊聊怎么把这几颗老鼠屎找出来，以及怎么做懒加载优化。 先定位：到底是哪些 Bean 在拖后腿 Spring Boot 启动慢，第一件事不是优化，是找到瓶颈。没有数据支撑的优化就是瞎改。 最简单的方式：Spring Boot Actuator 的 Startup 端点 Spring Boot 2.4+ 内置了一个 ApplicationStartup 机制。在配置文件里开一下就能用： # application.yml spring: application: startup: step-rec....

大促的时候，运营在首页挂了一个爆款商品。瞬间几十万用户涌进来，同一个商品详情接口被疯狂调用。Redis 里这个商品的缓存 Key 被打到单节点 QPS 上限，响应时间从 1ms 飙升到 50ms，Redis 线程池打满，带着其他 Key 的请求也一起慢了。一块热铁掉进水里，整锅水都烫了。 这就是典型的热点 Key 问题。一个 Key 太热，把 Redis 单节点打穿了。因为 Redis 是单线程处理命令的，一个慢不会拖累别的，但如果请求量超过这个单节点的处理能力上限，所有请求都得排队。 今天聊聊怎么用 Caffeine 本地缓存做二级缓存，配合过期时间抖动防止缓存雪崩。 热点 Key 为什么难搞 先搞清楚热点 Key 的问题本质。正常缓存访问是这样的： 请求 → Redis → 命中 → 返回（1ms） 热点 Key 的情况下： 1000 个并发请求 → Redis 同一个 Key │ └─ 1000 次网络 IO（即使是 Redis，单节点也有处理上限） 问题不在"数据能不能被缓存"，而在"所有请求都打到了同一个 Redis 节点上"。如果你的 Redis 是集群模式，这个热点....

去年双十一，隔壁组出了个事故。交易系统在高并发的时候偶发超时，运维翻日志找原因，结果发现那个时间段的 ERROR 日志全是空的。排查了一圈才搞明白——Logback 设了 AsyncAppender，队列满了之后，新来的日志直接被丢弃了。问题日志没留下来，复盘都无从下手。 异步日志本来是提升性能的好东西，但如果没搞懂它"队列满了怎么办"，关键时刻它会把你最需要的那条日志扔掉。 今天聊聊怎么用好 Logback 的异步日志——既不让日志拖慢业务线程，也不让关键日志在队列溢出时被丢弃。 同步日志慢在哪 先说清楚为什么需要异步。一次常规的日志写入，背后是好几步操作： 业务线程调用 log.info() │ ├─ 格式化：把参数拼进日志模板 → "订单 12345 支付成功" ├─ 编码：转成字节数组（UTF-8） ├─ 写磁盘：fsync 刷到文件 └─ 返回，业务线程继续 其中"写磁盘"这一步最慢。固态硬盘一次随机写入大约 0.1ms，机械硬盘可能到几毫秒。如果业务代码里日志打得很密，每次 log.info() 业务线程都要等磁盘写完才能继续——高并发下这个等待会非常可观。 异步日志....

公司在做压测的时候发现一个奇怪的现象：QPS 跑到 8000 的时候，接口响应时间有个规律性的毛刺——每隔 15 秒，P99 延迟就会跳一下，从 50ms 飙到 200ms，持续一两秒又恢复正常。查了半天，根因是 Prometheus 来拉指标了。JVM 要遍历所有指标、序列化成文本、再通过网络发出去，这一整套操作每次都要几十毫秒。平时感觉不到，高并发下就成了定时炸弹。 Prometheus 好用，但它的 Pull 模式有个固有的问题：每次抓取，应用程序都要做一遍"遍历指标 → 格式化 → 输出"的全流程。 指标越多、频率越高，这个开销越不可忽略。 为什么 Pull 模式在高频采集下会出问题 Prometheus 默认每 15 秒拉一次指标。对于大多数服务来说，这个频率没啥问题——15 秒一次，每次几十毫秒，感知不到。 但如果你把采集频率调成了 5 秒、甚至 1 秒，或者你的应用里有大量自定义指标（几百个 Counter/Histogram），情况就不一样了。 每次采集，JVM 里发生的事情是： Prometheus 发 GET /metrics 请求 │ ├─ 遍历所有注册的指标（....

上个月产品经理跑过来说，用户反馈有些手机上商品图不显示，全是裂图。我第一反应是 CDN 挂了，查了一圈没问题。后来发现是运营上传了一批 WebP 格式的图片，而部分老款 Android 机和 iOS 14 以下的 Safari 根本不支持 WebP。图片存了，用户看不见，等于没存。 WebP 确实是好东西——同样画质下体积只有 JPEG 的 60% 左右，做图片多的业务能省下一大笔带宽。但兼容性这个坑，处理不好就是事故。 今天聊聊怎么既能吃到 WebP 的红利，又不让老用户看到一屏裂图。 WebP 为什么好，又为什么烦 先看一组实测数据。同一张 1920×1080 的照片： 原始 PNG： 2.1MB JPEG 85%： 420KB WebP 85%： 260KB ← 比 JPEG 小 38% AVIF 85%： 180KB ← 更小，但兼容性更差 同样的视觉效果，WebP 能省将近一半的带宽。如果你的业务每天有 100 万次图片请求，平均每张 300KB，换成 WebP 后每张 180KB，一天能省 120GB 的流量。 但问题在哪？Can I Use 上 WebP 的支持率大约....

去年一个做在线文档平台的哥们半夜被运维叫起来。服务器 CPU 打到 100%，磁盘疯狂读写，查了半天发现有人在后台跑挖矿脚本。溯源之后找到入口——一个用户上传的 .docm 文件，里面有段恶意 VBA 宏。系统调用 Office 转 PDF 的时候，宏被执行了，服务端直接中招。 这事儿比 SQL 注入还吓人。注入你得找到注入点，宏病毒你只要把文件上传上去，别人帮你打开，你就进去了。 文件预览几乎是所有企业应用的标配——合同管理要预览 PDF、OA 系统要预览 Word、网盘要预览 Excel。但很少有人意识到，每次把用户上传的 Office 文件扔进转换引擎，都等于在服务器上双击了一个陌生人发给你的附件。 今天聊聊怎么用进程隔离的思路，把这个风险降到最低。 宏病毒是怎么在服务端生效的 很多人觉得"我服务端又没有 Office 软件，哪里来的宏？" 但实际上，现在主流的文件预览方案底层都绕不开文档转换引擎。LibreOffice、OnlyOffice、Apache POI——它们做的事情就是把 docx / xlsx / pptx 转成 PDF 或者 HTML，然后前端渲染。而这些引....

公司做视频平台，用户上传一个 2GB 的素材文件，进度条跑到 95%，浏览器崩了。刷新页面重新上传，进度条又从 0% 开始。用户直接关了页面，再也没回来。 后来加了断点续传。用户重新打开页面，后端一问 Redis——"这个文件你上次传了 38 个分片，还差 2 个"，直接从第 39 片开始传。3 秒搞定，用户甚至没注意到断过。 大文件上传这种事，不怕慢，怕的是断了之后要从头再来。今天聊聊怎么用 Redis 记录分片上传状态，实现真正的秒级续传。 先说清楚：为什么大文件上传非得分片 一个 2GB 的文件你不可能一口气传上去。网络稍微波动一下，整个 HTTP 请求就废了，2GB 白传。 所以业内的标准做法是分片上传：客户端把文件切成小块（比如每片 5MB），一片一片发。服务端收齐所有分片后，按顺序合并成完整文件。 客户端： 文件 2GB → 切成 400 片，每片 5MB 上传过程： 上传第 1 片 ✓ 上传第 2 片 ✓ ... 上传第 399 片（网络断了！）✗ 上传第 400 片 ✗ 服务端： 收到 398 片 等待第 399、400 片（永远等不到） 分片之后，问题就变成了....

朋友前段时间接了个支付对接的项目，联调的时候一切正常，上线跑了两天也没事。直到有一天财务对账，发现有几笔订单被扣了两次款。排查了半天，日志里同一笔订单收到了两条完全一样的请求，时间间隔不到一秒。他当时就懵了 —— 代码里明明做了幂等，怎么还能重复扣款？ 这不是什么高深的 0day 漏洞，甚至连"攻击"都算不上。就是一个中间人把你发出去的请求原封不动复制了一份，重新扔给了服务器。但后果你能想象：重复扣款、重复下单、重复发券，随便哪个都能让业务方提着刀来找你。 这个问题学名叫重放攻击（Replay Attack），解决起来其实思路很清晰。今天就用大白话聊聊，怎么用三道防线把这种请求挡在外面。 先说说重放攻击到底是怎么回事 举个例子。你在 App 上下一笔订单，客户端会发一个 HTTP 请求到服务器： POST /api/order/create Body: {"productId": 123, "amount": 99.00, "userId": 456} 这个请求跑在 HTTPS 下面，内容是加密的，中间人看不到你买了啥。但他不需要看到内容 —— 他把整个加密的数据包原封不动抓下来....

前两天群里有人发了个截图，他们公司一个后台管理系统被人拖了库。查了半天，问题出在一段 MyBatis 的动态排序代码上。那哥们特别委屈："我没拼字符串啊，我用的是 MyBatis，框架不是自带防注入吗？" 我一看代码，${orderBy} 赫然在目。他以为 MyBatis 是银弹，实际上 $ 和 # 差了一个安全分水岭。 今天聊的这个话题，但凡写过 Java Web 项目的人都会遇到。但很多人对 SQL 注入的认知停留在"用了 MyBatis 就安全了"，这个想法比注入本身还危险。 一句话搞懂：# 和 $ 到底差在哪 先别急着看方案，把这个最基础的概念弄明白。 MyBatis 里写 SQL，有两种方式塞参数： -- 方式一：#{} SELECT * FROM user WHERE name = #{name} -- 方式二：${} SELECT * FROM user WHERE name = '${name}' 区别在哪？#{} 走预编译，${} 是字符串拼接。 用 #{} 的时候，MyBatis 会把 SQL 发给数据库之前，先把参数位置用 ? 占位，参数值单独传给数据库。数....

做过全链路追踪的同学肯定都遇到过这个问题：主线程设置了 TraceID，异步任务或线程池中新线程里却拿不到这个值，导致日志里 TraceID 断掉了，排查问题时要在一堆没有上下文关联的日志里大海捞针。 我之前就遇到过这样一个案例：一个接口处理耗时 5 秒，排查后发现代码里用了 @Async 注解异步执行数据库操作，但子线程的日志里 TraceID 是空的，问了半天才发现是线程池上下文丢失的问题。 今天我们就来聊聊为什么异步场景下上下文会丢失，以及如何用 InheritableThreadLocal 或 TransmittableThreadLocal 来完美解决这个问题。 线程上下文丢失的真相 1. 为什么异步会丢上下文 问题场景： 主线程： ┌─────────────────────────────────────────────┐ │ Thread-1 │ │ TraceID: abc123 │ │ UserID: 100 │ │ RequestID: req-001 │ └─────────────────────────────────────────────┘ │ │ 提交....

凌晨 2 点，运维群炸了：结算任务超时，数据库连接池打满，CPU 飙到 95%。查了半天发现 —— 上一轮的账单还没算完，下一轮又启动了，数据重复处理、死锁、OOM，一波带走。 这不是段子。只要你的系统有定时任务，这个坑迟早会踩进去。 今天这篇文章，从根因到方案，从单机到分布式，把定时任务重叠执行这件事讲透。 一、问题到底出在哪？ 先看一个最简单的场景。 // 每 5 分钟执行一次数据同步 @Scheduled(cron = "0 */5 * * * ?") public void syncData() { // 从上游拉数据、清洗、入库 pullData(); // 耗时：不固定，2~8 分钟 cleanData(); saveToDB(); } 调度周期是 5 分钟，但 pullData() 本身就要 2~8 分钟。问题来了： 8:05 第一轮启动，预计 8:13 结束 8:10 第二轮启动，此时第一轮还没跑完 两轮并行执行，同时操作同一批数据 后果你懂的：数据重复、死锁、连接池耗尽、OOM，一条龙服务。 根因一句话：调度频率 > 任务执行耗时，且没有任何防护机制。 ....

做分页功能的同学肯定都遇到过这个问题：项目初期数据量小，分页查询秒级响应，产品经理说加上分页功能吧，很简单。结果上线后数据量上来，第 100 页就开始慢了，到第 10000 页直接超时。 我之前就遇到过这样一个案例：一个订单查询系统，用户反馈查第 1000 页以后的数据要 30 秒+，根本没法用。排查后发现，后端用的就是最常见的 LIMIT 10000, 20。 今天我们就来聊聊深分页的性能问题，以及如何用 Search After 和游标机制让第 100 万页也能毫秒响应。 深分页的性能问题根源 1. 传统分页的致命缺陷 很多开发者用的分页方式是这样的： -- MySQL SELECT * FROM orders ORDER BY create_time DESC LIMIT 10000, 20; -- Elasticsearch GET /orders/_search { "from": 10000, "size": 20, "sort": [{ "create_time": "desc" }] } 这种方式在小数据量时没问题，但数据量上来后就是灾难： 问题场景：1000万数据，....

做过分布式任务调度的同学肯定都遇到过这个问题：分片任务执行时，分片 0 先完成了，分片 1 还在跑，如果直接进入下一步可能会导致数据不完整。我之前就遇到过这样一个案例：一个数据汇总任务，分片 0 处理华东区数据，分片 1 处理华南区数据，分片 0 完成后就开始汇总，结果分片 1 还在处理，导致汇总数据只有华东区，漏掉了华南区。 今天我们就来聊聊 XXL-JOB 分片广播场景下的乱序处理问题，以及如何用全局屏障机制确保数据完整性。 分片广播的乱序问题 1. 什么是分片广播 XXL-JOB 分片广播原理： 执行器集群： ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 执行器 0 │ │ 执行器 1 │ │ 执行器 2 │ │ (分片0) │ │ (分片1) │ │ (分片2) │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ ▼ ▼ ▼ 处理数据A 处理数据B 处理数据C │ │ │ ▼ ▼ ▼ 完成 进行中 等待中 调度器一次广播，所有分片同时执行！ 2. 乱序问题的典型场....

做过数据库优化的同学肯定都遇到过这个问题：明明在字段上建了索引，查询却还是全表扫描。排查后发现，原来是 SQL 语句中用字符串类型去查询数字类型字段，触发了 MySQL 的隐式类型转换，导致索引失效。 我之前就遇到过这样一个案例：一个订单查询接口，明明 order_id 字段上建了索引，但查询时却用了 order_id = '12345' 这样的字符串条件。结果查询从毫秒级变成了秒级，线上出现大量超时。 今天我们就来聊聊 MySQL 隐式类型转换的陷阱，以及如何用 MyBatis 类型处理器来强制校正。 隐式类型转换的本质 1. 什么是隐式类型转换 隐式类型转换场景： 表结构： CREATE TABLE orders ( id INT PRIMARY KEY, order_id BIGINT INDEX, -- 数字类型，有索引 user_id INT ); 查询语句： -- 字符串查询数字字段 SELECT * FROM orders WHERE order_id = '12345'; -- 数字查询字符串字段 SELECT * FROM orders WHERE user_name....

做过 Redis 开发的同学肯定都遇到过 BigKey 问题：某个 Key 的 Value 太大，导致读取时阻塞主线程，整个 Redis 服务响应变慢甚至超时。我之前就遇到过这样一个案例：一个用户的购物车数据用单个 Hash 存储，随着时间推移数据越来越多，最终这个 Key 的 Value 达到了 15MB，每次读取都会导致 Redis 阻塞 500ms+，严重影响了系统性能。 今天我们就来聊聊 Redis BigKey 的危害，以及如何用 Hash 槽化迁移的方式实现零停机拆分。 BigKey 的危害 1. 什么是 BigKey BigKey 定义： - String 类型：Value 大小超过 1MB - Hash/List/Set/ZSet：元素数量超过 1000 个 常见场景： - 用户购物车：一个 Hash 存储所有商品 - 排行榜：一个 ZSet 存储所有用户分数 - 消息队列：一个 List 存储大量消息 - 配置中心：一个 String 存储超大配置 2. BigKey 的性能问题 性能影响分析： 1. 读取阻塞 - GET bigkey → 一次性读取 10MB+ ....