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

去年我们团队跑了差不多半年微服务，拆分得挺爽——订单、支付、库存、物流、用户中心，每个服务独立开发独立部署。架构图上画得漂漂亮亮。 直到有一次线上故障，把我整破防了。 一个下单请求超时，从网关一路追下去：Gateway → 订单服务 → 库存服务 → 支付服务 → 回调通知。五个服务，五个开发者写的日志，五种不同的格式。 订单服务的日志长这样： 2026-06-15 14:23:11.456 [http-nio-8080-exec-3] INFO c.o.s.OrderService - 订单创建成功，订单号: ORD20260615001 库存服务的日志长这样： [INFO] 2026/06/15 14:23:12.789 - StockServiceImpl: 扣减库存成功 [skuId=SKU8823, qty=1] 支付服务的日志干脆连时间戳格式都不一样： {"level":"info","msg":"支付回调处理完成","tradeNo":"TRD20260615001","time":"2026-06-15T14:23:13.456+08:00"} 我在 Kibana....

去年我们搞了一次周年庆秒杀。活动页面提前一周预热，到点那一刻，后台监控直接变成一片红。 不是 QPS 被打爆——网关和应用层都扛住了。是数据库连接池，三秒之内从 0 飙到 200（最大连接数），然后所有请求开始报 Cannot get JDBC Connection。 最离谱的是，库存表一行没动。 因为所有请求刚到数据库门口，就被连接池耗尽的异常挡回去了。秒杀还没开始，数据库先倒下了。 一、连接池为什么瞬间被榨干 常规架构下，每次请求处理到数据库这一步才会获取连接。秒杀场景的流量是瞬时脉冲——0 秒之前无人问津，0 秒之后几十万并发同时冲到数据库门口。 连接池有个坑：它不会拒绝你，它只会让你排队等。 HikariCP 默认最大连接数 10（或者你手动设的 200），当并发的数据库请求数超过这个值时，获取连接的线程进入等待队列。每个请求最多等 connectionTimeout（默认 30 秒）。秒杀场景下 30 秒太长了—— 所有线程都在等连接 连接被前面进来的请求占用着（那些请求可能正在执行慢查询） 后面的请求继续涌进来抢连接 线程池里的线程全卡在获取连接上，CPU 空转 tom....

凌晨两点，报警群里炸了。 "订单服务三台机器磁盘使用率全部超过 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....

去年双十一前一天，凌晨3点，被叫起来复盘一次诡异的事故。 事故的表现很魔幻：K8s 集群里所有 Pod 状态都是 Running，健康检查全部通过，Grafana 大盘一片绿。但用户反馈说下单按钮点不动，支付页面转圈圈，客诉量每分钟十几条。 运维同学第一个反应是"网络问题"。查了半小时，网络一切正常。第二个反应是"数据库挂了"，DBA 看了一眼连接池——没问题。 最后顺着日志一层层摸，发现 Redis Cluster 里有一个分片的 Master 选举失败，变成了只读模式。订单服务在查 Redis 缓存的时候拿不到写入权限，但它的 /health 接口还在正常返回 200。 因为健康检查只做了 ping——一个什么都没验证的空壳。 一、返回 200 不等于活着 大多数 Spring Boot 项目配健康检查都是这样： GET /actuator/health → {"status":"UP"} 加个 Spring Security 的登录校验就算完事了。看起来挺稳的，直到某天业务挂了，你才发现这玩意儿根本没用。 为什么？因为 Spring Boot Actuator 默认的健康检查....

公司用阿里云 OSS 存用户上传的文件，标准存储每月 0.12 元/GB。半年后发现月账单从几百涨到了两万——文件总量从 1TB 涨到了 20TB，其中 80% 是三个月前上传的、再也没人访问过的文件和日志备份。这些文件一直按标准存储计费，实际上低频存储的价格只要标准存储的三分之一。 云存储的价格差异很大——标准存储最贵，低频存储便宜一半，归档存储几乎不要钱（但取回要等几小时）。问题是很多公司的文件从上传第一天就放在标准存储里，从来没动过，也从来没降级。 今天聊聊怎么用生命周期策略，让不同类型的文件自动流转到合适的存储层级，存储账单直接砍半。 云存储的三种温度 各大云厂商的存储分层都差不多，本质上是"访问频率越高价格越贵、访问频率越低价格越便宜但取回有代价"的 trade-off： 存储类型单价（约）数据取回最短存储适合场景 标准存储0.12 元/GB/月免费无限制频繁访问的热数据 低频存储0.08 元/GB/月按量付费30 天一个月访问几次的温数据 归档存储0.03 元/GB/月解冻 1~5 分钟60 天几乎不访问的冷数据 深度归档0.015 元/GB/月解冻 12 小时....

公司有一次线上故障——某个下游服务挂了，调用方在 catch 块里打了 log.error("调用失败", e)。这行代码每分钟被执行了 5 万次，5 万条堆栈日志，每条 3KB，一分钟就写了 150MB 的日志文件。运维发现的时候磁盘已经满了，其他服务也跟着挂。灾难的起点不是下游挂了，而是日志把磁盘写爆了。 这种日志爆炸场景的典型特征是突发性——平时打日志没问题，一旦某个循环里遇到了异常，日志量瞬间暴涨。今天聊聊怎么给日志加上限频和异步落盘，让它在异常场景下也不会失控。 问题出在哪：日志写入是同步阻塞的 Logback 默认的 FileAppender 是同步写盘的。log.error() 调用时，线程会等日志写完了才继续执行。平时没感觉，但一旦日志量暴增，磁盘 IO 就成了瓶颈——所有打日志的线程都堵在等磁盘写入。 而且同步模式下，每行日志都是一次 write() 系统调用。一分钟 5 万条就是 5 万次系统调用，再加上堆栈的格式化，CPU 也被打满。 方案一：异步落盘，业务线程不等 IO Logback 的 AsyncAppender 就是干这个的： <appende....

公司的网盘系统出了个诡异的 bug。用户 A 上传了一个 500MB 的视频文件，分成了 100 个分片。上传到第 80 片的时候，用户 B 也上传了一个同名的视频文件——可能是一个修订版。两个上传请求同时往同一个文件名下写分片，最后合并出来的文件里混了一半 A 的内容和一半 B 的内容。文件打不开，用户投诉。 分片上传的并发冲突比单文件上传难处理得多。单文件上传一次 HTTP 请求就完成了，有冲突也容易看出来。分片上传是几十上百个 HTTP 请求，冲突可能发生在任何时候——第一个分片被 B 覆盖，最后一个分片还是 A 的。结果就是一个"拼接怪物"。 今天聊聊怎么用分布式锁把分片上传的整个过程保护起来，确保同一时间只有一个上传任务在操作同一个文件。 冲突是怎么发生的 分片上传的流程通常是这样： 1. 前端发起分片上传 → 后端返回 uploadId 2. 前端逐个上传分片 → 每片带 uploadId + 分片号 3. 全部分片上传完 → 发起合并请求 两个人的冲突： 时间线： 用户 A 用户 B T1 创建 uploadId=A1 T2 上传分片 0~50 T3 创建 uploa....

朋友公司的文件服务，一到月底报表下载高峰期就崩。运维排查发现每次下载一个 200MB 的 Excel，后端代码里居然是 byte[] data = file.readAllBytes()——把整个文件加载到堆内存里再往外写。10 个人同时下载，就是 10 个 200MB 的数组在堆里，JVM 直接 OOM。重启后又崩，加内存也撑不住——因为下载峰值不是你能通过加内存解决的线性问题。 大文件下载的 OOM 问题本质就一句话：你把整个文件搬进了 JVM 堆里，但 JVM 堆不是为文件 IO 设计的。 文件应该从磁盘流到网卡，中间经过你的应用，但不要在你的堆里停留。 今天聊聊怎么用流式传输和零拷贝，让 X GB 的文件下载跟 X KB 的一样轻松。 错误姿势：全量加载 最常见的错误写法： @GetMapping("/download") public ResponseEntity<byte[]> download(String filePath) { byte[] data = Files.readAllBytes(Path.of(filePath)); // ❌ 全量加载到....

一、问题背景：JWT 的 CSRF 隐患 你是否认为使用 JWT 就天然安全？实际上，JWT 在某些场景下依然存在 CSRF 风险！ 当 JWT 存储在 Cookie 中（尤其是 HttpOnly=false 的情况），攻击者可以通过以下方式发起 CSRF 攻击： 用户登录你的网站，服务器返回 JWT 并存放在 Cookie 中 攻击者诱导用户访问恶意网站 恶意网站发起对目标网站的请求（如转账、修改密码） 浏览器自动携带 Cookie 中的 JWT，请求成功执行 真实案例：某电商平台的支付接口使用 JWT 认证，但未做 CSRF 防护。攻击者通过构造恶意页面，诱导用户点击后成功发起支付请求，造成用户资金损失。 二、核心概念：CSRF 与 JWT 的博弈 2.1 CSRF 攻击原理 ┌──────────────────────────────────────────────────────────────────┐ │ CSRF 攻击流程 │ ├──────────────────────────────────────────────────────────────────┤ ....

一、问题背景：权限缓存的"脏数据"困境 你是否遇到过这样的场景： 管理员在后台修改了某个用户的角色权限 用户重新登录后发现权限没有变化 只有重启服务或等待缓存过期，权限才会生效 这就是典型的权限缓存一致性问题。为了提高系统性能，我们通常会将用户权限信息缓存到本地，但当管理员修改权限后，其他节点的缓存并不会自动更新，导致用户获取到过期的权限数据。 真实案例：某电商平台在大促期间，管理员紧急调整了部分运营人员的权限，但由于缓存未及时刷新，导致权限变更延迟生效，影响了订单处理效率。 二、核心概念：缓存一致性模型 2.1 缓存更新策略对比 策略描述优点缺点适用场景 Cache-Aside先更新数据库，再删除缓存简单存在竞态条件读多写少 Write-Through同时更新缓存和数据库一致性好写入性能低一致性要求高 Write-Behind先写缓存，异步写数据库写入性能高数据可能丢失允许最终一致性 Event-Based事件驱动更新缓存解耦性好实现复杂分布式系统 2.2 事件总线架构 ┌───────────────────────────────────────────────....

一、问题背景：线程池耗尽的"死亡螺旋" 你是否遇到过这样的场景：系统使用 @Async 异步执行任务，在流量高峰期突然出现大量请求超时，最终导致整个服务不可用？ 这很可能是 Future.get() 阻塞导致的线程池雪崩。当异步任务的处理速度跟不上请求速度时，任务会在队列中堆积，而调用线程在 Future.get() 处阻塞等待，最终导致调用线程也被耗尽。 // 危险的异步调用方式 @Async public CompletableFuture<String> doAsyncTask() { // 执行耗时操作... } // 调用方 public void process() { CompletableFuture<String> future = asyncService.doAsyncTask(); String result = future.get(); // 阻塞等待，可能导致线程耗尽 } 真实案例：某支付系统在双十一期间，异步对账任务因数据库慢查询导致处理延迟，调用线程在 Future.get() 处阻塞，最终导致 Tomcat 线程池被占满，新....

一、问题背景：日志数据的"熵增困境" 你是否遇到过这样的场景：系统运行一段时间后，任务执行日志表的数据量达到数十亿条，导致： 查询变慢：简单的日志查询需要数秒甚至数分钟 存储成本飙升：SSD 存储费用持续增长 备份困难：全量备份耗时过长 DDL 操作阻塞：添加索引或修改表结构需要长时间锁表 这就是典型的历史数据膨胀问题。任务执行日志通常具有"写多读少"的特点，超过90%的日志数据写入后很少被访问，但却占用着宝贵的存储资源和查询性能。 二、核心概念：冷热数据分离原理 2.1 数据生命周期模型 ┌──────────────────────────────────────────────────────────────────┐ │ 数据生命周期 │ ├──────────────────────────────────────────────────────────────────┤ │ │ │ 热数据 ──► 温数据 ──► 冷数据 ──► 归档数据 ──► 删除 │ │ (7天) (30天) (90天) (365天) │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ │ ....

公司的后台管理有一个搜索功能，搜订单备注里的关键词。刚开始数据量小，MySQL 的 LIKE '%keyword%' 还能跑。后来订单涨到几百万条，一个模糊搜索要跑 8 秒。更倒霉的是，这个搜索请求直接打在主库上——索引走不了，全表扫描，CPU 飙到 90%，其他正常业务也跟着慢。 LIKE '%xxx%' 是数据库的噩梦。前导通配符导致索引完全失效，只能全表扫描。MySQL 虽然也有 FULLTEXT 索引，但中文分词烂、不支持复杂排序、而且仍然在主库上消耗资源。 今天聊聊怎么用 Canal 把 MySQL 的数据实时同步到 Elasticsearch，把搜索的活从主库彻底拆出来。 架构：主库只管写，搜索交给 ES MySQL（主库） Elasticsearch │ │ │ INSERT/UPDATE/DELETE │ ├──── Canal 监听 binlog ──────────→├─ 增量同步 │ │ │ 业务读写 │ 全文搜索 │ （走主库） │ （走 ES） Canal 伪装成 MySQL 的 Slave，订阅 binlog 的变更事件。任何 INSERT、UPDAT....

一、问题背景：定时任务的"多米诺骨牌效应" 你是否遇到过这样的场景：线上运行着多个定时任务，其中一个任务因为外部服务超时、数据库慢查询或死循环而卡住，导致整个调度器线程池被占满，其他所有定时任务都无法按时执行？ 这就是典型的线程池饥饿问题。Spring 的 @Scheduled 默认使用单线程调度器，所有任务共用一个线程。一旦某个任务阻塞，后续任务都会排队等待，形成"多米诺骨牌效应"。 // 默认的单线程调度器 - 危险！ @Configuration @EnableScheduling public class SchedulerConfig { // 所有 @Scheduled 任务共用这个单线程 } 真实案例：某电商平台在大促期间，库存同步任务因数据库慢查询卡住，导致订单统计、报表生成等关键任务全部延迟，最终影响了实时数据展示。 二、核心概念：线程池隔离原理 线程池隔离的核心思想是：将不同类型、不同重要程度的定时任务分配到独立的线程池中执行，避免相互影响。 隔离策略对比 策略描述适用场景 按业务类型隔离不同业务域使用独立线程池订单、库存、用户等不同业务模块 按重要性隔....

朋友公司的 Redis 集群监控上 used_memory 才 4GB，但 used_memory_rss 已经到了 8GB——是 used 的两倍。运维加了内存，过两个月又一样。最离谱的是有一次 used_memory 只有 2GB，Redis 却报了 OOM。排查发现内存碎片率 3.5，8GB 的物理内存被碎片占了一半多。 这就是 Redis 的内存碎片问题。used_memory 是你存进去的有用数据，used_memory_rss 是 Redis 实际向操作系统申请的内存。两者之间的差，就是碎片。 今天聊聊怎么用 Redis 自带的内存碎片整理和对象复用，把碎片率降到 1.1 以下。 碎片怎么来的 Redis 的内存分配是 jemalloc 管理的。当你反复写入和删除不同大小的 Key，就会出现这样的场景： 内存布局（简化）： |AAAA| 空闲 |BB| 空闲 |CCCC| 空闲 |DD| 空闲 |... 删掉的 Key 留下的空隙不够大，放不下新的 Key。新 Key 只能往后申请新内存。结果就是 used 没涨多少，rss 一直涨。 碎片率计算公式： mem_fra....