语义缓存一直跑在 Redis Stack 上，Redis 8 说要合并进来 我们的语义缓存从 2024 年 9 月开始就跑在 Redis Stack 上（就是那个带 RediSearch 模块的发行版）。这套方案最大的别扭之处是：它跟官方主线版本是两套东西，运维要单独装，升级要跟 Stack 的节奏
LLM 调用账单太吓人 工单助手每天上万次调用 GPT，账单一个月涨到三千刀。财务找过来时我才认真看数据：大量 query 语义相近（"怎么退货""退货流程""我要退钱"），答案其实一致，却每次都花 token 去问模型。用 Redis Stack 的向量检索做"语义缓存"，把相似问题直接命中缓存，
半夜被内存告警叫醒 Redis 实例内存从 4G 一夜之间冲到 14G，触发了 maxmemory 限制开始淘汰 key，部分缓存击穿打到数据库，数据库 CPU 跟着飙到 90%。我登录上去按几个维度逐一排查，过程比想象的有条理。Redis 内存暴涨不是玄学，按固定顺序查基本能覆盖绝大多数情况。 先
升级 Redis 7.0 时，我把一段 Lua 脚本换成了 Functions 4 月 Redis 7.0 正式发布，我们把集群从 6.2 升到 7.0。升级本身平滑（RDB/AOF 兼容），但翻 release notes 时发现一个我一直想要的东西：Redis Functions。我们原本用 L
日志里那句 IllegalMonitorStateException 12 月初，结算服务凌晨报警了几次，错误信息很眼熟： java.lang.IllegalMonitorStateException: attempt to unlock lock, not locked by current th
升级背景：单核 CPU 打满了 11 月初我们把缓存集群从 Redis 5.0.9 升到了 6.2.5。起因很直接：大促前压测，某个分片的 CPU 到了 92%，但机器是 8 核的——也就是说 Redis 把一个核跑满了，剩下 7 个核在旁边看着。 $ redis-cli -h 10.0.4.11
32 G 内存的 Redis，用到 28 G 就没人敢再往里放了 3 月初做大促容量评估，缓存这块的数据很难看： $ redis-cli info memory used_memory_human:28.41G maxmemory_human:32.00G mem_fragmentation_rat
凌晨三点的抖动：Redis 响应时间突然飙到 800ms 九月九号大促那天晚上我值班，凌晨三点被叫起来。监控大屏上 Redis 的 P99 响应时间从平时的 0.4ms 冲到 812ms，持续了大概 40 秒，然后自己恢复了。 应用侧的连锁反应更难看：商品详情页接口 TP99 从 45ms 涨到 3
一个批量接口慢在哪：不是 Redis 慢，是网络慢 八月下旬优化一个批量查询接口。它要一次读 200 个商品的库存，我一开始的写法很直白： public Map<String, Integer> batchGetStock(List<String> skuIds) { Map<String,
大促前的准备：缓存预热到底该怎么做 八月中旬，运营定在 9 月 9 号做一场大促。我被分到的任务是"保证缓存不崩"，具体要回答两个问题：活动开始时缓存是空的怎么办？某个商品突然爆了怎么办？ 我们的缓存现状：Redis 6.0，一主两从 + 哨兵，单机 12GB。商品详情页的缓存是「被动」的——用户访
