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

引言 客服机器人上线一周，用户的吐槽集中在一句话上："它是不是失忆了？" 用户：我上周买的那双跑鞋想换货，订单尾号 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 个，一周后池就被抽空，而且时间点毫无规律，重启只能续命。这篇文章完整复盘一次真....

引言 从 MySQL 转 PostgreSQL 的团队，第一个月往往觉得"索引嘛，还不都是 B+ 树那一套"，直到在 SQL 里写下 WHERE tags @> ARRAY['新品'] 和 WHERE detail @> '{"city":"上海"}' 才发现：B-tree 对数组、JSONB、全文检索、几何范围这些条件根本无能为力——你可以给数组列建 B-tree，但它只索引整个数组字面值，永远不会为"数组包含某个元素"这类查询服务。 PostgreSQL 与 MySQL 在索引上最大的不同，是它把索引框架做成了可扩展的：不同的数据形态和查询模式，配不同物理结构的索引。这篇文章讲清生产中最常用的四类——B-tree（默认主力）、GIN（倒排，JSONB/数组/全文检索）、GiST（几何/模糊/最近邻）、BRIN（超大有序表的极简索引），每个都给建索引语句、匹配的查询操作符、EXPLAIN 验证方法，以及体积/写入代价的实测量级。选错索引类型时"明明建了索引却走全表扫"的困惑，看完这篇就没了。 一、先有全局观：四种索引解决四种不同的问题 索引物理结构直觉最擅长的查询典....

引言 "商品表要加扩展属性，每个品类的字段都不一样，手机有内存和屏幕、服装有尺码和颜色、食品有保质期——要不我们引入 MongoDB 吧？" 这句话在架构评审会上出现过无数次。听起来很合理：灵活结构、文档存储、不用改表。但真把 MongoDB 引进来之后，团队往往在第三个月开始还债：商品基础信息在 PG、扩展属性在 Mongo，下单事务跨两个库没法保证一致；报表要 JOIN 订单和商品属性，只能在应用层拼；运维多一套副本集、备份、监控，DBA 又是另一套技能栈。 "有半结构化数据"不等于"需要一个文档数据库"。PostgreSQL 的 JSONB 类型把"文档的灵活性"和"关系数据库的能力"合在了一个库里：JSON 可以存任意结构，同时享受强类型校验、GIN 任意键索引、标准 SQL 查询和真正的 ACID 事务——商品基础列和扩展 JSON 在同一行、同一事务、同一条 JOIN 语句里。这篇文章讲清 JSONB 的真实能力边界和五个落地场景，回答那个反复出现的问题：到底什么时候该用 JSONB 扛住，什么时候才真的需要 MongoDB。 一、先搞清楚：JSONB 到底是什么，和 M....

引言 周三下午三点，客服群开始零星弹出同一句话："系统又打不开了，刷新一下又好了。" 监控上看服务实例全是绿色、健康检查通过率 100%、CPU 内存都正常，但 Nginx 的 502 曲线每隔十几分钟就冒一个小尖峰。我们登录服务器查后端应用日志——一片平静，ERROR 一个没有，连对应的访问记录都找不到。 这就是 502 类问题最迷惑的地方：报错发生在 Nginx，但根因往往不在 Nginx；后端日志干干净净，不是因为没问题，而是请求压根没走到（或没走完）业务代码。 这次排查从一行 upstream timed out 出发，顺着四层往下挖：Nginx 层超时 → JVM 层发现 GC 停顿 → 线程层发现请求排队 → 连接池层发现连接被慢 SQL 占满，最终拼出完整根因链。这篇文章把这条链路、每一步的排查命令、以及修复时的超时层级设计完整复盘。 一、现场：偶发 502，"偶发"才是最难的部分 1.1 故障特征 观察项现象 发生频率工作日下午集中，十几分钟一次，每次持续几秒到几十秒 用户体感页面转圈很久 → 502，立刻重试大概率成功 Nginx 监控502 率平时 0，尖....

引言 "你说你熟悉 MySQL 索引，那我问你：索引为什么用 B+ 树？" 这是后端面试的经典开场。很多候选人的回答是"B+ 树查询快"——这个答案等于没说，哈希表查询 O(1) 岂不是更快？也有人答"B+ 树是平衡树"——红黑树也是平衡树，为什么不用？当面试官追问"那 B 树呢，B+ 树到底比 B 树强在哪"，大部分人就卡住了。 这个问题答不好，不是因为 B+ 树有多难，而是思考顺序错了：一上来就背 B+ 树的特点，却没有先回答"数据库索引的约束条件是什么"。答案的第一性原理其实只有一句话：磁盘随机 IO 极贵，索引结构的唯一设计目标，就是用最少的磁盘读取次数找到数据。理解了这一句，哈希、红黑树、B 树为什么落选，B+ 树为什么胜出，全部可以自己推导出来，根本不用背。这篇文章就从磁盘 IO 的成本讲起，把四种结构放在同一个标尺下一较高低，最后给出 InnoDB 里的真实数字和面试回答话术。 一、先立标尺：一次磁盘随机 IO 到底有多贵 1.1 数字说话 操作大致耗时（数量级） CPU 访问 L1 缓存~1 ns CPU 访问主存~100 ns SSD 随机读（4KB）~50....

引言 "我们要不要把数据库从 MySQL 换成 PostgreSQL？"——这个问题在我们团队被反复问了三次：第一次是听说同行都在用 PG，第二次是要做向量检索，第三次是被一个复杂报表 SQL 折磨了一周之后。三次的答案不一样：第一次没迁（纯跟风没有痛点），第二次新业务直接选了 PG（pgvector），第三次核心库做了完整评估后只迁了分析库。 "要不要迁"从来不是技术优劣题，而是成本收益题。PG 确实有大量 MySQL 没有或更强的能力（JSONB、物化视图、PostGIS、扩展生态），但 MySQL 也有它的优势：运维人才多、主从复制简单、大厂云服务成熟、简单读写下性能稳定。盲目迁移的团队往往在第一个月就被"ON UPDATE 居然不自动更新时间戳""字符串不能隐式等于数字"这些差异绊倒。这篇文章回答两个问题：PG 到底强在哪（七个能力点逐项对比），以及动手前必须完成的五个评估，文末附一份可以直接贴在 wiki 上的 MySQL vs PG 语法差异速查表。 一、先给结论：什么情况值得迁 情况建议 标准 CRUD、单库 < 千万级、团队只会 MySQL、没有特殊需求....

引言 表结构迁完了、数据也灌进去了，应用一连数据库，报错像连珠炮一样蹦出来：column "user_id" does not exist（明明字段就在那）、operator does not exist: integer = character varying（参数类型不对）、syntax error at or near "LIMIT"（LIMIT 两个参数写反了）……我们迁第一个服务时，300 多条 MyBatis SQL 在测试环境跑出了 70 多个语法错误，全部集中在同一批高频差异上。 MySQL 的哲学是"我尽量帮你跑"，PostgreSQL 的哲学是"写错了我就报错"。这篇不讲选型（那是上一篇《为什么迁移》的事），只解决迁移动手时的具体问题——把返工率最高的 10 个语法差异逐个列透：每一个都给 MySQL 写法、PG 写法、错误现场和修复，MyBatis 项目额外标注 XML 适配要点。建议直接收藏，迁移时对照逐条改。 差异 1：自增主键 AUTO_INCREMENT → IDENTITY（SERIAL 能用但不推荐） MySQL CREATE TABLE t_ord....

引言 "帮我看看昨晚订单服务为什么变慢了。" 这句话背后至少有三个动作：查日志里有没有异常堆栈、查监控里 CPU/延迟/QPS 的曲线、把两边的线索拼成一份事故结论。我们最初把所有 @Tool 挂在一个 Agent 上让它自己规划，跑了两周发现三个问题：工具越加越多（查日志、查指标、查链路、查发布记录……12 个工具）后模型开始选错；每个工具的返回值都进同一个上下文，日志片段和指标数据互相干扰；提示词里"日志专家"和"监控专家"的行为要求互相打架，模型谁的都不听。 解法是从"一个全能 Agent"换成"一个主管 + 多个专家"：主管 Agent 只负责听懂需求、拆解任务、汇总报告，手底下没有具体工具；三个执行者 Agent 各自只带自己领域的工具、用自己的专家提示词，并行干活、结果上报。这篇文章用 LangChain4j 实现一个智能运维助手：主管拆解 → 日志/监控执行者并行调查 → 主管汇总成报告，并重点讲清单 Agent 的瓶颈、并行编排的确定性收敛（防止主管反复派活死循环）、以及新增 Agent 不改编排代码的注册表设计。 一、先想清楚：单 Agent 为什么不够用 1.1 ....

引言 团队从 MySQL 切到 PostgreSQL 的头两个月，最常听到的一句话是："PG 挺好用的，但我连哪个 SQL 最慢都看不到。" 工具没跟上，数据库的能力就发挥不出来——pgvector 装好了不知道怎么验证索引有没有生效、时序表建好了查询还是全表扫、排查性能问题只能靠 explain 一条一条手动跑。 PostgreSQL 的生态哲学和 MySQL 不太一样：核心数据库保持精简，能力通过"扩展（extension）"按需叠加。这篇文章盘点 5 个覆盖"日常管理 → 通用客户端 → SQL 性能分析 → AI 向量检索 → 时序数据"全场景的必备工具，每个都给出安装方式和高频使用方法——其中两个是 GUI，两个是扩展，正好串起 PG 开发的完整工作流。 工具类型解决什么问题 pgAdmin 4官方 GUI图形化管理 PG，浏览器/桌面双模式 DBeaver跨库通用客户端一个工具连 PG/MySQL/ClickHouse，ER 图/数据传输强 pg_stat_statements内置扩展找出最慢/最费资源的 SQL，性能分析第一入口 pgvector扩展在 PG 里存....

引言 改一行代码验证一下，等 Maven 打包 5 分钟——一天改 20 次，一个半小时就花在盯着进度条上。这不是段子，是我们一个 40 模块的 Spring Cloud 项目的真实日常：mvn clean package 全量跑一次 4 分 50 秒，其中测试 1 分 20 秒、Checkstyle 30 秒、重复下载插件 40 秒、真正的编译只占 40 秒，剩下的时间全在串行等待。 更气人的是这些时间大多是白花的：模块之间明明没有依赖关系却串行构建；只改了一个类却全量重编译；本地仓库明明有依赖还要去远程检查更新。我们花了一个下午做了五件事，本地打包从 5 分钟降到了 30 秒左右（全量冷构建 1 分 10 秒），CI 平均构建从 6 分钟降到 1 分 40 秒。这篇文章把五个手段从配置到坑点一次讲清——它们不是互斥的银弹，而是分别打掉耗时构成里不同的部分。 先看我们的耗时构成基线（提速前，40 模块，MacBook Pro M1 Pro）： 全量 mvn clean package：4分50秒 ├─ 依赖解析/插件下载检查 40s ├─ 编译（大量模块串行+全量） 1分50秒 ├─....

引言 大促零点，商品详情页开始变慢。排查发现不是详情服务自己的问题——它依赖的评价服务有个慢 SQL，每个请求卡 3 秒。详情服务用默认的 Tomcat 200 线程池，请求一个接一个堵在评价服务调用上，200 个线程 30 秒内全部占满，详情服务整个挂掉；网关又把流量继续往这个已经挂掉的实例转，雪崩从评价服务蔓延到详情页，再到下单链路。 雪崩的本质是"故障传导没有刹车"：下游慢 → 上游线程被占满 → 上游也慢 → 更上游继续堆。Sentinel 就是这个刹车——在调用入口实时统计 QPS、响应时间、异常比例，超过阈值立刻拦截或熔断，不让故障穿透到下一跳。这篇文章从三种核心能力的原理讲起，完成 Spring Cloud Alibaba 集成、控制台规则、@SentinelResource 兜底、Nacos 持久化的完整落地，最后给生产级规则配置清单。 一、三种核心能力：限流、熔断、降级的关系 很多人把这三个词混着用，它们其实是三个独立环节： ┌─────────────────────────────────────┐ 请求进来 ─────→ │ ① 限流：流量超过阈值，直接拒绝（....