摘要：关于缓存热点重建原文说到在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃，并给出互斥锁和永远不过期两种候选方案。即使绕过互斥锁，也不会产生什么不好的后果，因为更新缓存是一个幂等操作。
向大家推荐这篇文章——Redis架构之防雪崩设计：网站不宕机背后的兵法
（另外推荐我去年的短文作为餐前点心——略谈服务端缓存设计）
《Redis架构之防雪崩设计》这篇文章（下文称之为“原文”）写得非常好，全面概括了大规模系统可能面对的缓存穿透和缓存雪崩等问题，可以看出是一线实战经验的精华总结，非常适合大家学习。
而我想再补充一些信息，使“原文”的版图更加完整。
关于“缓存穿透”“原文”给出了空对象和布隆过滤器两种解决方案。
空对象是首选方案，简单直接，碰到查询结果为空的键，放一个空值在缓存中，下次再访问就立刻知道这个键无效，不用发出SQL了。但“原文”也说了，存在如下问题：
第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。
对于第一点，我还建议空值放在另外的缓存空间中，不宜与正常值共用空间，否则当空间不足时，缓存系统的LRU算法可能会先剔除正常值，再剔除空值——这个漏洞可能会受到攻击。
对于第二点，如果是Redis缓存，更新数据后直接在Redis中清除即可；如果是本地缓存，就需要用消息来通知其他机器清除各自的本地缓存了。（业界终于接受了用消息来同步缓存的设计思想，cheers! ）我有一个小项目joint-cache-redis来简单地演示“用消息来同步多个机器的缓存”，而且在实践中发现Kafka可能比Redis MQ更适合于这个场景。
关于“缓存雪崩”这句概括很传神！缓存层宕掉后，流量会像奔逃的野牛一样，打向后端存储
没什么要补充的，就感谢一下Netflix开源的Hystrix吧！虽然只是一个库，但是要实现可靠的限流算法还是颇有门道的。
关于“缓存热点 key 重建”“原文”说到在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃，并给出“互斥锁”和“永远不过期”两种候选方案。
互斥锁(Mutex)：“分布式缓存加锁”通常是一个反模式（见我去年的文章大型服务端开发的反模式第7条），如果持有锁的实例不稳定导致没及时释放，就会浪费这个锁，直到锁过期。“原文”的作者还指出有死锁的风险。
其实是可以优化的：等待一两次后，重试时可绕过互斥锁。即使绕过互斥锁，也不会产生什么不好的后果，因为更新缓存是一个幂等操作。
也可以把锁的过期时间设得更短。
从这个例子我们能感觉到，幂等操作比非幂等操作更容易优化。
永远不过期："原文"很好地介绍了在Redis中的做法。对于Guava本地缓存就简单多了，使用refreshAfterWrite即可。
“原文”读到最后，才知道这是《Redis开发与运维》一书的节选，相信这本书会是国产技术书籍的精品！
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/61856.html
摘要：在某些查询中，可以将所有可能的查询条件放入这个集合，在查询之前使用这个集合对查询条件进行过滤，就可以避免缓存穿透的问题。解决方案二级缓存对于那些热度高的数据设置二级缓存，并且错开和一级缓存的失效时间，使请求不会同时穿透两层缓存去访问数据库 在我们的实际开发应用中，缓存机制的广泛存在，大大的提高了系统对数据库的请求承受阈值，但是在一些特定的场景下，需要去了解它可能出现的问题和对应的解决方...
摘要：缓存穿透是指查询一个一定不存在的数据。这就是缓存穿透请求的数据在缓存大量不命中，导致请求走数据库。并发下解决数据库与缓存不一致的思路将删除缓存修改数据库读取缓存等的操作积压到队列里边，实现串行化。 前言 只有光头才能变强。 文本已收录至我的GitHub仓库，欢迎Star：https://github.com/ZhongFuCheng3y/3y 回顾前面： 从零单排学Redis【青铜...
阅读 3449·2021-09-22 15:02
阅读 3469·2021-09-02 15:21
阅读 2115·2019-08-30 15:55
阅读 2759·2019-08-30 15:44
阅读 754·2019-08-29 16:56
阅读 2404·2019-08-23 18:22
阅读 3324·2019-08-23 12:20
阅读 3048·2019-08-23 11:28
