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

引言 看一眼我们线上早期接口的报错，很容易理解为什么前端同学会崩溃： {"timestamp": "2025-08-22T10:23:01.882", "status": 500, "error": "Internal Server Error", "path": "/order/create"} {"timestamp": "2025-08-22T10:23:03.114", "status": 500, "error": "Internal Server Error", "message": "订单服务异常: java.lang.NullPointerException", "path": "/order/create"} {"code": "A0001", "msg": "系统繁忙"} {"code": "500", "message": "下单失败：库存不足！"} {"errCode": 10010, "errMsg": "param error"} 同一个团队，五种返回结构、三套错误码风格、有的暴露堆栈有的吞掉。前端只能靠 if (res.code === 'A0001' ....

引言 大促彩排当晚，秒杀压测到 3000 并发时，下单接口开始批量报错，日志里刷屏的是同一句话： Deadlock found when trying to get lock; try restarting transaction DBA 的第一反应是“死锁了，MySQL 会自动回滚一个，重启事务就行”——问题是这个死锁每秒都在发生：被回滚的那一半请求里，一部分重试成功，一部分又撞进下一轮死锁，订单创建成功率从 100% 跌到 62%，压测被迫中断。 更蹊跷的是业务视角的死锁描述：两个事务根本“没有”操作同一行——事务 A 更新的是 SKU 1001 的库存，事务 B 更新的是 SKU 2002 的库存，它们凭什么互相等待？带着这个“不相干的行为什么会死锁”的疑问，我们拉开了一次教科书级的 InnoDB 锁排查：SHOW ENGINE INNODB STATUS 的死锁日志 → lock_mode X locks gap 字样 → 真相是间隙锁。这篇文章完整还原排查过程，并附上死锁日志的逐行解读技巧。 一、30 秒补课：InnoDB 的锁到底有几种 看懂死锁日志的前提是分清锁类型。....

引言 上个月运营做了一场大促预售，活动开始 10 分钟后客服反馈开始堆积：同一个用户下了两单。查日志发现不是并发 bug，也不是库存逻辑问题——用户在网络卡顿时连点了两次提交按钮，第一次请求 300ms 才返回，第二次请求几乎是同时到达的。前端虽然有按钮置灰，但置灰逻辑在“请求发出后”才生效，两道请求都穿了过去。 这类问题防得住吗？防得住，而且手段成熟——接口幂等。但幂等实现恰恰是“看起来简单、做对很难”的典型：网上随手搜到的 Redis SETNX 三行代码，放进真实系统里至少有四个坑等着你（并发窗口、异常回滚、过期时间、重复提交的用户体验）。 这篇文章用那次事故开题，把四种幂等方案一次讲透：唯一索引、Redis SETNX、Token 机制、乐观锁。每种给完整可跑的 Spring Boot 3.x 代码、适用场景、防坑要点——最后给一张选型决策表，照着抄就行。 一、为什么需要幂等：不只是双击 1.1 重复请求的四个来源 双击只是冰山一角。生产系统里重复请求的来源比想象中多： 来源场景特点 用户行为双击提交、刷新重发、返回键重放单用户、低频、难彻底在前端防住 网络重试HTT....

引言 公司电商单体三年长到了 80 万行：一个 war 包里装着用户、订单、库存、支付、营销五个业务域，开发者 40 多人往同一个仓库里提交代码。CTO 终于拍板拆微服务，第一个专题会的议题却是让所有人都沉默的一问——"那我们怎么切？ 研发 Leader 的直觉方案是按现有包结构切：com.shop.user 拆成用户服务、com.shop.order 拆成订单服务。看起来天经地义，但第一个反对声音来自订单组的资深开发："订单里查用户收货地址是直接 join 用户表的，拆了服务这个 join 怎么办？"第二个反对来自库存组："订单创建要锁库存、扣库存、释放库存，这是三个服务还是放订单里？" 这两个问题都不是代码问题，是边界问题。 单体时代用"共享数据库"偷偷掩盖了所有边界争议——join 一下就完事了，谁也不用想"收货地址到底属于用户域还是订单域"。拆分的第一课就是把这笔账算清楚：边界不清，拆出去的服务只是"分布式的单体"，接口间的 join 变成 RPC 调用，性能更差、复杂度更高。 这篇文章用这个真实电商单体做案例，把"拆边界"的全过程走一遍：用 DDD 限界上下文识别业务边界 →....

引言 公司知识库接了 RAG 之后，业务方提了第二个需求："能不能让它答得再准点？"——这个"再准点"背后是实打实的吐槽：问"年假可以攒到明年吗"，它从员工手册里捞出一段"考勤打卡规则"；问"服务器扩容审批流程"，它把无关的"机房巡检 SOP"排在最前面。答案的来源没问题（文档库里确实有），但检索根本没把对的段落捞出来——生成模型再强，也架不住喂进去的是错料。 我们拉了 100 条真实业务问题的评测集，跑了一版基线：Top5 召回率只有 60%——40% 的问题，正确答案所在的段落根本不在喂给大模型的上下文里。大模型面对缺失的料，只能一本正经地编。 最终的优化路径非常经典，就三步：按段落语义切分 → BM25+向量混合检索 → Rerank 重排序，召回率从 60% 提到 95%。这篇文章把这 60% → 95% 的全过程完整还原：每一步的坏代码长什么样、为什么坏、怎么改、改完涨了几个点——这是一份可以照着抄的调优清单。 一、先搞清"召回率"：RAG 排障的第一性指标 1.1 三个指标别混着说 RAG 的效果问题要先拆开看，不同层的问题药方完全不同： 指标定义反映哪层的问题 ....

引言 选 JSON 库这件事，团队里的争论从来没停过：新同事看博客说“Fastjson 快”，架构组说“Fastjson 有漏洞史别碰”，做 Android 的同学说“Gson 就够了”，玩 Kotlin 的说“Moshi 才是正解”。各说各的理，谁也说服不了谁——因为大多数对比文章只跑了“快慢”一个维度，而真实选型要考虑六件事。 这次我们认真做了一轮横评：四个框架（Jackson 2.17 / Gson 2.11 / Fastjson2 2.0.53 / Moshi 1.15）在同一个 Spring Boot 项目里，同一台机器、同一批数据、同一套 JMH 口径，跑序列化吞吐、反序列化速度、内存占用、特性支持、安全性、社区活跃度六个维度。先给结论——和许多人拍脑袋的印象一致又略有出入： Jackson 是全能王：性能第一梯队、生态无可替代、Spring 默认集成；Fastjson2 性能确实最强，但安全包袱要用工程手段兜住；Gson 胜在轻量和零学习成本，简单场景够用；Moshi 是 Kotlin 世界的答案。 下面逐维度展开数据和依据。 一、评测设计：先立规矩，再谈数据 1.....

引言 周五下午六点，一次再平常不过的发版。服务在测试环境跑得好好的，上线五分钟后开始疯狂报错： java.lang.NoSuchMethodError: com.google.common.collect.ImmutableList.toImmutableList()... 测试全绿、代码没动过这块逻辑、报错的方法在 IDE 里点进去明明存在——这种"物理上不可能的报错"几乎只有一个解释：运行时加载的 jar 版本和编译时看到的不一样。用 mvn dependency:tree | grep guava 一查，真相大白：新引入的一个报表 SDK 传递依赖了 guava 18.0，而我们代码编译时用的是 25.1——toImmutableList() 是 21.0 才加的方法，运行时类路径上排在前面的 18.0 里根本没有它。 依赖冲突是 Java 项目生命周期里最"常见而不常见"的问题：日常感觉不到它，一旦出现就是 NoSuchMethodError、ClassNotFoundException、AbstractMethodError 这类"玄学报错"，而且本地能跑线上炸（依赖树对 ....

引言 上个月市场部搞大促推广，十万条营销短信里带着原始链接——一条带渠道参数的 URL 足足 137 个字符，短信按 70 字拆条计费，一条短信被拆成三条，推广成本直接翻了三倍。更别提线下物料上印 137 个字符的 URL，二维码扫码后密密麻麻一屏。 短链接系统就是解决这个问题的：https://shop.example.com/product/detail?id=8847362&channel=sm&activity=d11&utm_source=xxx → https://s.example.cn/aB3xK9。看起来只是"把长的变短"，但把它当生产系统做，会撞上三个经典工程问题： 短码怎么生成——哈希会冲突，冲突了怎么办？ 跳转怎么扛住高并发——跳转是整个系统里 QPS 最高的接口，读多写少到什么程度？缓存怎么设计？ 访问统计怎么不拖垮跳转——每次跳转都记一笔，跳转链路被统计拖慢就本末倒置了。 这篇文章从 0 到 1 完整实现：MurmurHash + Base62 生成短码 → Bloom Filter 检测冲突 → DB 存储 → Redis 缓存....

引言 带新同事做订单去重的需求，他写出了这样一段代码：List 里 10 万条订单 ID，要移除一批黑名单 ID，他选择了 list.removeAll(blackList)——然后在压测时发现这个接口要跑 40 多秒。他一脸困惑："ArrayList 的 remove 不就是删个元素吗？" 这是 Java 集合最典型的认知偏差：API 写起来一行代码，底层复杂度却是天壤之别。集合框架的 API 设计得太"平"了——list.remove(i)、list.get(i)、map.put(k,v) 全都长一个样，编译器不会提醒你"这个操作是 O(n)"，JVM 也不会报错，只有当数据量上来后，CPU 和监控才会替它呐喊。 这篇文章梳理 5 个最常见、最容易在生产代码里扎根的集合性能陷阱。每个陷阱给三样东西：触发代码、底层源码原理、修复方案 + 实测量级对比。 #陷阱错误直觉正确复杂度频率 1ArrayList.remove(Object)"删除很快"O(n) 查找 + O(n) 搬移高 2LinkedList.get(index)"LinkedList 增删快"O(n) 逐节点走极....

引言 团队里新来的同学提了个问题："MyBatis 里面写的接口都没实现类，方法怎么就能执行 SQL 了？"我让他用 IDEA 在 sqlSession.selectOne() 打个断点，F5 步入跟一层——十分钟后他回来，表情像打开了新世界："原来插件能拦我 SQL、二级缓存影响我查询、还有一层参数和结果映射，全在这条调用链里。" 这个问题背后的能力，是面试和排障的分水岭： 面试问"MyBatis 插件原理"，答不上 Plugin.invoke 和责任链，说明只停留在 API 层； 线上查"为什么这条 SQL 打了 SQL 日志却没走缓存"、"为什么驼峰映射突然失效"，不懂 ResultSetHandler 和 TypeHandler 的分工就只能瞎猜； 写分页插件、慢 SQL 监控插件（比如 PageHelper），本质上都是在给这条调用链"加料"。 这篇文章以 sqlSession.selectOne("orderMapper.getOrder", 10086L) 为起点，沿着SqlSession → Executor（CachingExecutor 装饰）→ Stateme....

引言 上季度有个资金对账任务出了个诡异 bug：扣款和加款两条 SQL，一条提交了，另一条抛异常没执行——钱少扣了，账不平了。排查了半天，最后发现原因是同事为了"复用代码"，把事务方法从订单 Service 拆到了另一个类里，然后通过 this.xxx() 调用——事务悄悄失效了，代码没有任何报错，测试全绿。 @Transactional 的失效是最阴险的一类 bug：它不会报错、不会抛异常、甚至大部分场景连日志都没有，只是在你以为有事务的时候，实际上每条 SQL 都在自动提交。平时没事，等出问题就是数据不一致级别的故障。 这篇文章把 8 个失效场景一次讲全。每个场景给三样东西：能跑的失效代码、背后原理、最小修复方案。先给一张总览表，读者可以对照自查： #场景失效本质频率 1非 public 方法代理只增强 public 方法高 2同类内部调用 this.xxx()调用绕过了代理对象极高 3异常被 catch 吞掉代理看不到异常，无法触发回滚高 4rollbackFor 没配对默认只回滚 RuntimeException/Error高 5多线程事务绑定 ThreadLocal ....

引言 周三下午，订单系统突然全线报错。监控大屏上 RabbitMQ 集群三个节点的内存指示灯齐刷刷变红，业务侧表现却是"冰火两重天"： 上游：订单服务发消息全部卡住，接口超时——生产者被 MQ 拒绝接收； 下游：通知服务、积分服务的消费者日志一片寂静——消费者"拿不到"消息； 队列里：明明积压了几十万条消息，消费速率却是 0。 消息既进不去、也出不来，整个异步业务链路在十分钟内彻底断开。复盘后发现，触发点小到令人发指：两天前一次消费者重构，把 ACK 模式改成了手动确认，但代码里异常分支既不 ack 也不 nack——消息被消费者"领走"后永远没有"交差"，unacked 计数爬到上限后消费者不再被投递，队列只进不出，两天的积压最终撞穿内存水位线，触发了 RabbitMQ 最让人头疼的保护机制：Flow Control（流量控制）。 这篇文章把事故完整复盘：RabbitMQ 的内存水位与流控机制是怎么一环扣一环地锁死集群的、手动 ACK 为什么会变成"消息黑洞"、修复方案和监控体系怎么建——重点不是骂代码，而是讲清楚这个连环陷阱的每一步，让它不会在你身上重演。 一、事故时间线：1....

引言 上个月联调一个新模块，团队里发生了经典的一幕：后端小哥在终端里敲 grpcurl 敲得飞起，测试同学凑过来问"Postman 里怎么没有这个接口？"——一句话暴露了两个事实：一是我们的接口早就不是"清一色 REST"了（gRPC 做内部服务、WebSocket 做实时推送、MQTT 做设备接入、Kafka 做事件总线），二是调试工具的口味还停留在 HTTP 时代。 拿 Postman 硬调这些协议，结果都是"能用但别扭"：gRPC 要手写一坨 proto 导入流程；WebSocket 能连但历史消息和定时发送都缺；MQTT 和 Kafka 更是基本无能为力。这五个协议各自有专门的调试工具，用对了效率翻倍： 工具协议形态一句话定位 grpcurlgRPC命令行gRPC 界的 curl，CI 脚本和快速验证都靠它 BloomRPCgRPCGUI像 Postman 一样点点点调 gRPC WebSocket KingWebSocket浏览器插件浏览器里直接连 WS 收发消息 MQTT ExplorerMQTT桌面客户端主题树可视化，一眼看清设备上报了什么 Kafka UIKaf....

引言 去年给订单系统加了个"AI 助手"，产品经理的原始需求只有一句话："用户在对话框里说'帮我查下最近的订单'，助手能直接把订单查出来回他。" 第一版我做得很快：关键词匹配 + 意图分支。if (msg.contains("订单")) 就查订单，if (msg.contains("退款")) 就走退款——上线三天，就暴露了灾难现场： 用户说"我的单子怎么还没到"——不含"订单"关键词，助手回复"抱歉我不明白您的意思" 用户说"昨天买的那杯咖啡去哪了"——命中了"咖啡"关键词，走错了咖啡优惠券分支 每加一种问法，就要加一组关键词、多一层 if——我在用代码模拟一个自然语言理解系统，而大模型本身就是干这个的 后来换成 Function Calling，思路彻底反转：我不写任何意图判断，只把 Java 方法"介绍"给大模型（方法名、用途、参数说明）。用户说"帮我查最近的订单"，大模型自己决定该调 getOrders，自己从对话里抽取参数（limit=5），Spring AI 帮我执行方法、把结果喂回去——意图识别、参数抽取这两件最难的事，全部交给了模型；Java 代码里只剩纯粹的业务方....

引言 上周领导在周会上问了一个问题："我们的日活用户到底有多少？哪个接口被调得最多？"团队沉默了几秒——产品有埋点方案，但排期在两个月后；数据组说要做完整的 BI 体系；风控那边倒是有数据，但要走数据同步流程。 散会后我打开 Kibana 看了看我们早已在采集的 API 访问日志，突然意识到：答案其实一直躺在日志里。每条 API 日志里有 userId、接口路径、响应码、耗时、时间戳——DAU 就是 userId 的去重计数，接口 TOP10 就是一次 terms 聚合，异常率就是 status≥500 的占比，慢接口排行就是耗时字段的 top_hits。不需要埋点、不需要加 SDK、不需要排期，把日志结构化好，Kibana 拖拖拽拽就是业务大屏。 这篇文章把这套"穷人版 BI"完整讲一遍： 链路：Logback 结构化日志（JSON）→ Filebeat 采集 → Elasticsearch 存储 → Kibana 可视化，每个环节怎么配 四个实战指标从日志里"算"出来：DAU、接口调用 TOP10、异常率趋势、慢接口排行 完整可抄的配置：Logback JSON 配置 + Fil....