Redis缓存更新策略
Redis缓存更新策略
本文整理自黑马程序员相关资料
内存淘汰 | 超时剔除 | 主动更新 | |
---|---|---|---|
说明 | 不用自己维护,利用Redis的内存淘汰机制,当内存不足时自动淘汰部分数据。下次查询时更新缓存 | 给缓存数据添加TTL时间,到期后自动删除缓存,下次查询时更新缓存 | 编写业务逻辑,在修改数据的同时,更新缓存 |
一致性 | 差 | 一般 | 好 |
维护成本 | 无 | 低 | 高 |
业务场景需求:
- 在基本不会更新数据的情况下可以使用内存淘汰机制
- 在频繁更新数据的情况下可以使用主动更新,并以超时剔除作为兜底方案。
主动更新的三种方法#
-
Cache Aside Pattern:由缓存的调用者,在更新数据库的同时更新缓存
-
Read/Write Through Pattern:缓存和数据库整合为一个服务,由服务来维护一致性。调用者调用该服务,无需关心缓存一致性问题。
优点:整合的服务保证了数据的一致性
缺点:维护和开放成本高
-
Write Behind Caching Pattern:调用者只操作缓存,由其他线程异步的将缓存数据持久化到数据库,最终保持一致。
优点:异步更新缓存数据,效率高。例如缓存多次更新,但是更新到的缓存并没有被使用,多次将数据持久化到数据库就相当于进行了无用的操作,异步更新相当于将前几次的更新合并为一次更新,因而提高了效率。
缺点:无法保证一致性,维护成本高
目前主流使用的Redis缓存主动更新的方法是Cache Aside Pattern
操作缓存和数据库时需要考虑的三个问题#
-
删除缓存还是更新缓存?
- 更新缓存:每次更新数据库都更新缓存,无效写操作较多
- 删除缓存:更新数据库时让缓存失效,查询时再更新缓存
-
如何保证缓存与数据库的操作的同时成功或者失败
- 对于单体系统:将缓存与数据库操作放在一个事务中
- 对于分布式系统:利用TCC等分布式事务方案
-
先操作缓存还是先操作数据库
- 先删除缓存,再操作数据库
- 先操作数据库,再删除缓存
如上图所示,两种方案在多线程的情况下都会产生数据不一致的问题。但是在先操作数据库再删除缓存的情况下,要发生数据不一致的问题,需要在缓存写入之前完成更新数据库和删除缓存的操作,而写入缓存的耗时非常短。因而发生的概率相对于另一种方案更低。所以选择先操作数据库,再删除缓存。
作者:xuzhuo123
出处:https://www.cnblogs.com/xuzhuo123/p/16377551.html
版权:本作品采用「署名-非商业性使用-相同方式共享 4.0 国际」许可协议进行许可。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 上周热点回顾(2.17-2.23)
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)
· spring官宣接入deepseek,真的太香了~