-
我给一批缓存数据统一设了一小时过期、平时缓存命中率高得很数据库压力很小,可每隔整整一小时数据库就会突然被海量请求瞬间打垮、CPU 飙满响应超时,排查很久才惊觉那批缓存是同一时刻批量写进去的、于是又在同一时刻集体失效把流量齐刷刷地全砸向了数据库的深度复盘
我的系统在缓存里存了一大批热点数据(商品信息、配置项),为了定期刷新给每条都设了 TTL=1 小时,平时跑得非常好:绝大多数请求命中缓存根本不碰数据库、DB 的 QPS 低得可怜监控一片祥和。可诡异的事周期性发生:每隔大约一小时数据库就突然遭遇一波海量查询、QPS 瞬间冲到平时几十倍、CPU 打满连接池占爆大量超时,持续几秒到十几秒恢复、下个整点再来一次。我怀疑整点跑批(没有)、怀疑有人整点刷接口…- 0
- 0
-
一个被高频访问的热点缓存恰好过期的那一瞬间,几千个请求同时扑向数据库去重建它,瞬间把数据库打垮了:一次缓存击穿、热点 key 过期空窗的深度复盘
我有个被高频访问的热点数据放在缓存里、设了 5 分钟过期,平时读缓存命中一切顺滑。可某次监控突然报警数据库 CPU/连接数瞬间飙满、差点雪崩,恰好发生在那个热点缓存过期的那一刻。复盘那一瞬间才明白这是缓存击穿:那个 key 被每秒几千请求高频访问,当它到点过期从缓存消失的瞬间,几千个并发请求同时发现未命中、几乎同时全部扑向数据库去查数据重建缓存,本该由缓存挡住的几千 QPS 在这一瞬间全砸到数据库…- 0
- 0
-
我用 Redis 加了分布式锁保护临界区,以为万无一失,结果偶发两个进程同时进了临界区、一个进程还把别人的锁给删了:一次分布式锁实现陷阱的深度复盘
我有段临界区代码用 Redis 加了分布式锁保护:SET lock NX EX 30 抢锁、处理完 DEL 释放,以为万无一失。可线上偶发两个进程同时进入临界区的数据错乱,有时还有一个进程把另一个进程正持有的锁删了。推演时序才看明白这锁有两个致命漏洞:漏洞一,锁 EX 30 过期了但业务还没跑完,锁自动释放、B 抢到、A 和 B 同时在临界区;漏洞二,释放时直接 DEL 没校验是不是自己的锁,A …- 0
- 0
-
用户明明改了资料、刷新却还是旧的,排查发现是我更新数据库后顺手更新缓存在高并发下把旧值写回了缓存:一次缓存与数据库双写一致性、Cache-Aside 该删缓存而非更新缓存的深度复盘
我们的用户资料服务为扛读量加了 Redis 缓存,读走缓存未命中查库回填,写用我自以为周到的先更新数据库再顺手更新缓存。功能测着没问题,线上却偶发:用户改了资料、缓存却长期是旧值,刷不新直到过期才好。在并发场景下推演才看明白:更新库和更新缓存两步非原子,两个并发写请求 A、B 都先更库再更缓存,DB 最终是 B 的新值(对),但更新缓存时因线程调度 B 先写、A 后写,缓存被覆盖回 A 的旧值——…- 0
- 0
-
一个先更新数据库再删缓存的常规缓存写法,在一次并发读写恰好交错时,把旧数据又写回了缓存、脏了好久:一次缓存一致性的深度复盘
用 cache-aside(先更新数据库再删缓存)缓存商品,偶尔出现 DB 是新价、缓存却一直是旧价。根因是读写并发交错:缓存刚过期时读请求查 DB 读到旧值、还没回填,此时写请求更新 DB 并删缓存,然后读请求慢一步把旧值写回缓存、盖过了写的删除,缓存就脏到下次过期。本文讲透缓存和 DB 是两个独立存储、双写非原子、任何纯双写都有交错会不一致,给出 cache-aside+TTL 兜底(最关键)…- 0
- 0
-
一个只缓存查得到的数据的接口,被人用大量不存在的 ID 反复查询,缓存形同虚设、请求全砸到数据库上,差点把库打垮:一次缓存穿透的深度复盘
商品详情接口前面挡着 Redis,平时 DB 压力很小,某天 DB QPS 突然暴涨几十倍、缓存命中率却跌到 0。抓参数一看,请求查的全是不存在的随机 ID。根因是 cache-aside 只缓存查得到的非空结果:查不存在的 ID 时缓存没有、DB 也查不到、null 又不写缓存,于是每次都必然穿透直达 DB,被海量不存在 ID 攻击就把库打垮——这就是缓存穿透。本文讲透穿透与击穿、雪崩的区别,给…- 0
- 0
-
一个 Redis 分布式锁的过期时间没扛住业务耗时,锁提前自动释放让两个线程同时进了临界区、还互相误删了对方的锁:一次分布式锁失效的深度复盘
用 Redis 分布式锁保证同一笔账只有一个节点处理,跑了大半年都好好的,直到对账量大、业务跑了 40 秒、超过了锁的 30 秒过期时间——锁中途自动释放,第二个线程进了临界区两线程同时处理,第一个线程干完 del 又删掉了第二个线程的锁,锁彻底形同虚设。本文讲透分布式锁的两大核心难题(过期时间两难、误删),给出唯一标识+Lua 原子校验删除防误删、看门狗自动续期解决过期、生产用 Redisson…- 0
- 0
-
我用 Redis 做分布式锁防止任务被重复处理,结果先是一个实例崩了导致所有任务卡死,后来又出现同一个任务被两个实例同时处理,我对着分布式锁这几个致命实现细节排查了大半天的复盘
一个让我对分布式锁看着简单实则处处是坑彻底敬畏的架构坑,它教会我用 Redis 加把锁这件听起来一行代码搞定的事要真正正确实现需要考虑一连串容易被忽略的细节,漏掉任何一个锁就会在某种场景失效——要么死锁卡死所有人要么形同虚设根本没锁住。多实例下要保证同一时刻只有一个实例处理某任务,我用 Redis 分布式锁逐步踩坑:版本1 SETNX+DEL 没过期时间,持锁实例崩了锁永不释放全卡死(死锁);版本…- 2
- 0
-
一个超热点的商品缓存在过期那一瞬间,成千上万的请求同时涌向数据库去重建它,把 DB 瞬间打垮,我对着缓存击穿这个热点 key 过期引发的惊群效应排查了大半天的复盘
一个让我对缓存不是万能挡箭牌彻底清醒的架构坑,诡异在平时缓存把 DB 保护得很好负载很低,可某个特定瞬间 DB 会突然遭受排山倒海的并发冲击而崩溃——而这瞬间恰是某个最热门的缓存刚好过期那一刻。系统用 Redis 缓存商品详情设 1 小时过期,DB 监控却毫无规律间歇性出现瞬时高负载连接打满。代码是标准的读缓存没有就查 DB 回填。隐患在并发:一个爆款商品每秒上万请求,缓存过期那一瞬间这上万并发几…- 0
- 0
-
我用 Redis 加了分布式锁防并发,结果两个进程还是同时执行了、还互相把对方的锁删了,我对着分布式锁的几个致命细节排查了大半天的复盘
做了个多实例部署的定时任务,用 Redis 加分布式锁确保同一时刻只有一个实例执行,以为加了锁就万事大吉。结果生产诡异:有时两个实例同时跑(锁没锁住)导致数据重复处理,有时一个实例把另一个实例的锁删了。盯着 SETNX 抢锁、DEL 释放的标准代码反复看,排查大半天才发现藏着三个致命细节:SETNX 没设过期(持锁者崩溃就死锁)、锁提前过期(业务跑40秒超过锁30秒过期,A还在执行B就抢到锁同时执…- 0
- 0
-
我给系统加了 Redis 缓存本以为高枕无忧,大促零点却被缓存集体失效瞬间打垮了数据库,我对着缓存雪崩、击穿、穿透排查了大半天的复盘
第一次扛大促,我提前给核心查询都加了 Redis 缓存,自测命中率很高、DB 压力很小,信心满满以为"有缓存挡着数据库稳如泰山"。零点一过监控就疯狂告警:数据库 CPU 瞬间打满、连接池耗尽、接口大面积超时,缓存命中率从 98% 断崖跌到 30%,DB QPS 几乎垂直拉到 18000+。排查大半天才把三个名字相近、根却不同的缓存失效问题彻底搞明白:雪崩(我给所有 key 设了…- 0
- 0
-
我用 Redis 加了分布式锁防并发,结果偶尔还是有两个节点同时拿到锁、把临界区并发执行了,我对着这把"形同虚设"的锁排查了大半天的复盘
我用 Redis 的 SETNX 加锁、设过期时间防死锁、用完 DEL 释放,实现了分布式锁防并发,结果临界区偶尔还是被两个节点同时执行、锁形同虚设,还极其偶发难复现。把时序画出来才懂两个致命问题:① 业务执行时间超过了锁的过期时间,锁自动到期释放、另一个节点趁机拿到锁,于是两节点同时持锁;② 释放锁直接 DEL 没校验"是不是自己的锁",A 超时后 B 拿到锁,A 执行完却把…- 0
- 0
-
我给热点数据加了缓存提速,结果用户改完资料刷新还是看到旧的、甚至并发改一下缓存就和数据库长期对不上,我对着这个缓存一致性问题排查了大半天的复盘
我给热点数据加了 Redis 缓存提速,结果用户改完资料、提示保存成功了,刷新还是旧数据;并发下偶尔缓存和数据库长期对不上、怎么刷都不对,只能手动清缓存。我加了"更新数据库后也更新缓存"反而更乱。把并发读写画在时间轴上才懂:缓存和数据库是两个独立系统、更新无法原子完成,中间总有不一致窗口,并发下交错就出问题;而我犯的典型错误是选了"更新缓存"而非"…- 0
- 0
-
我给热点数据加了缓存,本以为能稳稳扛住流量、高枕无忧,结果缓存一过期,成千上万的请求在那一瞬间全砸到了数据库、把它直接压垮的深度复盘
我给热点数据加了 Redis 缓存,数据库压力一下就下来了,很满意。可某天高峰,数据库突然被打挂。不是有缓存挡着吗?盯监控复盘才发现:数据库挂掉恰好在那个热点缓存"过期"的一瞬间——这是经典的缓存击穿。热点 key 过期那一刻缓存突然没了,而此时正有上万并发在访问它,它们同时未命中、同时涌向数据库,瞬间把库压垮;第一个请求还没回填好,后续继续砸库,恶性循环。我只享受了缓存命中时…- 0
- 0
-
整点一到,数据库 CPU 瞬间飙满、全站雪崩:我给所有缓存设了同一个过期时间,亲手制造的那场每小时定时引爆的缓存雪崩事故复盘
服务每到整点,数据库 CPU 就从十几瞬间飙到 100%、全站卡顿,过一两分钟又自愈。盯了好几个整点才发现:每次飙升瞬间数据库查询量暴增几十倍——缓存集体失效了。根因是我预热缓存时给上万条数据设了完全相同的 3600 秒过期时间,它们在同一时刻整齐过期,海量请求同时穿透、砸向数据库。这篇从缓存雪崩"同时失效"的本质讲到过期时间加随机的正解、雪崩/击穿/穿透三大坑、多重防御与限流…- 0
- 0
-
缓存集体过期压垮数据库:缓存雪崩避坑复盘
那是一次教科书级别的雪崩:某个流量高峰的午间我们的服务突然开始大面积超时,告警短信像下雨一样砸进群里。我冲上去一看监控触目惊心——数据库 CPU 瞬间飙到 100%,慢查询日志疯狂刷屏,大量请求堆积超时,紧接着因为请求都卡在数据库上线程被占满,整个服务也跟着雪崩式瘫痪了。最诡异的是出事前流量并没有暴涨,就是平平常常的午高峰,怎么会在某一个瞬间突然就被打垮?排查结果是一个我们完全没意识到的定时炸弹:…- 0
- 0
-
缓存集体过期压垮数据库:雪崩击穿穿透避坑
一次让我记忆犹新的线上雪崩:服务前面挡着一层 Redis 缓存,绝大多数读请求都打在缓存上,数据库平时悠闲得很。某天上午十点整监控突然炸了,数据库 CPU 瞬间飙到 100%、响应从几毫秒蹦到几秒、大量请求超时、整个服务几乎瘫痪,可流量并没暴涨多少,就是平日水平。盯着曲线复盘才发现一个关键巧合:故障爆发的十点整,正是前一天凌晨批量预热缓存的那批数据集体到期的时刻——那批缓存头天同一时间一次性灌进 …- 0
- 0
-
大促后对账发现重复扣款:一篇讲透接口幂等性设计
大促结束后的第二天上午,财务一条"对账对不平、几十个用户被重复扣款"的消息把我从复盘的轻松里一把拽出来,更夸张的是有人同一笔订单在库里躺着三四条记录。复盘下来真相平淡得后背发凉:流量冲顶时下单接口变慢,用户疯狂连点,客户端和网关又都配了超时重试,同一个请求被结结实实送进后端好几遍——而整个下单链路没有任何一处做了幂等保护。这篇文章从那次重复扣款事故出发,把接口幂等设计从头讲透:…- 8
- 0
-
缓存三连击实战:穿透、击穿、雪崩,一个热点 key 如何打挂数据库
那次大促,数据库 CPU 垂直拉到 100%、接口大面积超时、上游服务跟着雪崩,我们第一反应是扩容却根本来不及。复盘才发现根因小得哭笑不得:一个被几万人盯着的热点商品缓存恰好在那一刻过期了——几万并发瞬间穿过缓存把同一条查询砸了几万次,这就是缓存击穿。这篇从这个一个 key 打挂数据库的事故讲起,把缓存三大杀手穿透、击穿、雪崩怎么区分、各自怎么治讲透:singleflight 与分布式锁防击穿、空…- 4
- 0
-
从 PostgreSQL 12 + MySQL 5.7 + MongoDB 4.4 + Redis 5 + 原生 pg_dump + Navicat 单栈手工运维 → PostgreSQL 17 + Citus 13 + TimescaleDB 2.17 + pgvector 0.8 + Patroni 4 + PgBouncer 1.24 + pgBackRest 2.55 + Atlas + Flyway 11 + Liquibase 4.30 + ClickHouse 25 + DuckDB 1.2 + Redis 7.4 + KeyDB 6.4 + Dragonfly 1.27 + MongoDB 8.0 + MariaDB 11.6 LTS + MySQL 8.4 LTS + CockroachDB 24 + TiDB 8.5 + dbt 1.9 + Airbyte 0.70 + Debezium 3.0 + Materialize 0.130 全栈现代数据库工程化 87 天踩坑录:23 反模式 + 27 修法
27 位 DBA + 后端工程师 87 天把公司核心数据库栈从 PostgreSQL 12 + MySQL 5.7 + MongoDB 4.4 + Redis 5 + 原生 pg_dump + Navicat 单栈手工运维,整体重构到 2026 年 PostgreSQL 17 + Patroni 4 + Citus + TimescaleDB + pgvector + ClickHouse 25 …- 3
- 0
-
从 MySQL 5.7 + MyCat + Redis 5 + Elasticsearch 7 + InfluxDB + Pinecone → Postgres 17 + Citus 13 + Vitess 21 + Valkey 8 + Dragonfly + OpenSearch 3 + ClickHouse 24 + TimescaleDB 2.17 + Iceberg 1.7 + pgvector 0.8 全栈升级 73 天踩坑录:19 反模式 + 19 修法
21 位 DBA + 数据工程师 73 天把公司"交易 / 用户 / 商品 / 订单 / 风控 / 日志"6 套核心数据系统,从 MySQL 5.7 + MyCat + Redis 5 + MongoDB 4 + Elasticsearch 7 + InfluxDB 1.8 + Pinecone 整体迁移到 Postgres 17 + Citus 13 + Vitess 21 …- 0
- 0
-
Redis 7.2 Cluster 12 节点扩容到 24 节点期间 P99 从 2.4ms 飙到 1.8 秒的 3 天复盘:大键 MIGRATE 阻塞 + MOVED redirect 风暴 + 客户端 slot 缓存雪崩三重叠加 + 11 条 Cluster 运维纪律
我们一个 Redis 7.2 Cluster 用户会话存储,12 节点扩容到 24 节点,在线 reshard 4 小时窗口里 P99 从 2.4ms 飙到 1.8 秒,应用层 50% 请求 timeout,47 个业务工单。3 天复盘找到三重根因:user:5000:big_session 单 key 12MB MIGRATE 阻塞主线程 200ms、Lettuce/ioredis MOVED …- 0
- 0
-
Redis 大 key 阻塞主线程导致集群级雪崩的复盘:18 分钟反复切换 + 5 种修法 + 9 条治理纪律
一次高价值用户标签 HGETALL 800MB 大 key 把 Redis 主线程阻塞 4.2 秒,Sentinel 误判反复切换 4 次,18 分钟内集群级雪崩。本文复盘完整排查过程、5 种修法(HSCAN/读 slave/分片/Sentinel 调参/SafeRedis 防护)、9 条治理纪律,以及 Redis 6.0 IO 多线程和持久化 fsync 的真相。- 10
- 0
-
Redis Cluster 与 Sentinel 高可用完全指南:从一次"3 哨兵全在同机房光纤挖断脑裂数据对账两天"看懂为什么 redis-cli cluster create 远远不够
2023 年我们公司业务量翻倍单 Redis 实例 32GB 内存撑不住决定上 Redis Cluster 6 主 6 从 18 个 hash slot 我们以为只是配置一下集群就行三个节点跑 redis-cli cluster create 自动分槽结果上生产第一周连续出 5 次 P1 故障第一种最让我傻眼的是有个开发用 MULTI EXEC 事务跨 slot 操作报错 CROSSSLOT Ke…- 5
- 0
Redis
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×