缓存一致性,缓存穿透,缓存击穿,缓存雪崩解决方案分析

(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,缓存脏数据无法被清除。

image.jpeg

从上面的情况可以看出,不一致的根本原因是异构系统之间无法协同同步,不能保证DB数据先同步,缓存数据后同步。所以就要考虑缓存系统如何等待DB同步,或者能否做到两者共用一套同步机制?缓存同步也依赖DB BINLOG是一个可行的方案。

IDC1中的DB,通过BINLOG同步给IDC2中的DB,此事IDC2-DB数据修改也会产生自身的BINLOG,缓存的数据同步就可以通过IDC2-DB BINLOG进行。缓存同步模块分析BINLOG后,失效相应的缓存Key,同步从并行改为串行,保证了先后顺序。

(3)缓存穿透(DB承受了没有必要的查询流量)

方法一:是布隆过滤器。它是一种空间效率极高的概率型算法和数据结构,用于判断一个元素是否在集合中(类似Hashset)。它的核心是一个很长的二进制向量和一系列的hash函数。使用谷歌的guava实现布隆过滤器。1)存在误算率,随着存入的元素数量增加,误算率也随着增加2)一般情况下不能从布隆过滤器删除元素3)数组长度以及hash函数个数确定过程复杂,布隆过滤器的使用场景?1)垃圾邮件地址过滤(地址数量很庞大)2)爬虫URL地址去重3)解决缓存击穿问题

方法二:存储空结果,并设置空结果的时间

(4)缓存雪崩(缓存设置同一过期时间,引起的DB洪峰)

方法一:大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程(进程)写,从而避免失效时大量的并发请求落到底层存储系统上
方法二:失效时间随机值

(5)缓存击穿(热点Key,大量并发读请求引起的小雪崩)

    缓存在某个时间点过期的时候,恰好在这个时间点对这个Key有大量的并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮

方法一:1.使用分布是缓存支持的互斥锁(mutex key),去set一个mutex key,当操作返回成功时,再进行load db的操作并回设缓存,也就是load DB 只会一个线程处理。
方法二:提前"使用互斥锁(mutex key):在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候,马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。增加了业务代码的侵入过多,以及增加了编码复杂性
方法三: "永远不过期": 从redis上看,确实没有设置过期时间,这就保证了,不会出现热点key过期问题,也就是“物理”不过期。从功能上看,如果不过期,那不就成静态的了吗?所以我们把过期时间存在key对应的value里,如果发现要过期了,通过一个后台的异步线程进行缓存的构建,也就是“逻辑”过期

(6)缓存系统常见的缓存满了和数据丢失问题

需要根据具体业务分析,通常我们采用LRU策略处理溢出,Redis的RDB和AOF持久化策略来保证一定情况下的数据安全。

本文参考:

https://www.csdn.net/article/1970-01-01/2825234

https://blog.csdn.net/zeb_perfect/article/details/54135506

推荐阅读更多精彩内容