Redis维护缓存的方案选择

Redis中间件常常被用作缓存,而当使用了缓存的时候,缓存中数据的维护,往往是需要重点关注的,尤其是重点考虑的是数据一致性问题。以下是维护数据库缓存的一些常用方案。

1、先删除缓存,再更新数据库

导致数据不一致的场景:

最终结果:数据库存储的是新值,缓存存储的是旧值,导致数据不一致

2、先更新数据库,再删除缓存

最终结果:A线程删除缓存失败,导致缓存中一直存的是旧值。但是实际上,删除缓存失败这个异常场景不在此范围讨论中(可以加入重试机制),因此,此方案数据一致性问题不大,但是可能导致穿透问题(缓存数据删除后,瞬间大量请求穿过缓存,直接打到数据库。但是,但凡是删除缓存都有可能导致穿透问题)

3、先更新数据库,然后更新缓存

最终结果:更新缓存的时间不确定,有先有后,可能导致旧值覆盖新值的问题。而且性能不好,一万次请求就得更新一万次缓存。

4、延时双删

在方案一的基础上,增加了一次删除缓存的操作。回想方案一,导致数据不一致的问题是,A线程在B线程之后更新完数据库后,没有去处理缓存数据。因此,在更新完数据库后,再删除一次缓存便可(本质上就是方案一与方案二的结合)

总体流程:先删除缓存,然后再更新数据库,更新完数据库后,延时再删除一次缓存,做兜底操作。

更新数据库前删一次缓存,是因为,防止在更新数据库后的瞬间,有人直接命中缓存,拿到旧数据

更新数据库后再删一次缓存,是因为,有人通过查库拿到旧数据,设置值进了缓存(方案一数据不一致的情况),之所以要延时,是因为要保证,第二次删除的时机要在其他人写数据之后,否则白删。

注意:既然是删除缓存数据,依然会导致缓存穿透的问题。

根据实际业务场景,我选择了方案三:先更新数据库,再更新缓存。原因如下:

1、修改缓存的入口只有一个,在控制台中设置,不存在多个线程修改缓存的情况

2、读的入口有多个,有许多定时器会在自己的业务中读缓存值,有并发且量十分大,因此,需要考虑缓存穿透问题(不能删除缓存)

3、缓存中存的实际是业务配置,读多写少,大量更新操作导致性能消耗的场景不存在

每一种方案都存在他的优缺点。在理想中,我们往往希望能适用所有场景的方案,但是,现实往往很骨感,一劳永逸的方法几乎只存在于某个乌托邦。方案没有好坏之分,只有是否适合自己的应用场景之别。

相关推荐
庸人自扰611 小时前
Redis从零讲解
数据库·redis·缓存
lypzcgf2 小时前
Coze源码分析-资源库-删除数据库-后端源码-领域服务/数据访问层
数据库·go·coze·coze源码分析·智能体平台·ai应用平台·agent平台
cqsztech2 小时前
oracle linux 10 +pg18 源码安装要点
linux·数据库·oracle
健康平安的活着2 小时前
spring事务传播级别的实操案例2
数据库
安审若无2 小时前
Oracle 闪回过期后的解决方法
数据库·oracle
Navicat中国2 小时前
Navicat 技术指引 | KingbaseES 逆向工程与正向工程
数据库·database·navicat·建模·金仓·kingbasees
奥尔特星云大使3 小时前
ALTER 与 UPDATE、DROP 与 DELETE区别
linux·运维·数据库·mysql
六月闻君3 小时前
MySQLdump 常用参数说明
数据库·mysql
扫地的小何尚3 小时前
NVIDIA Dynamo深度解析:如何优雅地解决LLM推理中的KV缓存瓶颈
开发语言·人工智能·深度学习·机器学习·缓存·llm·nvidia
野犬寒鸦3 小时前
多级缓存架构:性能与数据一致性的平衡处理(原理及优势详解+项目实战)
java·服务器·redis·后端·缓存