程序员的成长之路
互联网/程序员/技术/资料共享
关注
阅读本文大概需要 3 分钟。
来自:https://thinkinjava.cn
通常,我们会使用缓存用于缓冲对 DB 的冲击,如果缓存宕机,所有请求将直接打在 DB,造成 DB 宕机——从而导致整个系统宕机。
2 种策略(同时使用):
对缓存做高可用,防止缓存宕机
使用断路器,如果缓存宕机,为了防止系统全部宕机,限制部分流量进入 DB,保证部分可用,其余的请求返回断路器的默认值。
解释 1:缓存查询一个没有的 key,同时数据库也没有,如果黑客大量的使用这种方式,那么就会导致 DB 宕机。
解决方案:我们可以使用一个默认值来防止,例如,当访问一个不存在的 key,然后再去访问数据库,还是没有,那么就在缓存里放一个占位符,下次来的时候,检查这个占位符,如果发生时占位符,就不去数据库查询了,防止 DB 宕机。
解释 2:大量请求查询一个刚刚失效的 key,导致 DB 压力倍增,可能导致宕机,但实际上,查询的都是相同的数据。
解决方案:可以在这些请求代码加上双重检查锁。但是那个阶段的请求会变慢。不过总比 DB 宕机好。
解释:多个客户端写一个 key,如果顺序错了,数据就不对了。但是顺序我们无法控制。
解决方案:使用分布式锁,例如 zk,同时加入数据的时间戳。同一时刻,只有抢到锁的客户端才能写入,同时,写入时,比较当前数据的时间戳和缓存中数据的时间戳。
解释:连续写数据库和缓存,但是操作期间,出现并发了,数据不一致了。
通常,更新缓存和数据库有以下几种顺序:
先更新数据库,再更新缓存。
先删缓存,再更新数据库。
先更新数据库,再删除缓存。
三种方式的优劣来看一下:
先更新数据库,再更新缓存。
这么做的问题是:当有 2 个请求同时更新数据,那么如果不使用分布式锁,将无法控制最后缓存的值到底是多少。也就是并发写的时候有问题。
先删缓存,再更新数据库。
这么做的问题:如果在删除缓存后,有客户端读数据,将可能读到旧数据,并有可能设置到缓存中,导致缓存中的数据一直是老数据。
有 2 种解决方案:
使用“双删”,即删更删,最后一步的删除作为异步操作,就是防止有客户端读取的时候设置了旧值。
使用队列,当这个 key 不存在时,将其放入队列,串行执行,必须等到更新数据库完毕才能读取数据。
总的来讲,比较麻烦。
先更新数据库,再删除缓存
这个实际是常用的方案,但是有很多人不知道,这里介绍一下,这个叫 Cache Aside Pattern,老外发明的。如果先更新数据库,再删除缓存,那么就会出现更新数据库之前有瞬间数据不是很及时。
同时,如果在更新之前,缓存刚好失效了,读客户端有可能读到旧值,然后在写客户端删除结束后再次设置了旧值,非常巧合的情况。
有 2 个前提条件:缓存在写之前的时候失效,同时,在写客户度删除操作结束后,放置旧数据 —— 也就是读比写慢。设置有的写操作还会锁表。
所以,这个很难出现,但是如果出现了怎么办?使用双删!!!记录更新期间有没有客户端读数据库,如果有,在更新完数据库之后,执行延迟删除。
还有一种可能,如果执行更新数据库,准备执行删除缓存时,服务挂了,执行删除失败怎么办???
这就坑了!!!不过可以通过订阅数据库的 binlog 来删除。
https://coolshell.cn/articles/17416.html
https://www.cnblogs.com/rjzheng/p/9041659.html
https://docs.microsoft.com/en-us/azure/architecture/patterns/cache-aside
本文以收录在GitHub:https://github.com/gdjkmax/JavaBible/blob/master/%E9%9D%A2%E8%AF%95%E9%A2%98/100%20%E6%9C%9F%20Java%20%E9%9D%A2%E8%AF%95%E9%A2%98%E6%B1%87%E6%80%BB.md
点击原文链接可直达!
推荐阅读:
这 3 个学数据结构和算法的网站,相信你也会喜欢的!
项目实践:Spring Boot 三招组合拳,手把手教你打出优雅的后端接口
5T技术资源大放送!包括但不限于:C/C++,Linux,Python,Java,PHP,人工智能,单片机,树莓派,等等。在公众号内回复「2048」,即可免费获取!!
微信扫描二维码,关注我的公众号
写留言
朕已阅