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

引言 周三下午 2 点，运营群反馈"用户行为分析看板打不开了"。运维查 Redis 监控：CPU 正常、内存正常、连接数正常，但命令延迟 P99 从 2ms 飙到 800ms——看起来一切正常却慢得离谱。接下来 10 分钟，越来越多的接口开始超时，告警从 3 条涨到 47 条，最终整个 Redis 集群不可用。 排查发现：一个名叫 user:behavior:all 的 Hash Key，存了全量用户行为日志，200MB。更致命的是，运维在试图 DEL 这个 Key 时，Redis 主线程被阻塞了 3 秒——3 秒内所有命令排队等待，集群雪崩。 根因出奇简单：业务把用户行为日志全塞进一个 Hash，没设过期时间，日积月累从 2KB 长到 200MB。Redis 是单线程的——一个慢命令阻塞主线程，整个实例都卡住。这篇文章从发现到修复完整复盘，附大 Key 扫描脚本和预防机制。 一、为什么一个大 Key 能拖垮整个集群 1.1 Redis 单线程模型 Redis 主线程（单线程处理所有命令） │ ├─ 命令1: GET user:1001 0.01ms ├─ 命令2: SET toke....

引言 "你简历上写了分布式锁，说说怎么实现的？"——这是 Java 后端面试的高频题。大部分候选人的回答停留在"用 Redis 的 SETNX"——面试官追问三个问题就卡住了：锁过期了任务还没执行完怎么办？Redis 主从切换锁丢了怎么办？同一个线程递归调用能不能重入？ 这三个问题才是分布式锁的真正考点：SETNX 只是"加锁"这一个动作，而分布式锁的完整语义包括——互斥、防死锁、可重入、防误删、续期、故障容忍。每一项都有对应的坑和解决方案。这篇文章从"为什么需要分布式锁"讲起，对比数据库/Redis/Zookeeper 三种实现的底层原理，再深入 Redisson 看门狗的自动续期机制，最后逐一拆解三大坑的成因与解法。 一、为什么需要分布式锁 1.1 本地锁管不住分布式场景 // 单机时代：synchronized / ReentrantLock 就能解决并发 public synchronized void deductStock(Long skuId) { Stock stock = stockMapper.selectBySkuId(skuId); if (stock.get....

引言 "我们想做一个 AI 客服"——产品同学在需求会上说。"简单，接个 GPT API 不就行了？"——这是 90% 团队的第一反应。然后做完发现：用户说"帮我查一下订单 SO20250912001 的物流"，模型回了一句"作为 AI 助手，我无法查询您的订单"。 问题出在哪？接了个聊天 API，不是做了个 Agent。聊天 API 只能基于训练知识"说话"，不能"做事"——查不了数据库、调不了接口、记不住用户身份。Agent 的本质区别不是"更聪明的聊天"，而是"LLM + 工具 + 记忆 + 规划"四件套的组合体：LLM 是大脑，工具是手脚，记忆是上下文，规划是行动方案。 这篇文章是 AI Agent 系列的开篇，用 LangChain4j 拆解 Agent 的四层架构，最后给一个能跑的最小 Agent——它能在"我帮不了你"时主动调工具查数据库，在多轮对话中记住你是谁。全程纯 Java，不写一行 Python。 一、Agent 的本质：不是聊天，是行动 1.1 聊天 vs Agent 的区别 用户：帮我查一下订单 SO20250912001 的物流状态 聊天 API（gpt-....

引言 "让 AI 帮我写了个工具类，review 时发现连参数校验都没有，单测覆盖率 0%。"——这不是 AI 不行，是 prompt 不行。大部分开发者用 AI 写代码的方式是："帮我写一个 XX 工具类"——这就像跟新人说"做个订单功能"然后期望他交付生产级代码。 AI 的输出质量 = prompt 的精确度。同一个需求，"帮我写个单测"出来的测试覆盖三条路径，而"用 JUnit5 + Mockito，覆盖正常/边界/异常三个维度，覆盖率目标 90%，Mock 外部依赖"出来的测试能直接进 CI。差距不在模型能力，在 prompt 的约束密度——你把技术栈、质量标准、验收口径告诉它，它就按工程标准交付；你只说个大概，它就给你个大概的东西。 这篇文章给 Java 开发者 5 个可以直接复制粘贴的 prompt 模板，每个覆盖一个高频场景：单元测试、代码重构、性能优化、Bug 定位、技术选型。每个模板给完整示例 + 调优技巧，模板里的方括号 [...] 是你要替换的变量。 一、模板一：单元测试生成 1.1 模板 你是一个资深的 Java 开发工程师，请为以下方法生成单元测试。 【技术....

引言 大促压测到第 8 分钟，订单服务调用库存服务开始超时。运维的第一反应是调超时时间——把 Feign 的 readTimeout 从 3 秒调到 10 秒，结果更糟了：原本 3 秒失败的请求变成 10 秒失败，线程池被占满，订单服务自己也被上游超时拖垮，整条链路雪崩。调回来想加重试，又发现库存扣减接口不是幂等的——重试一次多扣一遍库存。 这三种痛——超时设多少、重试敢不敢做、调用链断了怎么定位——是微服务调用链治理的核心三问。本文用 OpenFeign + Sentinel + OpenTelemetry 三件套一次配齐，附完整配置和踩坑清单。 一、超时与重试：不是设个数就完事 1.1 超时双层模型 客户端发请求 ──connectTimeout(2s)──→ 建连成功 ──readTimeout(5s)──→ 收到响应 │ │ │ 连不上 │ 连上了但响应慢 ▼ ▼ 连接超时（网络不可达/队列满） 读取超时（下游处理慢/GC/锁等待） 参数含义默认值调优方向 connectTimeout建立 TCP 连接的超时10s（太久）调到 1~2s（连不上就是连不上，别等） r....

引言 "AI 这波我们 Java 开发者能不能不学 Python 也跟上？"——这是过去一年团队里被问得最多的问题。确实，AI 生态的教程九成是 Python 的，LangChain、LlamaIndex、各种 Agent 框架，清一色 pip install。Java 开发者想做一个"接入大模型的客服助手"，面对的是 Python 教程里 from langchain.chains import xxx 的陌生世界，而团队的技术栈、CI/CD、监控、服务治理全是 Java 的——为了一个 AI 接口引入 Python 技术栈，代价远大于收益。 LangChain4j 就是 Java 开发者对这个问题的回答：它把 LangChain 的核心能力（LLM 抽象、提示词模板、记忆、RAG、Agent/Tool Calling）用纯 Java API 重新实现，和 Spring Boot 无缝集成，不需要写一行 Python。这篇文章盘点 LangChain4j 生态里 Java 开发者做 AI 应用的 5 个必备组件，从核心抽象到向量存储到 Spring Boot 集成，每个组件给定位、核....

引言 上周四晚上，运维同学改了一个 Redis 连接池参数，然后经历了这样的流程： ① 改 application.yml → ② git commit → ③ Jenkins 构建 → ④ 打包 → ⑤ 上传服务器 → ⑥ kill -9 停服务 → ⑦ java -jar 启动 → ⑧ 健康检查 → ⑨ 通知客服切换流量 → ⑩ 全过程 12 分钟 改一个参数，12 分钟。如果这个参数改错了，再来 12 分钟。一晚上能改几次？更尴尬的是安全审计那天扫出的配置文件截图： spring: datasource: password: "P@ssw0rd!2024" # 明文密码进了 git redis: password: "redis123" # 明文密码进了 git cloud: alibaba: seata: password: "seata@prod" # 明文密码进了 git 三个生产密码在 git 历史里躺了两年，谁 fork 过、谁 clone 过，全不可追溯。 配置管理的三个痛点——改配置要重启（12 分钟）、多环境配置混乱（dev/test/prod 靠 yml 文....

引言 凌晨 3 点被电话叫醒，打开日志发现定时任务又双击了——上次跑的实例还没结束，这次又开始了，两份并行把库存扣了两遍。这不是什么复杂的分布式 bug，就是单机 @Scheduled 在多实例部署下没有做幂等也没有做调度协调，各跑各的。 找运维要个控制台看看任务状态，答："没有控制台，任务定义在代码里，改 Cron 要重新发版。" 要个失败重试和告警，答："自己写 log + 钉钉机器人。" 要个任务执行历史，答："去 ELK 里搜。" @Scheduled 是个很好的起点，但业务长到"多实例部署 + 任务可视化 + 动态调整 + 失败告警"这四件事里的任何一个，它就不够用了。 团队开始找替代方案：Quartz？XXL-Job？PowerJob？每个方案看起来都能解决一部分问题，但谁也说不清哪个最适合自己。这篇文章把四个方案按"从简单到复杂"排开，逐个拆解能力边界，最后给一张决策树——照着选就行。 一、四个方案速览 1.1 一句话定位 方案一句话定位调度 vs 执行 @ScheduledSpring 原生注解，单机定时器应用内线程池 QuartzJava 生态老牌调度框架，....

引言 三年前我们把单体拆成微服务时，调用关系是这样配置的： # order-service/application.yml user-service: url: http://10.0.1.23:8081 # 用户服务写死 IP stock-service: url: http://10.0.1.24:8082 # 库存服务写死 IP 第一次故障来得毫无悬念：用户服务那台 1.23 物理机宕机，运维紧急在 1.55 拉起实例，然后挨个改 20 个服务的配置、重启、祈祷没有漏网之鱼——光改配置就花了 40 分钟。第二次故障更尴尬：大促临时扩容 10 台库存服务，新实例起来后订单服务一个都调不到——没有地方让它知道“新来的兄弟住在哪”。 IP 漂移（实例挂了换机器）和动态扩容（实例数量随时变）这两个问题，本质上是同一个诉求：服务之间不能用"写死地址"通信，必须有一个"地址簿"动态维护"谁在线、住哪、健不健康"——这就是注册中心。 但选哪个地址簿，团队一直有分歧：老系统跑着 Eureka，新架构组推 Nacos，运维同学说他们更熟 Consul。 这篇文章把注册中心的本质讲透，再对三个候选....

引言 系统拆成微服务后第一个要回答的问题就是：服务之间怎么调？ 这个选择 90% 的团队是在"沿用上一代的习惯"中度过的——Java 老项目接着用 Dubbo，Spring Cloud 全家桶自然 Feign，新起的多语言团队上 gRPC。但真到大促压测时，选型的差异会以三个维度同时砸到你脸上：一个下单接口拆成"订单调库存"两段后，吞吐掉了 40%——这 40% 是消耗在了网络、序列化还是连接管理上？换一个框架能追回来多少？ 带着这个真实场景的问题，我们做了一次严格对照的压测：同一套业务接口（扣减库存），用 Feign、Dubbo、gRPC 三种方式各实现一遍，在同一台机器、同一套 JMeter 10,000 并发口径下跑。这篇文章完整记录测试方法、数据、三个框架各自的胜场与代价，最后给一张选型决策表。 一、三位选手速览 1.1 一句话定位 框架一句话定位本质协议 FeignHTTP 声明式客户端，Spring Cloud 标配，写接口像调本地方法HTTP/1.1 + JSON Dubbo阿里出品的高性能 RPC 框架，TCP 长连接 + 自定义序列化TCP + Dubbo ....

引言 看一眼我们线上早期接口的报错，很容易理解为什么前端同学会崩溃： {"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 的效果问题要先拆开看，不同层的问题药方完全不同： 指标定义反映哪层的问题 ....