关于缓存一致性问题，不知道我这个方案是否可行
89 / 6 / 创建于 7个月前 /
xing393939 的个人博客
数据库和缓存的数据一致性问题是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"的值）
这样有什么问题吗？
本作品采用《CC 协议》，转载必须注明作者和本文链接
关于 LearnKu
粤公网安备 44030502004330号
你提出的缓存策略看起来基本上是一种常见的缓存实现方式，但仍然存在一些潜在的问题和改进的空间，让我们逐个讨论：
并发问题：在高并发情况下，多个线程或进程可能同时触发 cacheMiss，导致多次生成相同的 leaseId。这可能会导致多个线程同时访问数据库并尝试更新缓存，浪费资源并增加数据库负载。你可以考虑使用分布式锁来确保只有一个线程生成 leaseId 和更新缓存。
缓存和数据库不一致：在更新数据库后删除缓存和 leaseId 的操作之间，可能会出现故障或异常情况，导致缓存和数据库不一致。为了解决这个问题，你可以使用事务来确保数据库和缓存的操作是原子的，要么都成功，要么都失败。
leaseId 过期问题：如果 leaseId 的过期时间设置得太短，可能导致缓存过早失效，增加了数据库访问的频率。你需要根据你的应用场景和数据更新频率来调整 leaseId 的过期时间，以达到合理的性能和一致性权衡。
性能和资源消耗：频繁地生成和删除 leaseId 可能会增加 Redis 的负担，特别是在高并发环境下。你可以考虑使用 Redis 的 Lua 脚本来原子地生成和删除 leaseId，以减少资源消耗。
数据库查询效率：每次 cacheMiss 都会触发一次数据库查询，这可能会导致数据库负载过大。你可以考虑添加缓存失效后的短暂等待时间，以允许多个请求合并为一次数据库查询，减轻数据库压力。
异常处理：你需要考虑如何处理数据库查询失败、缓存写入失败等异常情况，以确保系统的健壮性和可靠性。
总之，你的缓存策略基本上是可行的，但需要考虑并发性、一致性、性能和异常处理等方面的问题。根据具体的应用场景和性能需求，可能需要进一步优化
其实常规的缓存策略已经满足了，无非就是并发锁的问题，缓存失效就去获取锁，谁获取到谁就更新，没获取锁的就尝试获取缓存，获取到就是最新的缓存，所以核心还是并发锁的问题~