温馨提示:文本由机器自动转译,部分词句存在误差,以视频为准
00:00
好,各位同学。落到这,这章也已经接近了尾声,那么老规矩,从理论到案例,小总结拿下。最终要给同学们出一张结论性的总图,来帮助大家进行总结,来吧,缓存的问题呢,有更新不一致。穿透、击穿雪崩,预热等等啊,有的没的,收集到的笔面试题,案例方案都给同学们针对性的。讲解了一下,介绍了一下,不一定完全适合你,请同学们在生产上,在开发当中酌情参考,那么对于我们的更新方式啊,数据变更,缓存时效性啊,同步更新失效了以后,收到人工报账了,你再去更新,异步更新加上MQ定时更新,叉叉l job扫着每一段时间自己更新一次,同步更新那么开OK,那么这个呢,过第二个缓存不一致。
01:00
那么假设我们开到是吧,同步或者异步更新失败了,那么只能是什么增加重试补偿任务打最终要保证最终一致性对吧,甚至有时候一边一边有了,一边没有,干脆删掉一边再来一次,所以说只能是这个重试的话,可能是需要重试两次甚至是三次,为什么?也许my write还有一个东西叫什么不能过滤器啊,那么我们最后的目的就要达到最终一致性。过那么穿透主要是恶意攻击是吧,那么根本就不存在,也不存在MYSQ的不停的换着这个key,这个ID来打你,那么我们用的方法空对象缓存或者是不能过滤器,那么对于不能过滤器,我们手写了一个自研版的,也用了一个谷歌开源的瓜网自带的不能过滤器,那么这块请同学们可以这么讲啊,以后啊那些。过滤器啊,都可以不用自己手写了,用谷歌的这个是非常爽的啊,反正你就白名单黑名单。
02:04
弄上去合法的用波动过滤器过滤一下,再跑到red,跑到后台MYSQL去运作过第四个缓存机串,那么热点key的失效刚刚讲过了,好,我呢就不再啰嗦了,那么最后雪崩是吧?如整个right没了,缓存挂掉了是吧?刷用为祭天OK,那么快速失败熔断主存模式啊,集群等等尽量防止呢,不要整个RA1蛋机一倒倒一片,那么最后预先加载预热是吧?我们提前做一下储备,保证red so和MYSQL数据一样。不要把这个预热的工作留给客户,尽量头天晚上部署的时候有运维自己点,或者是刨一下我们的。点击斯瓦哥的这些脚本都访问一次,给这个系统提前加载,好OK,好,我们各位同学对于这我们的缓存预热雪崩击穿穿透就给大家呢总结讲解到这儿,那么接下来我们进入新的篇章。
我来说两句