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

引言 "产品经理上传一个 2GB 的安装包，进度条爬到 92% 时网络闪断，浏览器弹了个'上传失败'——一切从头再来。第三次传到 80% 时，Tomcat 那边先 OOM 了。" 这个事故里其实藏着三层问题：普通 multipart 上传把整个文件吃进服务器内存/临时目录，2GB 文件等于让每个请求都背着一颗内存炸弹；HTTP 是无状态的，传了 92% 断开，服务端对'已经收到多少'毫无记忆，重传只能从零开始；同一个安装包团队里十个人各传一遍，服务器接收了十遍完全相同的 2GB 字节。 对应的三个解法已经是行业标配：分片上传把大文件切成 5MB 小块逐个传，单次请求小、失败只需重传一块；断点续传用 Redis 记录已上传分片，重连后只传缺口；秒传在上传前先拿文件 MD5 问服务端"这个文件是不是已经有了"，有就直接返回成功，一个字节都不用传。这篇文章给出从前端 File.slice 到后端合并落盘的完整实现：前端 TS + Axios 并发池，后端 Spring Boot + Redis 分片状态 + FileChannel 零内存合并，文末再讲生产环境演进到 OSS/S3 原生分片时....

引言 "凌晨 Redis 主节点物理机故障，哨兵把流量切到了从节点，业务几分钟就恢复了——但早上对账发现，故障前 4 分钟内的 1200 笔已支付订单状态全部丢失。" 支付服务把订单状态临时存在 Redis 里做状态机流转，默认配置下只有 RDB、save 60 10000（60 秒内 1 万次写入才触发快照），深夜低峰期写入稀疏，最后一次成功快照停在故障前 4 分钟。更麻烦的是这些状态已经驱动了后续业务，丢了就补不回来。 另一个极端同样常见：有人被这次事故吓到，把所有实例都开成 appendfsync always，结果每条写命令都强制刷盘，单实例写入 QPS 从 5 万掉到 2000，应用线程大量阻塞在 write() 上——为了不丢 1 秒钟的数据，付出了 25 倍吞吐的代价，这显然也不是正确答案。 Redis 持久化的选型之所以争议不断，是因为它从来不是"RDB 还是 AOF"的二选一，而是一连串工程权衡：能接受丢多久的数据、文件多大、恢复多快、fork 子进程对大实例的卡顿有多大、重写期间的双写内存撑不撑得住。这篇文章从持久化的本质讲起，把 RDB 快照、AOF 追加日志、A....

引言 "商家后台的经营看板每天早上 9 点准时雪崩——门店店长们上班第一件事就是打开看板看昨天的销量，接口 P99 直接飙到 10 秒以上，连接池被打满，连带下单接口都跟着超时。" 慢的是一条看似平平无奇的聚合 SQL：5000 万行的订单表，按门店和日期统计商品销量 Top20。开发同事最初的反应是"加个索引吧"，加完从 10 秒变成 800ms，以为收工——结果一周后看板又慢了，而且 EXPLAIN 显示索引建了却没完全用上。后续又陆续做了查询改写、分区裁剪、物化视图预聚合四步，最终稳定在 45ms，前后 200 倍差距。 这个案例最有价值的地方不是某一条神奇 SQL，而是一条完整的优化阶梯：每一步解决一个不同层面的瓶颈，每一步都有 EXPLAIN ANALYZE 的前后对比作为证据，而且每一步都有明确的适用边界——索引解决"扫得太多"、改写解决"索引用不上"、分区解决"表太大"、物化视图解决"重复计算"。这篇文章就按这条阶梯逐级推进，SQL 基于 PostgreSQL 14，数据量 5000 万行真实量级。读完你会掌握一套可复用的优化方法论：先用 EXPLAIN ANALYZE ....

引言 "用户投诉一笔订单被扣了两次钱，流水截图发过来，两笔扣款间隔 17 秒，金额、商户号、支付单号完全一样。" 查到支付系统时，第一眼以为是第三方支付平台重复回调——对方日志里只回调了一次；再往下查 MQ 监控，发现同一条支付成功消息被投递了两遍，消费者也老老实实执行了两遍扣款，账户服务没有任何去重逻辑。 更讽刺的是，重投递的触发点不是故障，而是消费者处理完业务后没有 ACK：RabbitMQ 等不到确认，30 秒后认为消费者"没处理成功"，把消息重新入队又推了一次。第一次扣款其实已经成功，第二次又成功——幂等性缺失让"至少一次投递"（at-least-once）直接变成了"至少扣一次款"。 这篇文章按事故的真实时间线复盘：消息为什么一定会重复（MQ 的投递语义）→ 重复扣款的代码根因 → 三重保障修复（消费端幂等 + 手动 ACK + 死信队列兜底）→ 唯一索引/Redis SETNX/状态机三种幂等方案的对比选型。代码基于 Spring Boot + Spring AMQP（RabbitMQ），关键语义会对照 RocketMQ 和 Kafka。先给结论：在 MQ 的世界里，"消息....