这是一个创建于 863 天前的主题，其中的信息可能已经有所发展或是发生改变。
数据库和缓存的数据一致性问题是 Web 开发中经常碰到的，一般我们都是采用 cache aside 方案，比如这篇文章介绍的。最近参考Scaling Memcache at Facebook，我想到了一个基于 redis 的简化版本，不知是否可行，希望大家帮忙参考下：
- cacheMiss 时，生成一个对应 cacheKey 的 leaseId （ redis 生成一个值：key 是
cacheKey + "_id"，value 是随机数，expireTime=10 秒，若 key 已存在则失败），若生成 leaseId 失败则等待并重试。 - cacheMiss 后，先查 db 再更新缓存，但更新缓存的时候，需要检查 leaseId 是否有效（ redis 是否存在 key=
cacheKey + "_id"、value=leaseId 的值） - 每次更新 db 后，删除缓存，同时删除 leaseId （ redis 删除 key=
cacheKey + "_id"的值）
这样有什么问题吗？
 | 1 yule111222 2023 年 9 月 20 日 cacheMiss 后，先查 db 再更新缓存，这一步追加分布式锁不就行了吗？ |
 | 2 pdxjun 2023 年 9 月 20 日 为什么这么麻烦，加一个分布式锁，不就可以了吗 |
 | 3 luckyrayyy 2023 年 9 月 20 日 miss 的时候生成 key ，不就是一个分布式锁么。更新缓存加分布式锁有热点风险 |
 | 4 javaisthebest 2023 年 9 月 21 日 只要是多机器通信就会牵扯到网络 只要牵扯到网络就会形成分区。。 所以放弃你这个想法吧。 天命不可违 后续的任何一次操作失败就代表形成了 P 。。 |
 | 5 xing393939 OP @yule111222 @pdxjun 要求数据强一致的话：加分布式锁，那么所有请求被阻塞的时间是[更新 db+删除缓存+查 db+更新缓存]，而我的方案阻塞的时间是[查 db+更新缓存]，我这个相当于是乐观锁。 @luckyrayyy 你说的热点风险具体场景是咋样的呢？ |
Select Language