龙岗爱联有学网站建设,给我免费观看片在线,外包公司排名,广告做网站缓存常用的读写策略
缓存与DB的数据不一致问题#xff0c;大多数都是指DB的数据已经修改#xff0c;而缓存中的数据还是旧数据的情况。
旁路缓存模式
对于读操作#xff1a;基本上所有模式都是先尝试从缓存中读#xff0c;没有的话再去DB读取#xff0c;然后写到缓存中…缓存常用的读写策略
缓存与DB的数据不一致问题大多数都是指DB的数据已经修改而缓存中的数据还是旧数据的情况。
旁路缓存模式
对于读操作基本上所有模式都是先尝试从缓存中读没有的话再去DB读取然后写到缓存中 对于写操作先更新数据再删除旧缓存 为什么先修改数据库而不是先删除缓存 如果是先删除缓存的话很容易引起数据不一致的问题。
比如写操作的过程中来了个读操作。在删除完缓存但数据库没有修改完的期间来了个读请求它就会把没有修改的数据进行缓存后续再更新数据库之后数据库的内容和缓存的内容就不一致了。
同样地读取操作的过程中DB读完了但没有写入缓存中来了个写请求把DB数据改了那么最终写入的缓存将会是旧的数据因为DB已经被更新了。只不过这次情况概率小因为写入缓存的速度特别快期间DB的数据很难被修改完成 为什么修改数据库后要删除缓存不能修改完数据库后直接修改缓存吗 不能在高并发场景下同时处理多个写请求如果某个写请求中间完成了另外一个写请求那么最后更新的缓存就会是旧的数据。但如果是先更新数据库再删除缓存的话就不用考虑这么多了因为下次访问会重新加载最新数据。 这种模式会有一致性问题吗举个例子 也会有的但是概率比较小具体如下
第一种情况写操作的过程中来了读请求。更新完DB但缓存没有删掉的期间如果来了一个读请求此时会命中缓存读取到的是缓存中的旧数据但是这个缓存马上会被删掉影响几乎可以忽略不计。第二章情况读操作的过程中来了个写请求。请求1读取了DB的值准备写入缓存但还没有写入此时如果来了个写请求将DB的数据修改了那么之前读请求写入的缓存就是过期的缓存了。不过这种情况概率也比较小因为写缓存的速度非常快写缓存的期间数据被修改不太可能除非高并发场景。
解决方案使用分布式锁保证更新DB和删除缓存的操作同步进行不会受其它线程影响。
特点
实现简单能保证最终一致性所有数据的首次读取都要经过DB之后才能命中缓存可以将热点数据可以提前放入 cache 中写操作比较频繁的话导致 cache 中的数据会被频繁被删除会影响缓存命中率
适用场景读多写少大多数场景、不需要保证和数据库的强一致性
注意根据CAP理论如果需要数据库和缓存数据保持强一致就不适合使用缓存换句话说用用缓存的本质就是牺牲一致性去换速度。
读写穿透模式
旁路缓存模式是由用户去分别控制cache和DB的读写而读写穿透是由cache服务去直接完成对DB的读写这样减轻了程序员的职责但是Redis没有提供直接将缓存数据写入DB的功能所以比较少见。
对于读操作也是先去缓存中找然后再去DB中找唯一不同的就是从DB找的过程是由cache程序自动进行的。
对于写操作在更新DB的同时也更新cache本身而不是删除这个步骤是由缓存服务去实现的。
适用场景需要保证数据的强一致性
缺点
使用要求高要求缓存程序对自身修改时能同步对DB进行更新Redis就不支持
异步写入模式写后模式
也是由 cache 服务来负责 db 的读写更新数据时先更新缓存中的数据然后过一段时间再异步批量去更新db常用在实时变化且又是非核心的数据中比如点赞量、阅读量等等。
适用场景对响应速度要求很高但对一致性要求不高
缺点如果写入DB前缓存挂了数据就会丢失
