缓存穿透、雪崩、热点与Redis

向大家推荐这篇文章——Redis架构之防雪崩设计:网站不宕机背后的兵法

(另外推荐我去年的短文作为餐前点心——略谈服务端缓存设计

《Redis架构之防雪崩设计》这篇文章(下文称之为“原文”)写得非常好,全面概括了大规模系统可能面对的缓存穿透和缓存雪崩等问题,可以看出是一线实战经验的精华总结,非常适合大家学习。

而我想再补充一些信息,使“原文”的版图更加完整。

关于“缓存穿透”

“原文”给出了空对象和布隆过滤器两种解决方案。

空对象是首选方案,简单直接,碰到查询结果为空的键,放一个空值在缓存中,下次再访问就立刻知道这个键无效,不用发出SQL了。但“原文”也说了,存在如下问题:

第一,空值做了缓存,意味着缓存层中存了更多的键,需要更多的内存空间 ( 如果是攻击,问题更严重 ),比较有效的方法是针对这类数据设置一个较短的过期时间,让其自动剔除。

第二,缓存层和存储层的数据会有一段时间窗口的不一致,可能会对业务有一定影响。例如过期时间设置为 5 分钟,如果此时存储层添加了这个数据,那此段时间就会出现缓存层和存储层数据的不一致,此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

对于第一点,我还建议空值放在另外的缓存空间中,不宜与正常值共用空间,否则当空间不足时,缓存系统的LRU算法可能会先剔除正常值,再剔除空值——这个漏洞可能会受到攻击。

对于第二点,如果是Redis缓存,更新数据后直接在Redis中清除即可;如果是本地缓存,就需要用消息来通知其他机器清除各自的本地缓存了。(业界终于接受了用消息来同步缓存的设计思想,cheers! )我有一个小项目joint-cache-redis来简单地演示“用消息来同步多个机器的缓存”,而且在实践中发现Kafka可能比Redis MQ更适合于这个场景。

关于“缓存雪崩”

这句概括很传神!缓存层宕掉后,流量会像奔逃的野牛一样,打向后端存储

没什么要补充的,就感谢一下Netflix开源的Hystrix吧!虽然只是一个库,但是要实现可靠的限流算法还是颇有门道的。

关于“缓存热点 key 重建”

“原文”说到在缓存失效的瞬间,有大量线程来重建缓存,造成后端负载加大,甚至可能会让应用崩溃,并给出“互斥锁”和“永远不过期”两种候选方案。

互斥锁(Mutex):

“分布式缓存加锁”通常是一个反模式(见我去年的文章大型服务端开发的反模式第7条),如果持有锁的实例不稳定导致没及时释放,就会浪费这个锁,直到锁过期。“原文”的作者还指出有死锁的风险。

其实是可以优化的:等待一两次后,重试时可绕过互斥锁。即使绕过互斥锁,也不会产生什么不好的后果,因为更新缓存是一个幂等操作。

也可以把锁的过期时间设得更短。

从这个例子我们能感觉到,幂等操作比非幂等操作更容易优化。

永远不过期:

“原文”很好地介绍了在Redis中的做法。对于Guava本地缓存就简单多了,使用refreshAfterWrite即可。

“原文”读到最后,才知道这是《Redis开发与运维》一书的节选,相信这本书会是国产技术书籍的精品!

    原文作者:SQL
    原文地址: https://segmentfault.com/a/1190000008931971
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞