标签:缓存 过期 数据库 redis 缓存数据 一致性 数据
缓存和数据库一致性
-
双写模式:写数据库后,写缓存
- 问题:并发时,2写进入,写完DB后都写缓存。有暂时的脏数据
- 问题:并发时,2写进入,写完DB后都写缓存。有暂时的脏数据
-
失效模式:写完数据库后,删缓存
-
问题:还没存入数据库呢,线程2又读到旧的DB了
- 解决:缓存设置过期时间,定期更新
- 解决:写数据写时,加分布式的读写锁。
缓存数据一致性-解决方案:
- 如果是用户纬度数据(订单数据、用户数据),这种并发几率非常小,不用考虑这个问题,缓存数据加上过期时间,每隔一段时间触发读的主动更新即可
- 如果是菜单,商品介绍等基础数据,也可以去使用canal订阅binlog的方式
- 缓存数据+过期时间也足够解决大部分业务对于缓存的要求。
- 通过加锁保证并发读写,写写的时候按顺序排好队。读读无所谓。所以适合使用读写锁。(业务不关心脏数据,允许临时脏数据可忽略);
总结:
- 我们能放入缓存的数据本就不应该是实时性、一致性要求超高的。所以缓存数据的时候加上过期时间,保证每天拿到当前最新数据即可。
- 我们不应该过度设计,增加系统的复杂性
- 遇到实时性、一致性要求高的数据,就应该查数据库,即使慢点。
标签:缓存,过期,数据库,redis,缓存数据,一致性,数据 来源: https://blog.csdn.net/m0_49708378/article/details/121044108
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。