-
用户明明改了资料、刷新却还是旧的,排查发现是我更新数据库后顺手更新缓存在高并发下把旧值写回了缓存:一次缓存与数据库双写一致性、Cache-Aside 该删缓存而非更新缓存的深度复盘
我们的用户资料服务为扛读量加了 Redis 缓存,读走缓存未命中查库回填,写用我自以为周到的先更新数据库再顺手更新缓存。功能测着没问题,线上却偶发:用户改了资料、缓存却长期是旧值,刷不新直到过期才好。在并发场景下推演才看明白:更新库和更新缓存两步非原子,两个并发写请求 A、B 都先更库再更缓存,DB 最终是 B 的新值(对),但更新缓存时因线程调度 B 先写、A 后写,缓存被覆盖回 A 的旧值——…- 0
- 0
-
一个先更新数据库再删缓存的常规缓存写法,在一次并发读写恰好交错时,把旧数据又写回了缓存、脏了好久:一次缓存一致性的深度复盘
用 cache-aside(先更新数据库再删缓存)缓存商品,偶尔出现 DB 是新价、缓存却一直是旧价。根因是读写并发交错:缓存刚过期时读请求查 DB 读到旧值、还没回填,此时写请求更新 DB 并删缓存,然后读请求慢一步把旧值写回缓存、盖过了写的删除,缓存就脏到下次过期。本文讲透缓存和 DB 是两个独立存储、双写非原子、任何纯双写都有交错会不一致,给出 cache-aside+TTL 兜底(最关键)…- 0
- 0
-
我给热点数据加了缓存提速,结果用户改完资料刷新还是看到旧的、甚至并发改一下缓存就和数据库长期对不上,我对着这个缓存一致性问题排查了大半天的复盘
我给热点数据加了 Redis 缓存提速,结果用户改完资料、提示保存成功了,刷新还是旧数据;并发下偶尔缓存和数据库长期对不上、怎么刷都不对,只能手动清缓存。我加了"更新数据库后也更新缓存"反而更乱。把并发读写画在时间轴上才懂:缓存和数据库是两个独立系统、更新无法原子完成,中间总有不一致窗口,并发下交错就出问题;而我犯的典型错误是选了"更新缓存"而非"…- 0
- 0
-
缓存一致性完全指南:从一次"运营改了价格用户还看到旧的"看懂为什么顺手更新缓存会出大问题
2023 年我做一个电商的商品详情页用户访问展示商品的名称价格库存详情页访问量很大我自然想到加缓存在数据库前面挡一层 Redis 第一版方案我做得很顺手读商品时先查 Redis 命中就直接返回没命中就查数据库把结果写进 Redis 再返回写商品时更新数据库再顺手把 Redis 里那条也更新成新值本地一测读得飞快改了价格刷新页面也是新的我心里很笃定缓存就是数据库的一个副本数据库改了顺手把缓存也改一下…- 3
- 0
Cache-Aside
幸运之星正在降临...
点击领取今天的签到奖励!
恭喜!您今天获得了{{mission.data.mission.credit}}积分
我的优惠劵
-
¥优惠劵使用时效:无法使用使用时效:
之前
使用时效:永久有效优惠劵ID:×
没有优惠劵可用!




