V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
xing393939
V2EX  ›  Redis

关于缓存一致性问题,不知道我这个方案是否可行

  •  
  •   xing393939 ·
    xing393939 · 220 天前 · 1540 次点击
    这是一个创建于 220 天前的主题,其中的信息可能已经有所发展或是发生改变。

    数据库和缓存的数据一致性问题是 Web 开发中经常碰到的,一般我们都是采用 cache aside 方案,比如这篇文章介绍的。最近参考Scaling Memcache at Facebook,我想到了一个基于 redis 的简化版本,不知是否可行,希望大家帮忙参考下:

    1. cacheMiss 时,生成一个对应 cacheKey 的 leaseId ( redis 生成一个值:key 是cacheKey + "_id",value 是随机数,expireTime=10 秒,若 key 已存在则失败),若生成 leaseId 失败则等待并重试。
    2. cacheMiss 后,先查 db 再更新缓存,但更新缓存的时候,需要检查 leaseId 是否有效( redis 是否存在 key=cacheKey + "_id"、value=leaseId 的值)
    3. 每次更新 db 后,删除缓存,同时删除 leaseId ( redis 删除 key=cacheKey + "_id"的值)

    这样有什么问题吗?

    5 条回复    2023-09-21 08:33:18 +08:00
    yule111222
        1
    yule111222  
       220 天前
    cacheMiss 后,先查 db 再更新缓存,这一步追加分布式锁不就行了吗?
    pdxjun
        2
    pdxjun  
       220 天前
    为什么这么麻烦,加一个分布式锁,不就可以了吗
    luckyrayyy
        3
    luckyrayyy  
       220 天前
    miss 的时候生成 key ,不就是一个分布式锁么。更新缓存加分布式锁有热点风险
    javaisthebest
        4
    javaisthebest  
       219 天前
    只要是多机器通信就会牵扯到网络

    只要牵扯到网络就会形成分区。。

    所以放弃你这个想法吧。

    天命不可违

    后续的任何一次操作失败就代表形成了 P 。。
    xing393939
        5
    xing393939  
    OP
       219 天前
    @yule111222 @pdxjun 要求数据强一致的话:加分布式锁,那么所有请求被阻塞的时间是[更新 db+删除缓存+查 db+更新缓存],而我的方案阻塞的时间是[查 db+更新缓存],我这个相当于是乐观锁。


    @luckyrayyy 你说的热点风险具体场景是咋样的呢?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1359 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 39ms · UTC 17:33 · PVG 01:33 · LAX 10:33 · JFK 13:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.