redis端口号为什么是(redis配置端口与实际端口不一样)

redis端口号为什么是(redis配置端口与实际端口不一样)strong 一 Cache Aside Pattern strong strong 二 缓存与数据库双写不一致 strong strong 1 双写不一致情况 strong strong 2 读写并发不一致 strong strong 三 解决方案 lt strong

大家好,我是讯享网,很高兴认识大家。



<strong>一、Cache Aside Pattern</strong><strong>二、缓存与数据库双写不一致</strong><strong>1、双写不一致情况</strong><strong>2、读写并发不一致</strong><strong>三、解决方案</strong><strong>1、消息队列串行化</strong><strong>2、加分布式锁</strong><strong>3、用阿里开源的canal</strong><strong>总结</strong><p></p> 

讯享网

在了解这个问题之前,我们有必要知道缓存+数据库读写数据的模式,也就是Cache Aside Pattern

(1)读的时候:先读缓存,缓存没有的话,就读数据库,然后取出数据后放入缓存,同时返回响应;

(2)写的时候:先更新数据库,然后再删除缓存。&nbsp;

写的时候模式分析为什么是删除缓存,而不是更新缓存?

①假设我们有10次写,若是更新缓存的话需要更新10次缓存,10次数据库,我们优化为只需要删除一次缓存,更新10次数据库,当有一个读请求过来只是没有命中,去数据库读取一下,这样对性能的影响也不是很大;

②这是 一个 lazy 计算的思想,不要每次都重新做复杂的计算,不管它会不会用到,而是让它到需要被使用的时候再重新计算。像mybatis,hibernate,都有懒加载思想。


讯享网

线程1在写数据库与更新缓存之间卡顿了一下,然后线程2在线程1卡顿的这个空隙去写了数据库并刷新了缓存,然后线程2都已经执行完了,线程1又把脏数据更新到了缓存,造成了数据库与缓存不一致。

先更新写操作的,由于中间网络问题或者什么问题造成更新数据推后,最后造成了脏数据的更新,导致数据库与缓存双写不一致。

(1)对于并发几率很小的数据(如个人维度的订单数据、用户数据等),这种几乎不用考虑这个问题,很少会发生缓存不一致,可以给缓存数据加上过期时间,每隔一段时间触发读的主动更新即可。

(2)就算并发很高,如果业务上能容忍短时间的缓存数据不一致(如商品名称,商品分类菜单等),缓存加上过期时间依然可以解决大部分业务对于缓存的要求。

(1)主要思路:在后台进程中我们可以创建多个队列,然后根据hash算法将写请求路由到不同的队列中,当来读请求的时候,就加入队列中,当写请求处理完毕后,再去处理读请求。

(2)分析:如果对于同一份数据有多个写请求同时在队列中,那么来一个读请求中加入队列中之后,一般写请求耗时比较久,那么读请求会需要很久才能返回,这样会特别影响性能,但能保证一致性(一般情况下建议不要用)

通过加分布式读写锁保证并发读写写写的时候按顺序排好队读读的时候相当于无锁

可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存,但是引入了新的中间件,增加了系统的复杂度

以上为个人经验,希望能给大家一个参考,也希望大家多多支持。

小讯
上一篇 2025-04-20 07:29
下一篇 2025-05-25 15:02

相关推荐

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/151075.html