Redis 二三事之事前预防和事中恢复
事中恢复:
可以先把流量拦截在入口的地方,比如通过 Nginx 的配置把请求都转到一个特别设计的页面,主要是 一些对用户友好的错误展示。
然后把 Redis 重新启动起来。
这样做的目的是为了防止流量过大,直接把新启动的服务,启动一个打挂一个的情况出现。
要是启动起来了,没多久又挂了,那就可以考虑缓存预热
复制代码
在设计服务的时候做到服务无状态,以达到快速扩容(Redis 提供了灵活的节点扩容和收缩方案。在不影响集群对外服务的情况下,可以为集群添加节点进行扩容也可以对下线节点进行缩容)的目的。
事前预防:
我首先想到的是 Redis 崩了,也就是发生了缓存雪崩。
复制代码
在高并发的情况下,除了缓存雪崩,我们还必须得考虑到缓存的击穿、穿透问题。
复制代码
复制代码
复制代码
服务中是不是需要考虑限流、降级和熔断机制,最大程度的保护程序的运行?
复制代码
我们是否应该建立多级缓存的机制,防止 Redis 挂掉之后,大批流量直接打到 MySQL 服务导致数据库的崩盘?
复制代码
多级缓存解决方案
有赞透明多级缓存解决方案(TMC)
相关链接:https://tech.youzan.com/tmc/
著作权归 NoLongerConfused 所有。商业转载请联系 NoLongerConfused 获得授权,非商业转载请注明出处。
版权声明: 本文为 InfoQ 作者【NoLongerConfused】的原创文章。
原文链接:【http://xie.infoq.cn/article/df14e9e8bb258bf4e4bb9614d】。文章转载请联系作者。
评论