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

公司用阿里云 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....

朋友公司大促期间，数据库连接池突然打满。所有需要数据库的请求都排队等连接，connection-timeout 设了 30 秒——等了 30 秒拿到连接的人还得用，30 秒拿不到的人直接报错。问题是那些等了 28 秒终于拿到连接的人，数据库早已经被前面的人压垮了，拿到连接也没用。400 个请求同时排队，300 个超时报错，100 个拿到连接但数据库响应时间从 5ms 飚到 500ms。 这不是数据库的问题，是连接池在突发流量面前没有自保能力。今天聊聊怎么用动态扩容和排队熔断，让连接池在洪峰到来时不崩溃。 问题：连接池是漏斗，不是水坝 连接池的设计初衷是"复用连接，避免频繁建连"。但它有一个致命假设：总有空闲连接可用。 突发流量一来，连接瞬间打满，后续请求只能排队。排队的请求占着 Tomcat 线程，Tomcat 线程也满了——连锁反应。 请求 → 连接池 → 没空连接 → 排队等 ↓ 排队占着 Tomcat 线程 ↓ Tomcat 线程池也满了 ↓ 新请求直接被拒 ↓ 整个服务不可用 连接池从"漏斗"变成了"堵点"。 方案一：动态扩容，峰值时多借几个连接 HikariCP 的 ....

公司的支付系统出了个大事故。一笔订单因为网络抖动，支付回调超时了，系统重试了扣款。结果扣了两笔——用户投诉，财务对账发现了差异，运营逐笔人工退款。查日志发现，不是网络不通，是"半通"——第一次扣款请求发出去了，银联处理成功了，但响应在回来的路上丢了。系统认为扣款失败，又发了一次。 这种"网络半通"是分布式系统里最危险的情况——操作已经执行了，但调用方不知道。不加重试怕丢，加多了怕重。今天聊聊怎么用业务流水号加状态机，让重试在"安全"的边界内进行。 问题的本质：操作不是天然幂等的 HTTP 的 POST 不是幂等的，数据库的 INSERT 不是幂等的，银行的扣款接口更不是幂等的。如果不做任何处理，同一个扣款请求发两次，钱就会扣两笔。 分布式系统里有太多场景需要重试——网络抖动、超时、服务暂时不可用。重试本身是合理的，问题在于你拿什么来判断"这次重试的请求，上一次有没有已经成功过了"。 答案就是业务流水号。不是数据库自增 ID，不是 UUID，而是一个由业务方生成、全链路唯一、可用来判断"这条请求我见没见过"的标识。 业务流水号：请求的唯一身份证 业务流水号的核心原则：由发起方生成，....

朋友公司的订单系统连了两个库——订单库和库存库。一笔订单创建需要在订单库 INSERT、在库存库 UPDATE，同一个事务里跨两库操作。高峰期出现了死锁：事务 A 锁了订单表的行等库存表的锁，事务 B 锁了库存表的行等订单表的锁。两个事务互相等待，40 秒后被 MySQL 的 innodb_lock_wait_timeout 强杀。问题是强杀后抛出的异常只说了"锁等待超时"，没说是谁锁了谁——运维排查不到哪个事务导致了死锁。 单库死锁 MySQL 自己能检测和回滚，跨库死锁 MySQL 管不了——因为在它看来就是两个独立的事务各等各的。今天聊聊怎么在应用层做跨库死锁检测，并配合智能重试自动恢复。 跨库死锁是怎么发生的 单库死锁 MySQL 的 InnoDB 引擎自己就能处理：检测到环 → 选一个代价最小的回滚。但跨两个库的时候，场景是这样的： 事务 A: 事务 B: BEGIN BEGIN UPDATE orders SET ... UPDATE inventory SET ... WHERE id=1001 WHERE sku='XYZ' （锁住订单库的行） （锁住库存库的行） ....

公司用 Nacos 做配置中心，Gateway 路由也放 Nacos 里动态刷新。运维改了一条路由规则，配置一刷新，Gateway 就开始间歇性 502——大概持续了 2 到 3 秒。排查发现是路由表在热更新的时候，旧的被清空了、新的还没加载完，中间有一个空窗期。请求进来找不到路由，全部 502。 热更新本来是为了不重启，结果还是搞出了服务中断。问题不在热更新本身，而在更新的姿势不对——路由表是"先清空再加载"而不是"先准备好再切换"。今天聊聊怎么用双缓冲让路由切换做到真正的零宕机。 问题出在哪里：单路由表的空窗期 Spring Cloud Gateway 的 RouteDefinitionRouteLocator 在接收到 Nacos 配置变更时，默认行为是： 收到新配置 │ ├─ 清空旧路由表 ├─ 逐条解析新路由 ├─ 校验路由合法性 └─ 加载完成 从"清空"到"加载完成"之间，路由表是空的。这段时间进来的请求，全部 502。加载几十条路由可能只要 100ms，但如果路由规则复杂、或者有外部依赖校验，这个窗口可能拉到秒级。 双缓冲：新路由加载完再切过去 双缓冲的思路很朴素....