今天抽时间和大家聊聊redis的雪崩以及redis集群的演变过程。
首先来说说什么是redis的缓存雪崩。
如图是一个比较常见的业务流程图，先去看缓存是否存在，如果存在返回，如果不存在直接查数据库，并更新缓存。
一般在设置缓存的时候，都会去设置一个失效时间，防止无用缓存占用大量内存。
常见的缓存雪崩分为两种：
1，就是在某一时刻，大量缓存失效，导致大量查询直接落在数据库上，压垮数据库。
2，缓存数据库宕机了，导致所有的查询请求全部落在了数据库上
当然应对两种情况都有不同的解决方法，第一种就比较简单了，我针对不同的key设置不同的缓存失效时间即可，也是很容易想到的，这边不做过多讨论。
今天主要来说说这第二种。要知道在早期的缓存数据库大都是单机部署的，从单机到现在的大规模集群是经历了很长的一个发展周期的。关于redis的演变过程，大致可以分为如下几个历程：
如图，关于redis的发展历程大概可以分为如上几个阶段：单机 - 主从 - 哨兵 - 高可用集群：
现在成熟企业的redis主要都是基于一个大规模的redis集群，这也是为了解决redis的单点故障，保障了整个缓存系统的高可用性，关于redis高可用集群相关的详细介绍可以参考我的另一篇博文：redis高可用集群详细介绍
这篇文章详细介绍了redis的高可用集群的相关原理，搭建以及相关配置的详细介绍。有兴趣的可以了解下。
当redis高可用集群也是应对缓存单点故障导致缓存雪崩的主要解决方式。
