缓存和数据库又双叒不一致了 我们的商品详情页用"先更新 DB，再删缓存"的策略。大多数时候没问题，但运营一次批量改价后，部分用户看到的价格还是旧的，持续了十几分钟。根因是并发下的时序问题：线程 A 更新 DB、还没删缓存时，线程 B 读了旧 DB 值并写回缓存，导致 A 的删除"删了个寂寞"，脏数据
一个 ES 查询，把节点 CPU 打到了 95% 运营后台有个"订单检索"接口，平时挺快，某天加了"按创建时间排序 + 关键词模糊"后，单查询 CPU 占用飙升，集群一个节点到了 95%，其他查询全被拖慢。我用 profile API 抓了执行计划，发现罪魁是把本该放 filter 的条件写进了 q
升级 Redis 7.0 时，我把一段 Lua 脚本换成了 Functions 4 月 Redis 7.0 正式发布，我们把集群从 6.2 升到 7.0。升级本身平滑（RDB/AOF 兼容），但翻 release notes 时发现一个我一直想要的东西：Redis Functions。我们原本用 L
集群重启后要 40 分钟才能变绿，问题出在分片数 我们用 ES 做商品搜索和日志检索，版本从 7.15 升到 8.0（2022 年 2 月发布，正式用上）。3 月一次故障演练，重启集群后主分片恢复花了 40 分钟才变绿，期间搜索不可用。排查下来，根因是分片数设错了：一个 200 GB 的索引被切成
大促压测：Redis 被打到 12 万 QPS，还是扛不住 3 月大促前做全链路压测，商品详情页的接口目标 5 万 QPS。单 Redis 集群（3 主 3 从，Redis 6.2）在 12 万 QPS 时 CPU 跑满，P99 从 3 ms 飙到 47 ms，再往上就开始超时。加节点成本太高，而且
日志里那句 IllegalMonitorStateException 12 月初，结算服务凌晨报警了几次，错误信息很眼熟： java.lang.IllegalMonitorStateException: attempt to unlock lock, not locked by current th
压测报告里那行 P99 把我叫住了 11 月中旬做双十一前的容量压测，商品详情接口 3000 QPS 下 P99 是 42 ms，还算好看。压到 6000 QPS 的时候 P99 直接跳到 180 ms，而且曲线是锯齿状往上爬，不是平稳的。同时 Redis 集群 CPU 到了 61%，带宽 780
升级背景：单核 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
