归档

接了大模型问答的活儿，第一版我们用普通 HTTP 请求，前端点完"发送"就开始转圈，最长 18 秒才一次性吐出整段答案。产品同学盯着转圈圈说了一句话："能不能像 ChatGPT 那样一个字一个字蹦？"于是有了这次 SSE 改造。 SSE 是什么，为什么不用 WebSocket 大模型生成是单向的：服

去年底老板拍板：核心交易系统去 Oracle。理由很直接——一年 380 万的授权费，加上审计合规越来越严。我接手时第一反应是：这活儿坑比想象多，不是导出 SQL 再导入就完事。 先盘家底 系统跑了九年，Oracle 里不止 SQL。我用了两周做依赖盘点，列了一张表： 依赖类型 数量 风险 存储过程

背景：我们一套跑了五年的订单分析系统，主库是 MySQL 8.0，平时扛交易，月底还要跑 T+1 报表。一次月底大查询把从库 CPU 打到 100%，复制延迟一度飙到 47 秒，运营看板直接瘫痪。那一刻我意识到，把 OLTP 和重分析塞在同一套实例里，迟早出事。 为什么盯上 TiDB 当时评估了三个

把命运交給一家供应商太冒险 工单助手全量依赖 OpenAI，某次它区域性抖动 40 分钟，我们的自动回复全挂，运营被迫人工顶上，积压了上千条工单。AI 能力已经是生产依赖，就不能有单点。我搭了一套多模型路由加降级，核心：多供应商接入、健康检查、自动降级兜底。上线后两次抖动都平稳度过。 多供应商统一接

模型返回的 JSON 总在变花样 让 LLM 抽取工单里的"订单号、问题类型、紧急度"并输出 JSON，结果它时而多回一句解释，时而把字段名写成 order_num 而非 orderId，解析直接炸，下游拿到 null 又是一堆空指针。要做可靠的系统，结构化输出必须可控。我把"约束加重试加校验"几层

LLM 进了核心链路，黑盒就太危险 工单助手上线后，运营反馈"有时候答非所问"。但 LLM 调用对我们来说是个黑盒：不知道每次花了多少 token、耗时多少、模型返回了啥。更糟的是出了错没法归因。我参照传统可观测性，给 LLM 调用也接上了 Trace、Token 统计和效果评估三件套，才算把这层黑

LLM 调用账单太吓人 工单助手每天上万次调用 GPT，账单一个月涨到三千刀。财务找过来时我才认真看数据：大量 query 语义相近（"怎么退货""退货流程""我要退钱"），答案其实一致，却每次都花 token 去问模型。用 Redis Stack 的向量检索做"语义缓存"，把相似问题直接命中缓存，

Java 生态终于有了统一的 AI 门面 之前接 OpenAI 要手搓 HTTP，接 Azure 又是一套，模型一换代码重写。团队里三个人各自封装了一遍，接口还不一样。Spring AI 在 2024 年初推出 1.0 里程碑版本，把各家模型、向量库抽象成统一接口。我拿它重构了工单助手，迁移成本比预

半夜被内存告警叫醒 Redis 实例内存从 4G 一夜之间冲到 14G，触发了 maxmemory 限制开始淘汰 key，部分缓存击穿打到数据库，数据库 CPU 跟着飙到 90%。我登录上去按几个维度逐一排查，过程比想象的有条理。Redis 内存暴涨不是玄学，按固定顺序查基本能覆盖绝大多数情况。 先

内存曲线像极了漏水的水龙头 订单服务上线两周，Old 区内存从 1.2G 缓慢爬到 3.8G，Full GC 后也只回一点，没真正回落。不是突崩，是慢性失血。这种"缓增长"最容易被忽视，因为单次看都正常，直到某天 Old 区满了频繁 Full GC，接口全抖。我用多次 dump 对比把它揪出来，过程