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

引言 去年大促当晚 21:47，客诉群炸了： "我明明付了钱，订单还是显示待支付！" 更离谱的是有用户截图：已经发货的订单，状态被改回了"待支付"。 排查 40 分钟后真相大白：订单状态流转靠 Kafka 消息驱动，order.created、order.paid、order.shipped 三个事件发到一个 32 分区的 Topic 上——发消息时压根没传 key。Kafka 默认分区策略把同一个订单的三个事件轮询（3.3+ 是粘性策略）散到了不同分区，各分区消费进度不一，paid 比 created 早了 400ms 被消费。消费端逻辑是"收到什么事件就改成什么状态"，于是刚付完款，一条迟到的 created 把状态从"已支付"打回了"待支付"。 当晚 6700 笔订单触发"状态回退"告警，客诉 300+。修完这个事故，团队对 Kafka 顺序的理解被彻底刷新： 以为"Kafka 天然有序"——错，Kafka 只保证单分区内有序，分区之间谁先谁后它管不着 以为"加了分区就更快"——对，但分区越多，没做分区键设计的消息散得越开，乱序概率越高 以为"消息按序到了就稳了"——错，消....

引言 面试场景还原： 面试官："Kafka 为什么比 RocketMQ 快？" 候选人："因为 Kafka 有零拷贝、顺序写、批量发送。" 面试官微微一笑："那 RocketMQ 团队为什么不把这些抄过去？是技术不行吗？" 候选人：？ 这一问就露馅了。因为题目的前提就是错的——Kafka 不是"更快的 MQ"，RocketMQ 也不是"慢一点的 MQ"。它们是两个物种： Kafka 从 LinkedIn 的日志管道演化而来，本质是分布式日志系统，为海量数据的高吞吐流转而生 RocketMQ 从阿里双 11 交易链路演化而来，本质是业务消息中间件，为交易场景的功能完备性而生 先亮核心结论：高吞吐的数据链路选 Kafka，业务交易链路选 RocketMQ。我们公司生产上两者并存——埋点日志、CDC、Flink 流处理走 Kafka（日处理 40 亿条）；订单、支付、库存等业务消息走 RocketMQ，各干各的，谁也没想替代谁。 这篇文章按《本地缓存三巨头》的套路，从 5 个维度拆解两者差异：简介 → 架构对比 → 吞吐实测 → 功能完备性 → 延迟与消费体验，最后给出"谁也替代不了....

引言 一个安静得可怕的对账日： 风控月度对账发现：37 笔已支付成功的订单，下游库存服务完全没有收到"支付成功"消息。Kafka 集群日志没有任何 ERROR，Producer 端没有回调异常，Consumer 端没有报错——消息就是凭空消失了。 复盘结论更扎心：这不是一次故障，是三个"配置漏洞"的接力——生产者 acks=1 时恰好赶上分区 Leader 切换、Broker 没设 min.insync.replicas（ISR 缩到 1 也照收不误）、消费者开了自动提交（先提交 offset 后处理，业务处理失败消息就"确认掉了"）。三层各漏一个，消息就没了。Kafka 从不承诺"你配错了我也不丢"，它只承诺"你配对了我不丢"。 这篇文章按消息的生命周期拆三层保障：生产者端（acks + retries + 幂等）→ Broker 端（副本 + ISR + Unclean 选举）→ 消费者端（手动提交）。每一层讲三件事：消息怎么丢的、每条配置的语义是什么、为什么必须这么设。先放结论总表（完整可抄清单在第七章）： 层配置设定值防住什么代价 生产者acksallLeader ....

引言 先看一次真实压测的内存报告： 网关服务切到虚拟线程（JDK 21 + spring.threads.virtual.enabled=true）后吞吐立涨 40%，团队很满意——直到压测 10 万并发时 Old 区从 800MB 涨到 2.3GB， young GC 每 10 分钟 41 次。MAT 打开 heap dump（方法见《堆外内存排查》），榜首触目惊心： Class Name | Instances | Retained java.lang.ThreadLocal$ThreadLocalMap | 992,317 | 1.5 GB java.lang.ThreadLocal$ThreadLocalMap$Entry| 2,976,951 |（每个 map 里 3 个 Entry） ↳ TraceIdContext.TRACE_ID | ↳ UserContext.USER | ↳ TenantContext.TENANT | 三个 ThreadLocal，10 万并发请求线程，每人一份 ThreadLocalMap 副本——平台线程时代"几百个池化线程共享几十个 Th....

引言 一个看似无关痛痒的数字，正在悄悄吃掉你们的效率： 我们的订单服务，单实例启动 8.2 秒。听起来还行？算笔账就知道了： 滚动发布：80 个实例，K8s 滚动窗口 25%，一次发布光等启动就要 8 分钟 弹性扩容：大促前扩 40 个实例，业务方在群里催了 5 分钟，实例还在 Starting K8s 健康检查：liveness 探针 6 秒超时，实例启动慢的节点被反复杀掉重建，发布雪崩 本地开发：改一行代码重启 8 秒，一天重启 50 次，一个多小时没了 启动时间不是"体验问题"，是资源、发布效率和稳定性三重账单。 这篇文章把订单服务从 8.2 秒压到 2 秒出头的全过程拆成 5 个优化点：关闭多余自动配置 → 懒加载 → 缩小类扫描 → AOT 编译 → Undertow，每一步都给出实测的前后耗时对比和"什么场景该开什么"的判断。先放总成绩单（基线：Spring Boot 3.2、JDK 21、4C8G 容器、含 MyBatis/Redis/Kafka/RabbitMQ 全家桶）： 优化点配置耗时变化适用场景 ① 关闭多余自动配置spring.autoconfigu....

引言 两个投诉，隔着不到十分钟打进来，把一个普通的周四下午变成了事故复盘会： 14:40，用户 A："我刚下的订单，列表里怎么找不到？刷新也没用。" 14:48，用户 B（内测商家）："你们后台给我的报表是三个月前的吧？我上周的销量呢？" 排查结果比投诉更扎心：订单从库延迟 3 小时 12 分钟（用户 A 的问题），而排查时顺手做的全量巡检还揪出一个更吓人的——报表归档从库的复制位点停在三个月前（用户 B 的问题），期间没有任何告警，因为监控清单里压根没有这台"冷从库"。 根因不在什么高深的东西：14:02 一个定时任务发了单个 50 万行的大事务 UPDATE，主库 6 分钟执行完，从库却要整事务串行回放 42 分钟——在这 42 分钟里，这个事务之后的所有 binlog 都只能排队，单线程回放的从库被彻底堵死。更早的 1 个半小时积压叠上去，就是 3 小时 12 分钟的账。 这篇文章按真实排查顺序展开：事故还原 → 复制原理补课（延迟是架构属性不是故障）→ Seconds_Behind_Master 的读法与三个坑 → 定位大事务 → 三重修复（大事务拆小 + 并行复制 + 关....

引言 先还原一个真实的排障现场： 业务方反馈"消费有延迟"，你登录服务器： 先看 Broker 日志？几千行，没有明显报错 再看监控大盘？只有集群级指标，看不出哪个组慢了 想查 Lag，敲 kafka-consumer-groups.sh --describe？几十个消费组、几百个分区刷屏，肉眼比对到眼花 最后定位到根因只花 20 分钟，但**"找到该看什么"花了 2 小时**。 Kafka 排障的痛点从来不是"看不到问题"，而是没有趁手的工具把问题呈现出来。这篇文章把我运维 Kafka 集群（3 副本、50+ Topic、日均 2 亿消息）沉淀下来的 5 个工具一次性讲清： Kafka UI——开源 Web 管理界面，Topic/消费组/Lag 一目了然，日常排障主力 kafka-topics.sh——命令行建/删/改 Topic，一切自动化操作的基础 Kafka Manager——Yahoo 出品，集群级监控的鼻祖 CMAK——Kafka Manager 的社区延续版，现状与选型必知 Burrow——LinkedIn 出品，消费 Lag 的智能告警（不靠拍脑袋定阈值） 每个....

引言 面试高频题，也是最难答好的一题： "Kafka 的消息都持久化到磁盘了，为什么还能单机扛百万级消息？Redis 数据放内存不是更快吗？" 大多数人的回答是背一句"Kafka 顺序写 + 零拷贝"，再往下追问就露馅了： 为什么顺序写就快？内存 25GB/s，磁盘顺序写才 200MB/s，差 100 倍呢 PageCache 是什么？Kafka 为什么自己不搞个缓存？ 零拷贝到底省了几次拷贝？省的是谁的钱？ 批量和压缩跟"快"有什么关系？ 先给一组我们生产环境的真实数据（3 副本、NVMe 盘、2KB 消息、acks=all）：单 Broker 稳定跑 80 万 msg/s，CPU 使用率不到 40%，磁盘 util 长期低于 30%。既没吃满 CPU，也没吃满磁盘——因为它在四个环节上同时"不浪费"。 这篇文章按一条消息的生命周期拆四板斧：顺序写（消除磁盘随机 IO）→ PageCache（读写走内存）→ 零拷贝 sendfile（消除无谓的数据拷贝）→ 批量+压缩（消除网络往返）。每板斧都给原理图 + 性能数据对比 + 关键参数。先放结论总表，后文逐个展开： 环节普通....

引言 "上周三晚上，支付服务突然不响应，登录到机器上 screen 早已刷不动。值班同学的第一反应是重启——被拦下来了。30 分钟后我们还原出了完整的事故链条：top -H 看到一个线程 CPU 100%（不是进程，是 GC 线程），jstack 确认是 Young GC 风暴，ss -s 发现 ESTAB 连接只有 47 条但 SYN-RECV 堆了 4000+，lsof 揪出一个 Tomcat 容器拿着已被删除的 42GB 日志文件不放手——磁盘早满了，GC 日志都写不出来，一连串症状相互掩盖。如果按'感觉像什么就查什么'的乱枪打法，这 30 分钟可能变成 3 小时。" 排障和破案一样：新手靠猜，高手靠证据链。而证据链的生产工具，就是那几个看起来平平无奇的 Linux 命令。这篇文章按"从系统到进程、从现象到根因"的排查路径，精选 5 个我日常使用频率最高、也最容易拉开效率差距的命令：ss（网络连接）、lsof（谁占着端口/文件）、strace（进程卡在哪次系统调用）、top -H（哪个线程在烧 CPU）、jstack（Java 线程在等什么）。每个命令只讲三件事：实战场景（什么症....

引言 新同事入职第一天写了个调用：定义一个接口 @FeignClient(name = "user-service")，方法上标个 @GetMapping，然后 @Autowired 注入就发 HTTP 请求了。他盯着代码看了十分钟，跑来问我："这个接口没有任何实现类，Spring 是怎么把它实例化出来的？userMapper.query() 这种调用，方法体里明明什么都没有，参数怎么就变成 JSON、URL 怎么就拼出来了？" 这确实是 Spring Cloud 里体验最"魔法"的一块。更有意思的是上个月刚排的一个线上问题：我们调用户服务的 GET /user/query 查询接口，前端传参是 UserQuery 对象，Feign 一发出去，对端直接回了 405 Method Not Allowed——查了半天发现请求方法变成了 POST，body 里躺着那个 Query 对象。为什么会变？答案就藏在"Java 方法如何被翻译成 HTTP 报文"的翻译官——SpringMvcContract 的解析规则里。 这篇文章就沿着"魔法"的生成路径逐层拆开：@EnableFeignClien....

引言 "迁移演练一切正常，正式切流后第 3 天，客服接到用户投诉：同一笔订单在'我的订单'里能看到，点进详情页却是'订单不存在'。排查两小时，发现读流量已经 100% 切到 PG，但一条 9 个月前的历史订单在 MySQL 里有、PG 里没有——当初 pgloader 跑全量时，这张表刚好漏了两个分片，而我们的校验脚本只对了'当天数据'。" 这是 2024 年我们订单库迁移中最深刻的一次教训：迁移的成败不在"搬数据"本身，而在流程的严密性——全量、增量、校验、切流、回滚，任何一环的侥幸都会变成线上的故障。这次迁移的对象是 5000 万行订单库（20 张核心表 + 80 张次要表），从决定迁移到 MySQL 归档下线共 6 周，全程零停机、零数据丢失，期间还真实触发了一次回滚演练。 系列前三篇解决了"为什么迁"（《为什么从 MySQL 迁移到 PostgreSQL》）、"语法差在哪"（《MySQL→PostgreSQL 语法迁移对照》）、"迁了值不值"（《MySQL vs PG 性能横评》），这篇补上最后一环——怎么迁。完整流程六步：pgloader 全量迁移 → 应用层 SQL 改造 ....

引言 "周三晚上 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 原生分片时....