语义缓存上线一个月，命中率 8.3% 三月份我们给客服 Agent 上了语义缓存，预期是「相似问题不用重复问模型，能省一大笔钱」。上线一个月看数据，命中率 8.3%，省下的钱还不够维护缓存本身的成本。 这篇文章记录我们怎么把命中率从 8.3% 提到 41%，以及中途推翻重做的一版设计。 先看为什么这
压测卡在 400 QPS 上不去 知识库问答系统三月中旬做上线前压测，目标 800 QPS，结果压到 400 就开始大量超时。看 Grafana 面板，网关 CPU 才 40%，数据库连接池很闲，但整体 P99 已经飙到 3.2s。 拿 async-profiler 抓了 60 秒火焰图，TIME_
语义缓存一直跑在 Redis Stack 上，Redis 8 说要合并进来 我们的语义缓存从 2024 年 9 月开始就跑在 Redis Stack 上（就是那个带 RediSearch 模块的发行版）。这套方案最大的别扭之处是：它跟官方主线版本是两套东西，运维要单独装，升级要跟 Stack 的节奏
搜索改版做了三个月，用户还在搜不到东西 公司的技术文档站搜索，原来是纯 Elasticsearch BM25。今年 8 月我接手改版，第一版直接换成了向量检索，想着"语义搜索肯定更强"。上线一个月，搜索结果的点击率从 68% 掉到 51%，用户投诉反而变多了。 我把 200 条低点击率的 query
客服机器人上线两周，P95 首字延迟 4.2 秒 9 月初，我们给内部工单系统做的智能客服上了线。第三天开始收到投诉："问一句话要等四五秒才出字"。我拉了 Grafana 看，数据比投诉描述的还难看： gateway_request_duration_seconds{quantile="0.95",
LLM 调用账单太吓人 工单助手每天上万次调用 GPT，账单一个月涨到三千刀。财务找过来时我才认真看数据：大量 query 语义相近（"怎么退货""退货流程""我要退钱"），答案其实一致，却每次都花 token 去问模型。用 Redis Stack 的向量检索做"语义缓存"，把相似问题直接命中缓存，
半夜被内存告警叫醒 Redis 实例内存从 4G 一夜之间冲到 14G，触发了 maxmemory 限制开始淘汰 key，部分缓存击穿打到数据库，数据库 CPU 跟着飙到 90%。我登录上去按几个维度逐一排查，过程比想象的有条理。Redis 内存暴涨不是玄学，按固定顺序查基本能覆盖绝大多数情况。 先
想给搜索加上"语义" 我们的商品搜索一直靠关键词匹配，用户搜"适合送妈妈的礼物"这种长尾 query 基本搜不到，因为标题里没有这几个字。运营天天抱怨转化差。ES 8 增强了 dense_vector 和 kNN 检索，我试着把商品标题做成向量塞进去，让语义相近的也能召回，点击率明显好转。这里把建模
告警：凌晨三点的慢查询邮件 四月某天早上，运维把一封告警邮件转给我：「日志检索接口 P95 超过 8 秒，ES 集群 CPU 打满」。我们的应用日志一直存在 Elasticsearch 里，单日写入约 30 亿条，随着业务量涨，ES 的堆内存和查询延迟都快撑不住了。老板提了个方向：能不能把明细日志搬
我们为什么离不开 Nginx 后端是 Spring Boot 起的 8080 服务，但直接把 8080 暴露在公网既不安全也难扩展。一来没有 TLS 卸载，二来单实例挂了没容灾，三来限流得在每个应用里写。Nginx 在我们架构里身兼数职：反向代理、负载均衡、限流、长连接优化。它配一次能管一片服务，是
