归档

问题代码：第一版大模型调用把线程池打满了 四月我们想给工单系统接一个大模型做自动摘要。第一版我图省事，用 RestTemplate 直接 POST 到 OpenAI 兼容接口，同步等返回。压测一上来就出问题：模型平均响应 3 秒，线程池 200 个线程 10 秒就被占满，QPS 卡在 60 上不去。

告警：凌晨三点的慢查询邮件 四月某天早上，运维把一封告警邮件转给我：「日志检索接口 P95 超过 8 秒，ES 集群 CPU 打满」。我们的应用日志一直存在 Elasticsearch 里，单日写入约 30 亿条，随着业务量涨，ES 的堆内存和查询延迟都快撑不住了。老板提了个方向：能不能把明细日志搬

背景：一个 RAG 需求把选型问题拍到了脸上 三月初产品提了个需求：把过去三年积攒的技术工单做成内部知识库，让用户用自然语言提问。核心就一步——向量相似度检索。团队当时在 Milvus、PGVector、Redis 三套方案里反复横跳，谁也说服不了谁。我干脆拉了一台 16C32G 的机器，把三套都跑

给内部文档做个能问答的机器人 公司几百份技术文档散在 Wiki，搜起来费劲——关键词搜只能匹配字面，问"怎么处理订单超时"搜不到"订单 30 分钟未支付自动关单"的那段。我想用 RAG（检索增强生成）做个问答，让模型"先查资料再回答"。2023 年初这套链路在 Java 侧得自己拼，没有现成框架，正

每天 300 万条的对账 财务对账原来用 crontab + 一个 main 方法跑，失败了从头来，半夜崩了没人管。最惨的一次，任务跑到一半数据库连接断了，已处理的 150 万条没记录，重跑又重复处理了一遍，对账差了几十万。换成 Spring Batch 后，断点续跑和重试才真正可控，凌晨的 job

中文向量化的尴尬 做知识库检索时，第一步就是把文档切块转成向量。英文世界有现成的 sentence-transformers，中文呢？2023 年初这块还很青涩，我踩了一圈坑，记下来给后来者省时间。当时我们想给内部 Wiki 做语义搜索，先用英文模型试，中文召回烂得一塌糊涂，才意识到"中文 embe

一次没顶住的流量 去年大促，预估峰值 8000 QPS，实际来了 1.4 万，订单服务被打挂 12 分钟。复盘发现：我们的容量评估靠的是"去年×2"的拍脑袋，没有真实压测支撑，对系统的真实拐点一无所知。那天凌晨告警炸了，扩容来不及，限流没配，全靠手动重启扛，资损不小。这次我把容量评估正经做了一遍，把

几个年头里反复踩的坑 建表时随手选类型，上线后不是慢就是错。我整理了团队里最高频的几类字段选型问题，新项目开工前照着过一遍。这些坑每一个都对应过一次线上事故或一次漫长的数据迁移，所以值得写下来反复提醒。 varchar 长度 有人图省事一律 varchar(255)，其实 MySQL 在 utf8m

Java 也要有自己的 AI 抽象层 2023 年初，Python 侧 LangChain 已经热闹非凡，Java 这边还在各自调 OpenAI 的 HTTP。我们团队想给内部系统接个问答能力，结果每个项目都自己封装一套 OkHttp 调用，模型一换全部重写。Spring 社区开始孵化一个叫 Spr

把线程池换成虚拟线程 我们有个网关聚合服务，每请求要并发调 5 个下游，原来用 200 个平台线程的池子，峰值打满就排队。用户多的时候，线程池耗尽，请求在队列里干等，RT 从 200ms 飙到 2 秒。听说 JDK 19 的虚拟线程能把"一个任务一个线程"做到近乎免费，就拿来做了对照实验，想看看是不