FWQ
Redis缓存一致性、缓存穿透、缓存击穿及缓存雪崩问题分析
Redis缓存一致性、缓存穿透、缓存击穿及缓存雪崩问题分析 收藏 积累知识,胜过积蓄金银!毕竟在数据库开发的过程中,会遇到各种各样的问题,往往都是一些细节知识点还没有掌握好而导致的,因此基础知识点的积累是很重要的。下面本文《Redis缓存一致性、缓存穿透、缓存击穿及缓存雪崩问题分析》,就带大家讲解一下知识点,若是你对本文感兴趣,或者是想搞懂其中某个知识点,就请你继续往下看吧~ (1)缓存失效一致性问题 一般缓存的使用方式是:先读取缓存,若不存在则从DB中读取,并将结果写入到缓存中;下次数据读取时便可以直接从缓存中获取数据。 数据的修改是直接失效缓存数据,再修改DB内容,避免DB修改成功,但由于网络或者其他问题导致缓存数据没有清理,造成了脏数据。但这样仍然无法避免脏数据的产生,一种并发的场景下:假设业务对数据Key:Hello Value:World有大量的读取和修改请求。线程A向OCS读取Key:Hello,得到Not Found结果,开始向DB请求数据,得到数据Key:Hello Value:World;接下来准备向OCS写入此条数据,但在写入OCS前(网络,CPU都等可能导致A线程处理速度降低)另一B线程请求修改数据Key:Hello Value:OCS,首先执行失效缓存动作(因为B线程并不知道是否有此条数据,因此直接执行失效操作),OCS成功处理了失效请求。转回到A线程继续执行写入OCS,将Key:Hello Value:World写入到缓存中,A线程任务结束;B线程也成功修改了DB数据内容为Key:Hello Value:OCS。为了解决这个问题,OCS扩充了Memcached协议(公有云即将支持),增加了deleteAndIncVersion接口。此接口并不会真的删除数据,而是给数据打了标签,表明已失效状态,并且增加数据版本号;如果数据不存在则写入NULL,同时也生成随机数据版本号。OCS写入支持原子对比版本号:假设传入的版本号与OCS保存的数据版本号一致或者原数据不存在,则准许写入,否则拒绝修改。 回到刚才的场景上:线程A向OCS读取Key:Hello,得到Not Found结果,开始向DB请求数据,得到数据Key:Hello Value:World;接下来准备向OCS写入此条数据,版本号信息默认为1;在A写入OCS前另一个B线程发起了动作修改数据Key:Hello Value:OCS,首先执行删除缓存动作,OCS顺利处理了deleteAndIncVersion请求,生成了随机版本号12345(约定大于1000)。转回到A线程继续执行写入OCS,请求将Key:Hello Value:World写入,此时缓存系统发现传入的版本号信息不匹配(1 != 12345),写入失败,A线程任务结束;B线程也成功修改了DB数据内容为Key:Hello Value:OCS。 此时OCS中的数据为Key:Hello Value:NULL Version:12345;DB中的数据为Key:Hello Value:OCS,后续读任务时会再次尝试将DB中的数据写入到OCS中。 (2)缓存数据的写同步的与DB一致性问题 随着网站规模增长和可靠性的提升,会面临多IDC的部署,每个IDC都有一套独立的DB和缓存系统,这时缓存一致性又成了突出的问题。 首先缓存系统为了保证高效率,会杜绝磁盘IO,哪怕是写BINLOG;当然缓存系统为了性能可以只同步删除,不同步写入,那么缓存的同步一般会优先于DB同步到达(毕竟缓存系统的效率要高得多),那么就会出现缓存中无数据,DB中是旧数据的场景。此时,有业务请求数据,读取缓存Not Found,从DB读取并加载到缓存中的仍然是旧数据,DB数据同步到达时也只更新了DB,缓存脏数据无法被清除。…