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

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

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

《Redis架构之防雪崩设计》这篇文章（下文称之为“原文”）写得很是好，全面归纳了大规模系统可能面对的缓存穿透和缓存雪崩等问题，能够看出是一线实战经验的精华总结，很是适合你们学习。

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

关于“缓存穿透”

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

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

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

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

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

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

关于“缓存雪崩”

这句归纳很传神！缓存层宕掉后，流量会像奔逃的野牛同样，打向后端存储

没什么要补充的，就感谢一下Netflix开源的Hystrix吧！虽然只是一个库，可是要实现可靠的限流算法仍是很有门道的。

关于“缓存热点 key 重建”

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

互斥锁(Mutex)：

“分布式缓存加锁”一般是一个反模式（见我去年的文章大型服务端开发的反模式第7条），若是持有锁的实例不稳定致使没及时释放，就会浪费这个锁，直到锁过时。“原文”的做者还指出有死锁的风险。

实际上是能够优化的：等待一两次后，重试时可绕过互斥锁。即便绕过互斥锁，也不会产生什么很差的后果，由于更新缓存是一个幂等操做。

也能够把锁的过时时间设得更短。

从这个例子咱们能感受到，幂等操做比非幂等操做更容易优化。

永远不过时：

"原文"很好地介绍了在Redis中的作法。对于Guava本地缓存就简单多了，使用refreshAfterWrite便可。

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