缓存一致性

锁的粒度

锁的粒度越小 对业务影响的越小

双写模式

写数据库是一并将缓存进行更新
但在高并发下会出现一点问题 这里有两个请求 首先请求一进去了 将数据修改完毕 因为一些原因卡住了 这时候请求二进入 将数据修改哭数据修改完毕顺便将缓存修改完了 这时候请求一才将缓存修改完毕 这时候缓存中的数据和数据库中的数据不一致
脏数据的解决办法:
若缓存中的数据可以接受暂时不一致的话 可以添加一个过期时间 当缓存过期了 再次从数据库中拿到最新数据
可以上锁 只有在写数据库写缓存这一对操作完成时才能执行下一对
image

失效模式

写数据库后顺便将缓存中的数据删除 当进行访问时 会从数据库找到数据并保存到缓存中
首先有三个请求 请求一写数据库 删缓存执行完毕 请求二写数据库执行有点慢 这时候请求三进入 这时候因为请求二还未修改完成 所以读取到的是请求一的旧数据 然后执行更新缓存操作 得到的是旧数据 如果在请求二删缓存之前完成更新的话那还好 之后删缓存 请求数据还是最新数据 如果在删缓存之后 请求数据的 话 那还是脏数据
image
解决方法:
还是可以加锁来完成 写数据库和删缓存完成之后才能放行下一个请求

总结

数据一致性要求高和频繁进行修改的数据就不应该添加到缓存中
我们项目使用的方案: 失效模式 为了避免乱序 添加分布式读写锁

posted @   RainbowMagic  阅读(56)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
点击右上角即可分享
微信分享提示