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

引言 "周三晚上 20:00 大促前的最后一次发布，测试全绿，发布完成后 22:30 用户量一上来，接口全部超时。排查发现是一个新的营销接口调下游风控服务没设超时——风控库抖了一下，接口线程全部挂在那里，Tomcat 200 个线程 10 分钟内耗尽，拖垮了整个应用。更讽刺的是，这个问题在测试环境根本暴露不出来，因为测试环境的下游永远秒回。" 复盘时我们把历次线上事故拉了个清单，发现一个扎心的规律：90% 的上线后事故，根源都不是"不会写"，而是"忘了查"——超时没设、日志级别没改、缓存没过期、幂等没做。这些知识团队里人人都懂，但上线前的匆忙时刻，没人按住每一行代码问一遍。 所以这份清单的定位不是教程，是检查表（Checklist）：每个点只回答三件事——查什么（检查标准）、怎么查（工具/命令）、中招长什么样（事故症状）。发布评审时照着走一遍，10 分钟能拦住绝大多数"低级但致命"的问题。这份清单也是对本系列前面事故复盘文章的收口：幂等对应《消息重复消费排查》《接口幂等 4 种方案》，SQL 对应《PG 性能调优实战》，缓存对应《Redis 大 Key 阻塞》，内存对应《堆外内存暴增排....

引言 "周四凌晨 2:17，主库服务器主板故障宕机，告警准时响了。值班同学打开手机看到'PG 主库不可达'，翻运维手册、找从库、改应用配置、重启连接池——业务恢复时是 3:04，整整 47 分钟。好在是凌晨，只积压了十几分钟的订单，如果是大促高峰，这个数字会是几十万笔。" 复盘会上两个结论：手动切换不可接受，必须让"检测故障 → 选举新主 → 提升从库 → 流量切过去"全程自动化，把 47 分钟压到 30 秒以内；同时排查中发现主库 8000 多个连接、40GB 内存被几百个空闲会话白白吃掉——MySQL 一个连接一条线程尚可硬扛，PG 是一个连接 fork 一个进程，连接数根本开不起太高，必须上连接池。 最终落地的就是生产圈公认的"高可用三件套"：流复制负责把 WAL 日志实时搬到从库，保证主库挂了有库可切；Patroni 负责故障检测、选主和 VIP 漂移，把切换 RTO 从 47 分钟压到 28 秒；pgBouncer 负责把应用的几千个连接收敛成后端几十个真正的 PG 进程，内存从 40GB 降到 6GB。这篇文章按部署一个新集群的真实顺序展开：先把流复制跑通，再权衡同步/异步....

引言 "凌晨 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....

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

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

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

引言 "凌晨 2 点网关告警内存 85%，3 点 92%，4 点容器被 OOMKilled，重启后一切正常，然后 6 小时后再来一遍。" 值班的同事第一反应是堆内存泄漏，jmap、jstat、堆 dump 全做了，发现 Xmx 2G 的堆只用了 800M，Young GC 规律、Old 区平稳，MAT 里 Dominator Tree 翻了三遍没有任何大对象——但容器 RSS 实实在在涨到了 3.7G（limit 4G）。 堆没涨，进程内存涨了——这就是堆外内存泄漏的典型特征。 它比堆内泄漏阴险得多：jmap 看不见、堆 dump 里找不到、OOM 时连 hprof 都不会生成（因为是内核 OOM Killer 直接杀的进程），监控图上只有一条让你绝望的平滑上涨曲线。 这篇文章按那次事故的真实排查路径，走完六个台阶：jmap 看堆 → RSS 对不上账 → NMT 给本地内存分类 → MAT 从 DirectByteBuffer 小对象顺藤摸瓜 → Netty LEAK 检测打出 Created at 堆栈 → jemalloc 做最终归因。元凶是一个 WebSocket 推送 Han....

引言 "渗透测试报告出来了，同一个后台系统三个高危：订单列表的排序参数能拖出整库用户表、订单备注里写一段 <script> 后台运营一查看就中招、攻击者还能借运营的登录态静默发起转账审核。" 三个漏洞的入口各不相同，但修复加起来没超过 200 行代码——因为它们正好对应 Web 安全里最经典的三道防线：SQL 注入、XSS、CSRF。 这三个词几乎每个 Java 开发者都听过，线上的真实情况却是：知道用 #{} 但 order by 场景图省事写成 ${}；XSS 只在前端做了转义，接口用 curl 直接打就穿；CSRF 则更隐蔽——"我们是前后端分离 + JWT，应该不用防吧？" 这句话在不少团队里流传，但只要你的 token 放在 Cookie 里自动携带，CSRF 的门就一直敞着。 这篇文章按"攻击原理 → 漏洞代码 → 正确配置/代码 → 绕过手法"的结构，把三道防线一次讲透：SQL 注入靠 MyBatis 预编译 + 参数白名单（防御位置在数据访问层）；XSS 靠输入校验 + 输出按上下文编码（防御位置在输出渲染层，输入过滤只是兜底）；CSRF 靠 Spring ....

引言 "PG 有条 SQL 特别慢，但我说不清慢在哪。"这个求助背后通常藏着三个没做对的事：不知道哪条 SQL 最该被优化（凭感觉抓一条，可能优化完也省不出 1% 的负载）、不知道它为什么慢（猜是缺索引，加完索引发现没走）、不知道优化后有没有变好（没有前后数据，全靠"感觉快了"）。MySQL 时代大家习惯了 slow log + EXPLAIN 那套流程，但 PG 的参数名、日志格式、EXPLAIN 输出都长着另一副面孔，照搬经验会处处碰壁。 PG 的慢查询定位有一套清晰的漏斗：慢查询日志圈定"慢"的事实 → pg_stat_statements 排序找出"最值得治"的 SQL → EXPLAIN ANALYZE 拆开看它到底慢在哪一步。这三步各解决一个层次的问题，跳过任何一步都容易变成"在错误的 SQL 上使劲"。这篇文章按漏斗顺序走完整个流程，并把重心放在第三步——读懂 PG 的 EXPLAIN 输出：Seq Scan / Index Scan / Bitmap Scan 三种扫描节点的区别与选择逻辑、cost 的真实含义（它不是时间）、以及 rows 估算与实际行数偏差为什么是"....

引言 "一个实例已经下线 20 秒了，消费者还在往它上面发请求，每隔一段时间报一批 connect timeout。" 排查时发现 Nacos 控制台里这个实例先变红（不健康）、过一会儿才彻底消失，而消费端的地址列表更新又比控制台晚了好几秒——三层时间差叠在一起，就是那批超时的全部来源。 要算清这笔时间账，光靠"知道 Nacos 有心跳、有推送"是不够的，必须回答四个源码级问题：服务实例是什么时候、被谁注册上去的？心跳 5 秒一次是谁在发，服务端凭什么 15 秒判不健康、30 秒才摘除？消费者本地的地址列表多久更新一次，UDP 推送和定时拉取到底谁兜底？ 这篇文章以 spring-cloud-alibaba 2.2.x + nacos-client 1.4.x + nacos-naming 1.4.x（HTTP 心跳模式）为准，按一条实例从启动到被发现的真实路径，把 NacosServiceRegistry、NamingProxy、ServiceManager、BeatReactor、HostReactor、PushReceiver 六个核心类串起来。代码均有删减只保留主干，文末会单独....

引言 客服机器人上线一周，用户的吐槽集中在一句话上："它是不是失忆了？" 用户：我上周买的那双跑鞋想换货，订单尾号 8821 Agent：好的，请提供订单号和商品名称。 用户：我刚说了啊，跑鞋，8821！ Agent：好的，请提供订单号和商品名称。 每轮对话都是一次独立的 HTTP 请求，模型本身是无状态的——你以为它"记得"上一轮，其实是你的应用每次都得把历史重新喂给它。大多数人实现的第一步也确实是"把对话存数据库"，但存了照样失忆：数据库里有历史 ≠ 模型看到了历史。这中间缺的是"记忆注入层"——每次生成前，把该让模型看到的历史和事实，以它能直接利用的格式放进请求。 这篇文章按工程落地的顺序讲清三种记忆：短期记忆（滑动窗口 + Token 裁剪）、长期记忆（偏好向量化 + 检索注入）、会话隔离（userId/sessionId 两级主键），最后用 LangChain4j 实现一个"记得你上次问了什么"的电商客服 Agent。 一、先澄清：模型没有记忆，记忆是你的应用伪造的 1.1 一次请求的真相 // 模型 API 是完全无状态的：每轮对话都要把完整上下文带上 chatMode....

引言 "MySQL 和 PostgreSQL 到底谁快？"这个问题几乎每个月都会在不同群里引发一轮争吵。吵架的根源是双方都在拿"我上次那个查询快多了"之类的孤例互相说服，而没有限定场景——OLTP 点查 MySQL 有传统优势，JSON 检索 PG 甩开几倍，谁的孤例都能成立，但谁也说服不了谁。性能对比没有全局答案，只有场景答案。 这篇文章用统一环境（同一台服务器、相同数据量、相同压测工具、各库都给合理配置而非默认摆烂配置）跑完 10 个高频场景，把"谁在什么条件下快、快多少、为什么"一次说清。数据来自我们的真实测试环境，绝对数值会随硬件和版本波动，但相对结论（谁领先、差距量级、原因）在不同机器上是稳定的。测试脚本在文末完整给出，欢迎在你自己的环境里复现打脸。 前置说明：测试基于 MySQL 8.0.36（InnoDB）与 PostgreSQL 16.3，双方都经过基础调优（buffer pool / shared_buffers 各按内存 50~60% 配置，关闭自动提交干扰，数据全部预热后测量）。所有场景均跑 5 轮取中位数。 一、测试环境与方法论：先立规矩，再谈数据 1.1....

引言 一张订单表 5000 万行，两年前建表时没人想过它会这么大：管理后台查一个用户近三个月的订单，索引还健在时 80ms，如今同样的查询变成 1.2 秒；DBA 想给 created_at 建个新索引，CREATE INDEX CONCURRENTLY 跑了三个小时还没完，期间磁盘 IO 打满影响线上；想删掉两年的历史数据，DELETE 跑了一夜没删完，还把表搞出了 40% 的膨胀。单表大了以后，慢的从来不只是查询——索引维护、数据清理、备份恢复、vacuum，每一件事都在恶化。 这些问题的共同解法是分区表：把一张逻辑大表按规则切成多个物理小段，查询只碰需要的段（分区裁剪），删除整段数据变成秒级的 DETACH/DROP，索引和 vacuum 都只发生在小分区上。PostgreSQL 10+ 的声明式分区让这件事的门槛降到了几条 DDL。这篇文章按"选分区类型 → 建按月 RANGE 分区 → 本地索引设计 → 分区裁剪验证 → 自动化维护"的顺序，用完整的 SQL 和 EXPLAIN 前后对比，讲清千万级大表分区的正确姿势——以及哪些坑（跨分区查询反而更慢、主键必须带分区键、唯一索....

引言 三年前我们把一个 60 万行的单体拆成了 28 个微服务，庆功会上大家都觉得架构"现代化"了。半年后复盘，数据却很诚实：需求交付周期从平均 5 天变成了 12 天，线上 P1/P2 故障数量翻了一倍，排障平均耗时从 20 分钟变成了一个半小时，而支撑这一切的团队只有 12 个人。最讽刺的是，让我们最痛苦的不是技术难题，而是拆完之后才发现的那些"本来可以不发生"的问题。 微服务从来不是一个技术选型，它是一种用复杂度换灵活性的组织结构决策——Conway 定律早就说了，系统架构会长成团队沟通结构的样子。这篇文章把我们踩过的 10 个坑按"拆分→数据→治理→交付→组织"四个层次摊开，每个坑都给出当时的真实症状、付出的代价，以及事后回头看的正确做法。如果你正在考虑微服务化，或者已经在坑里，希望这十条能帮你少交一半学费。 一、拆分层：拆多细，决定后面所有坑的深度 坑 1：服务拆分过度——一次下单跨 8 个服务 症状：拆服务时按"名词"机械切分，user-service、account-service、address-service、coupon-service、inventory-ser....

引言 凌晨两点，告警短信把运维叫醒：order-service HikariPool-1 - Connection is not available, request timed out after 30000ms。登上服务器一看，20 个数据库连接全部 active，但数据库 processlist 里一半连接在 Sleep、没有任何 SQL 在执行——连接被借走了，却没有在跑查询，也没有归还。重启服务后一切恢复正常，但第二天同一时间，告警再次响起。 这是典型的连接泄漏（Connection Leak）：代码从池里借走连接后，因为异常分支、提前 return、手动取连接等原因没有 close，连接永远不会回到池中。它和"慢 SQL 占满连接池"症状相似但根因完全不同——慢 SQL 是连接在用但用得久（processlist 能看到正在执行的语句），泄漏是连接"人间蒸发"（processlist 显示 Sleep，池却显示 active）。更阴险的是它的累积特性：代码每天只泄漏两三个连接，但池总共只有 20 个，一周后池就被抽空，而且时间点毫无规律，重启只能续命。这篇文章完整复盘一次真....