网站中英文要怎么做,sae wordpress 图片,青岛北方现货交易平台,互联网大厂设计哪家口碑好熟练掌握Redis缓存技术#xff1f;
那么请问Redis缓存中有几种读写策略#xff0c;又是如何保证与数据库的一致性问题 今天来聊一聊常用的三种缓存读写策略
Cache Aside Pattern
Cache Aside Pattern 是我们平时使用比较多的一个缓存读写模式#xff0c;比较适合读请求比…熟练掌握Redis缓存技术
那么请问Redis缓存中有几种读写策略又是如何保证与数据库的一致性问题 今天来聊一聊常用的三种缓存读写策略
Cache Aside Pattern
Cache Aside Pattern 是我们平时使用比较多的一个缓存读写模式比较适合读请求比较多的场景服务端需要同时维系 db 和 cache并且是以 db 的结果为准 那么服务端到底是先更新db还是先更新cache
1.先更新数据库
读 查询缓存缓存中查询到了直接返回查询不到时查询数据库查询完数据库后将数据更新至缓存
写 修改数据库 删除缓存 那么能不能先删除缓存再更新数据库呢
答案是 不能这样会导致数据的不一致性
当请求A 发起写请求此时删除缓存同时请求B发起读请求由于没有缓存查询数据库随后请求A更新数据库 通常情况下查询数据库的速度比修改数据库更快。这是因为查询操作通常只涉及对数据库中的数据进行读取和匹配并且可以使用合适的索引来加速查询过程。相比之下修改操作需要对数据库中的数据进行写入和更新可能还需要触发额外的数据库约束、触发器或日志记录等操作这些都会增加一定的开销和时间。 那么是不是先更新数据库再删除缓存是不是就没有数据不一致的情况呢
答案是 并不是
当请求A发起读请求恰巧此时缓存过期需要查询数据库此时请求B发起写请求由于没有缓存故不会执行删除缓存操作请求A查询完数据库将数据写入缓存请求B随后更新数据库
但因为要同时达成读缓存时缓存失效并且有并发写的操作而操作缓存比操作数据库要快得多所以概率要小很多
那么如何解决这种情况呢
更新完数据后的时候同时更新缓存并且我们需要加一个锁/分布式锁来保证更新 cache 的时候不存在线程安全问题确保数据库和缓存的强一致问题 2.先更新缓存
读 查询缓存缓存中查询到了直接返回查询不到时查询数据库查询完数据库后将数据更新至缓存
写
先更新缓存再更新数据库
首先如果缓存更新成功但数据库更新失败会导致数据不一致的问题
其次当请求A发起写请求先更新缓存于此同时请求B发起读请求返回数据后数据库被更新照成了数据不一致的情况
这种概率大吗
大因为redis操作比数据库操作快的多很容易发生
redis为什么那么快 第一Redis 的大部分操作在内存上完成内存操作本身就特别快 第二Redis追求极致选择了很多高效的数据结构并做了非常多的优化比如 hash跳表有时候一种对象底层有几种实现以应对不同场景。 第三Redis 采用了多路复用机制使其在网络 IO 操作中能并发处理大量的客户端请求IO 多路复用机制是指一个线程处理多个 IO 流就是我们经常听到的 select/epoll 机制。简单来说在 Redis 只运行单线程的情况下该机制允许内核中同时存在多个监听 Socket 和已连接 Socket。内核会一直监听这些 Socket 上的连接请求或数据请求。一旦有请求到达就会交给 Redis 线程处理这就实现了一个 Redis 线程处理多个 IO 流的效果。 而我们的Cache Aside Pattern采用的就是第一种情况先更新数据库比较适合读请求比较多的场景
那么对于首次请求一定不存在cache的情况如何解决呢
可以设置定时任务将热点数据提前放入 cache 中 Read/Write Through
原理Read/Write Through原理是把更新数据库的操作由缓存代理cache 服务负责将此数据读取和写入 db从而减轻了应用程序的职责。Read Through如果命中缓存则直接返回数据如果没有命中则查询数据库随后写入到缓存中并返回Write Through当有数据更新的时候如果没有命中缓存直接更新数据库然后返回。如果命中了缓存则更新缓存然后再由缓存自己更新数据库这是一个同步操作。 Write Behind
原理在更新数据的时候只更新缓存不更新数据库而缓存会异步地批量更新数据库。这个设计的好处就是让数据的I/O操作非常快带来的问题是数据不是强一致性的而且可能会丢。 对比Read/Write Through 是同步更新 cache 和 db而 Write Behind 则是只更新缓存不直接更新 db而是改为异步批量的方式来更新 db
非常适合一些数据经常变化又对数据一致性要求没那么高的场景比如浏览量、点赞量
