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

引言 3 月压测第二天，下单成功率从 99.2% 掉到 87.3%，一天 2,136 单创建失败。 报错不是"库存不足"，也不是"锁超时"，而是一个很多人第一次见的异常： org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only （Spring 6.x 的提示语；5.x 是 Transaction rolled back because it has been marked as rollback-only，意思一样。） 更让人看不懂的是代码：发积分那段明明包在 try-catch 里，异常被吞了，主流程还打了一行 log.warn("add points failed, continue")。日志确实打出来了，说明 catch 生效；但事务最后还是回滚了，订单没建成。 先给结论：catch 能拦住异常往外抛，拦不住内层事务已经把你标记成 rollback-only。 ....

引言 618 开场 3 分钟，客服群先是安静，然后炸了：大量用户反馈"点进去就是系统繁忙"，但后台监控显示后端 QPS 只有预期的四分之一，服务器闲得发慌。 翻网关日志，429 占比 87%。也就是说，我们自己的限流把 87% 的真实用户拒了，同时那批刷子请求畅通无阻。 配置是四个 Nginx 实例，每个上面一行 limit_req_zone $binary_remote_addr zone=perip:10m rate=5000r/s;。 我当时的理解是"每个用户每秒 5000 次"，显然过于宽松，肯定是刷子打太多了。第一反应是把 rate 调到 50000，多放点人进来。 调完 5 分钟，后端 QPS 从 2 万冲到 19 万，数据库连接池瞬间打满，订单服务开始超时，事故从"网关误杀"升级成"后端雪崩"。 先给结论：限流限的是"谁"，不是"多少"。 你把 key 选错，rate 配得再准也是在限一个不存在的人；你把单机限流当全局限流，四个实例就是四份配额，总量永远是配置值的 N 倍。这篇按事故顺序讲完三层限流的完整配置：CDN 边缘 → Nginx 原生 + Lua 分布式 → 应....

引言 去年大促，1,000 件商品的秒杀刚开抢，监控上三条曲线同时变形： 入口 QPS 冲到 12 万 库存服务的扣减请求 3 万 QPS MySQL 连接池 100%，等待队列堆到 2,000+ 结果库存被扣成 -37，超卖 37 单；数据库 CPU 打满，连商品详情查询都开始超时；Redis 上那个 stock:1001 的单分片 CPU 100%——3 万个扣减请求全砸在同一个 key 上。 当时的代码用的是最直觉的写法：UPDATE stock SET count = count - 1 WHERE sku_id = ? AND count > 0。这条 SQL 看着无懈可击，它的真实含义却是 3 万个请求在数据库行锁上排队。单行更新的上限就在那，连接池先满，超时、重试、更多请求涌进来，雪崩不到 10 秒。 这篇文章不讨论"库存怎么扣得快"，只回答三个问题：10 万 QPS 该被拆成哪几条流量、每一层要多少机器、架构为什么长成这个形状。 读完你能带走一套可复用的容量推导方法，以及一张能直接照着画的架构图。 一、需求拆解：先问清"10 万 QPS 是谁的 10 万" "....

引言 09:02，告警群里跳出一条：jvm_gc_pause_seconds P99 = 2.8 秒。 09:12，我先拍脑袋扩了两台实例——没用，CPU 只有 20%，瓶颈不在算力。 09:20，jstat 显示老年代从 45% 涨到 99%，Full GC 每两分钟一次，每次 STW 2.5 秒。接口 P99 从 60ms 变成 3.1s，网关 5xx 占到 12%。 09:40，我摘掉一台机器做堆分析，才发现占着 2.1GB 老年代的既不是缓存，也不是连接池，是日志——一个报表接口把 35MB 的 JSON 塞进了 log.info，而异步日志的队列把它钉在了老年代里。 这篇复盘讲清一条链：一行看起来人畜无害的日志，怎么在 40 分钟里喂满 8G 堆，把 GC 变成"空转"；以及用三条命令，怎么在 10 分钟内从"怀疑内存泄漏"走到那行代码。 如果你手上也有一个"GC 很忙但回收不掉"的服务，这套排查顺序能直接复用。 先给结论：Full GC 频繁有两种，一种是垃圾太多，一种是活对象太多。前者加内存加机器能缓解，后者只能靠改代码。判据只有一个——Full GC 之后老年代有没有明....

引言 去年双十一前扩容，我们从 3 台 Broker 扩到 6 台。 机器加完，监控上看新 Broker：CPU 2%，磁盘 IO 为零，网络流量只有心跳。3 小时后有人问了一句："新机器是不是没加入集群？" 查了一圈，集群成员确实是 6 台，但 kafka-topics.sh --describe 里所有分区的 Replicas 还是老三台的 ID： Topic: order-events Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3 Topic: order-events Partition: 1 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1 ...所有分区，一个新 Broker 都没有 Kafka 不会自动把分区搬到新 Broker。 加机器只是让集群多了一个可用节点，要把负载真正分过去，必须做分区重分配——这一步没人做，新机器就是白买的。 同一次扩容还差点出第二个事故：重分配方案生成后直接 --execute，没加 --throttle。跨机房带宽瞬间打满，在线消费的 P99 从 15ms 飙到....

引言 面试官问："分库分表之后，跨库分页和聚合查询怎么做？" 我答："每个库查出来，在内存里合并排序，再取对应的页。" 面试官追问："16 个库，每库 100 万订单，要查第 100 页，你这套要查多少行？" 我算了一下： 每页 10 条，第 100 页 → offset = 990 每个库要查 990 + 10 = 1000 条 16 个库 → 16,000 条 应用层再对这 16,000 条排序，取第 991–1000 条 "16,000 条不算多吧？"我还嘴硬。 "那第 10,000 页呢？" offset = 99,990 每个库查 100,000 条 16 个库 → 1,600,000 条 会议室安静了。 这不是段子。我们线上真踩过：运营后台的订单列表支持跳页，某次查到第 50 页，接口 30 秒超时，16 个库的 CPU 同时飙到 90%。DBA 拿着慢查询日志找过来，每条都是 LIMIT 5000, 10——单看一条不慢，16 条并发的 LIMIT 5000,10，加上应用层归并，直接把连接池打满。 那次之后我把跨库查询拆成两张账单： 分页的账单：分片数 × (of....

引言 凌晨 02:17，告警群连续炸了三条： [P0] consumer-group order-settle Lag 突破 200 万，持续增长中 [P0] 对账任务延迟超过 30 分钟阈值 [P1] 下游结算服务 QPS 跌至 0 值班同事打开 Grafana 一看，曲线是这样的： Lag 200万 ┤ ╱ 150万 ┤ ╱ 100万 ┤ ╱ 50万 ┤ ╱ 0 ┼━━━━━━━━━━━━━━━━━╯━━━━━━━━━━━━━━▶ 时间 23:00 01:30(上游补数据) 02:17(告警) 根因很快定位：上游订单服务 01:30 做了一次历史数据补发，把积压的 180 万条订单事件一口气灌进了 Kafka。而消费组 order-settle 的处理能力是 800 条/秒——进来的速度是处理速度的 4 倍，Lag 只涨不跌。 更要命的是，消费逻辑里每条消息都要同步调用一次下游结算接口（平均 40ms），还套着"拉取一条、处理一条、提交一条"的朴素写法。消费端不是被消息打垮的，是被自己的串行处理拖垮的。 那一晚我们用四步把 Lag 从 200 万清到 0，耗时 47 分钟： ....

引言 周五晚上 21:30，客服群里涌入一批截图： "我明明把收货地址改了，下单页面还是旧地址！" "商品价格后台已经调成 79 了，用户下单还是按 99 扣的款！" 排查了两个多小时，DB 里的数据是对的，Redis 里的数据是对的，接口日志也没报错——但部分用户看到的就是旧数据。最后定位到的"凶手"让所有人沉默：订单服务的 OrderMapper.xml 里，三年前有人加了一行 <cache/>，二级缓存一直开着。 事故链条清晰得可笑： 订单查询 SQL 关联了 user_address 和 product 两张表，结果缓存在 OrderMapper 的命名空间下； 地址服务、商品服务各自更新自己的表，走的是 AddressMapper、ProductMapper——它们的更新只清自己命名空间的缓存，根本不知道 OrderMapper 里还躺着关联查询的旧结果； 用户改完地址，订单页查到的还是缓存里的旧快照，直到缓存过期（默认永不过期）或订单表自己有更新才"自愈"。 更扎心的是复盘时发现：这个缓存的命中率只有 11%，却制造了一起脏读事故。 性能收益约等于零，正....

引言 今年 3 月的一个凌晨，Kafka 集群做 3.8 → 3.9 的滚动升级，库存服务照常处理订单。 库存扣减的代码长这样： @Transactional // 数据库事务 public void deduct(String orderId, String skuId, int quantity) { stockMapper.deduct(skuId, quantity); // ① DB 扣减并提交 stockLogMapper.insert(orderId, skuId, quantity); kafkaTemplate.send("stock-deducted", orderId, event) // ② 再发消息 .whenComplete((result, ex) -> { if (ex != null) { log.error("send failed, orderId={}", orderId, ex); } }); } 平时这套代码跑了两年，没出过事。但那天凌晨，Broker 滚动重启期间分区 Leader 切换，ISR 一度缩到 1。Broker 端配了 ....

引言 去年大促前，我们给订单服务做了一轮压测。报告很漂亮： 8,000 QPS，平均响应时间 38ms，错误率 0%。 老板批了扩容预算，团队安心等大促。结果开场第 7 分钟，订单服务在 1,200 QPS 就开始超时，网关 504 一片。 复盘会上有人问了一句："那 8,000 QPS，到底是订单服务扛住的，还是压测机扛住的？" 会议室安静了。 把脚本和监控翻出来，四个问题摆上桌： 压测是同事在 JMeter GUI 里点的，本机 16 核开了 2,000 个线程，压测机 CPU 先到 100%，GUI 还在实时刷新结果树； 2,000 线程从第一秒压到最后一秒，没有阶梯、没有预热，JIT 和连接池冷启动阶段的数据被平均值抹平了； 只看平均响应时间 38ms，没人提 P99——事后翻原始数据，当时 P99 已经 2.3 秒； 所有请求都用同一个商品 ID，缓存命中率接近 100%，测出来的是"缓存有多快"，不是"系统能扛多少"。 那次之后我才真正理解：压测工具决定你能不能看清瓶颈，压测方法决定你看到的是不是真相。 这篇文章把四款主流工具放在同一张桌子上：JMeter、wrk、....

引言 三个月前，我们做了一次选型评审。会议室白板上写着三个候选：Kafka、RocketMQ、Pulsar。两小时讨论，最后停在同一个问题上： "你们说的'快'，是看了谁的博客？" 提案 A 说 Kafka 单机百万；提案 B 说 Pulsar 存算分离、弹性最好；提案 C 说 RocketMQ 双 11 扛过万亿级。三个人引用的都是厂商宣传页和几年前的 PPT，环境不同、消息大小不同、持久化语义不同——没有一个数字能横向比较。 于是我们自己搭了一套环境，把三套集群都按同样的机器规格、同样的消息、同样的可靠性语义压了一遍。3 台 8 核 16G 的机器，各 1000 万条 1KB 消息，每轮跑三遍取中位数。 先给结论（细节和原始数据在后文）： 维度第一名第二名第三名一句话 生产吞吐Kafka 26.8 万/s（262 MB/s）Pulsar 14.2 万/sRocketMQ 9.6 万/sKafka 领先 2.8 倍 端到端 P99（稳态）RocketMQ 9msKafka 18msPulsar 42mspush 长轮询占优 积压 1000 万条的消化速度Kafka 55 ....

引言 线上商品详情页有个接口，P99 稳定在 60ms，CPU 5%，GC 正常，数据库慢查询为零。压测报告看了三天没找到瓶颈，最后抓了一次链路： 商品详情页（一个请求要展示 100 个 SKU 的实时价格和库存） for (String skuId : skuIds) { // 100 次循环 String price = redis.get("sku:price:" + skuId); String stock = redis.get("sku:stock:" + skuId); } // 200 次 Redis 调用，耗时 98ms，占接口总耗时 80% 单次 get 0.5ms，看着不多；乘 200 次就是 100ms。而 Redis 服务端真正处理这 200 条命令花的时间，加起来不到 1ms——99% 的时间都花在"客户端发出去、服务端处理完、再传回来"的往返路上。 这不是 Redis 慢，是调用方式错了。消除往返有三把工具，能力边界完全不同： 手段核心作用原子性适用 原生命令（MGET/HMGET/MSET）一条命令拿多个 key单命令原子简单批量读写，最优先 ....

引言 去年大促当晚 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 ....