【Redis核心知识 九】Redis企业级解决方案【缓存预热、热备、雪崩、击穿、穿透】（一）

上一篇blog【Redis从入门到放弃系列 十五】Redis集群之Cluster模式及集群搭建可谓呕心沥血，一周的零碎时间学习加上周末4h的写，本篇聊些老八股，关于企业级的一些Redis缓存解决方案，包括：缓存预热、缓存雪崩、缓存击穿、缓存穿透，以及一些简单的性能监测指标。依据政策流程以及可能会在什么分支上发生什么灾难，我构建了下列的流程图，正确请求是先从缓存拿数据，拿不到再从数据库里拿。

缓存预热、缓存雪崩、缓存击穿主要原因为频繁访问数据库更新缓存，造成数据库压力过大，而穿透则是因为数据库也没有数据，不停的进行穿透请求，造成Redis服务器和数据库压力均很大。心里有个数后可以详细的看看各种情况及处理手段。

缓存预热

新的缓存系统没有任何缓存数据，在缓存重建数据的过程中，系统性能和数据库负载都不太好，所以最好是在系统上线之前就把要缓存的热点数据加载到缓存中，这种缓存预加载手段就是缓存预热。如果不预热会有如下问题产生：Redis服务器启动后迅速宕机、数据库和应用服务器也可能会宕机

现象和问题原因

排查Redis服务器发现如下现象：请求数据量较高；主从之间数据吞吐量达；数据同步操作频度比较高，数据库读取频度比较高。主要原因为重启时Redis的缓存中没有数据。

解决方案

因为主要问题是缓存没有预先加载，导致重启时扛不住这么大的访问压力，所以主要解决问题思路就是预加载数据，但是预加载也不能加载全部，需要有策略的预加载数据：

• 要预加载数据，提前给redis中嵌入部分数据，再提供服务。但不可能将所有数据都写入redis，因为数据量太大了，耗费的时间太长了，第而且redis根本就容纳不下所有的数据
• 要有依据的加载，日常统计高热度访问数据；依据当天的具体访问情况，试试统计出频率较高的热数据
• 要加快高热数据的加载速率，然后将访问频率较高的热数据写入到redis，热数据比较多，需要多个服务并行的读取数据去写，并行的分布式的缓存预热

处理完成后后将嵌入的热数据的redis对外提供服务，这样就不至于冷启动，直接让数据库奔溃了。当然其中最重要的一点就是如何统计热数据，按照如下执行顺序去统计

1. nginx+lua将访问量上报到kafka中，要统计出来当前最新的实时的热数据是哪些，我们就得访问的请求对应的流量，日志，实时上报到kafka中
2. storm从kafka中消费数据，实时统计出每个商品的访问次数，访问次数基于LRU内存数据结构的存储方案，优先用内存中的一个LRUMap队列去存放，性能高，而且没有外部依赖，apache commons collections有开源的实现，设定好map的最大大小，就会自动根据LRU算法去剔除多余的数据，保证内存使用限制，即使有部分数据被干掉了，下次来重新开始计数即可，如果被LRU算法淘汰说明不是热数据
3. 每个storm task启动的时候，基于zk分布式锁，将自己的id写入zk的一个节点中
4. 每个storm task负责完成自己这里的热数据的统计，比如每次计数过后，维护一个前1000个key的list，每次计算完都更新这个list
5. 开启一个守护线程，每隔一段时间，比如一分钟，将排名前1000的热数据list同步到zk中

确定好日常统计的热数据后。在启动前进行加载，启动时

1. 使用脚本程序固定触发数据预热的过程
2. 条件允许，可以使用CDN进行加速

以上就是缓存预热完整的一个解决方案。可以想象，如果没有预热，大量的请求穿透Redis服务器进入数据库，不但数据库扛不住，接下来给Redis更新缓存数据，Redis服务也扛不住啊。

缓存雪崩

缓存雪崩是指缓存中短期内有大批量的key集中过期，而查询数据量巨大，导致短期内应用服务器、数据库、Redis服务器和集群扛不住压力集中宕机。

现象和问题原因

为了便于理解，我将雪崩时的现象和背后的原因做了一个对应关系的展示：

解决方案

其实主要问题就是短时间内key的集中化过期，我们让这些key不集中过期其实就是解决这个问题的关键。

• 调整删除策略，LRU和LFU的删除策略，按照命中次数去进行删除，保留高热数据key
• 稀释数据有效期，对不同的业务数据进行统计和分类错峰过期，错峰使用随机时间实现，稀释key的集中到期数量
• 超热数据使用永久的key
• 定期维护，对即将过期的热点数据进行延时策略，延长过期时间
• 加锁，缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。

加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量。假设在高并发下，缓存重建期间key是锁着的，这时过来1000个请求999个都在阻塞的。同样会导致用户等待超时，加锁排队有可能还要解决分布式锁的问题；线程还会被阻塞，用户体验很差！因此，在真正的高并发场景下很少使用！加锁的伪代码如下：

//伪代码
public object GetProductListNew() {
    int cacheTime = 30;
    String cacheKey = "product_list";
    String lockKey = cacheKey;
    String cacheValue = CacheHelper.get(cacheKey);
    if (cacheValue != null) {
        return cacheValue;
    } else {
        synchronized(lockKey) {
            cacheValue = CacheHelper.get(cacheKey);
            if (cacheValue != null) {
                return cacheValue;
            } else {
              //这里一般是sql查询数据
                cacheValue = GetProductListFromDB(); 
                CacheHelper.Add(cacheKey, cacheValue, cacheTime);
            }
        }
        return cacheValue;
    }
}

缓存击穿

缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。导致短期内数据库扛不住压力集中宕机

现象和问题原因

为了便于理解，我将击穿时的现象和背后的原因做了一个对应关系的展示：

解决方案

其实主要问题就是单个超热key的高并发访问，我们让超热key不过期其实就是解决这个问题的关键。

• 预先设定超热Key，对此类Key设置长期Key并追加延时策略【后台开启定时任务刷新有效期】
• 临时设置永久Key，访问业务量短期内激增的时候，临时设置为永久Key保证不过期
• 加分布式锁，防止被击穿，其实就是降低对数据库的访问压力，但整体依然是阻塞的。

简单地来说，加分布式锁就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是在获取到锁后再进行操作。

缓存穿透

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，数据库的压力骤增。 导致短期内数据库扛不住压力宕机

现象和问题原因

为了便于理解，我将穿透时的现象和背后的原因做了一个对应关系的展示：

解决方案

其实主要问题就是大量请求对数据库击穿，我们让请求到不了数据库就行了：

• 缓存null，如果一个查询返回的数据为空（无论是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。问题是：空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间（最长不超过五分钟），让其自动剔除。还有就是缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象
• 白名单策略，提前预热所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。还有最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力
• 实时监控，实时监控redis命中率中null的占比，平时监测一个数量，如果超过多少倍就认定有攻击，增加黑名单策略
• key加密，防止黑客知道哪些key不存在，让key加密。

以上就是整个缓存穿透的一个解决方案

性能指标监控

分为性能指标、内存指标、基本活动指标、持久性指标和错误指标几类。

性能指标

性能指标

主要检测的是当前Redis服务器的性能使用状态

单个请求响应时间越快越好；平均每秒处理请求数越多越好；缓存命中率低，数据库请求压力会大；

内存指标

主要检测的是当前Redis服务器的内存使用状态

已使用内存适量最好，不宜过多，过多扛不住；内存碎片率越低说明利用的越好；由于最大内存限制丢弃的key越少越好；阻塞越少越好

基本活动指标

主要检测的是当前Redis服务器的连接状态

客户端连接数不宜过高；slave数量应当适量；最后一次主从交互后的秒数标识数据同步程度；Redis中key的总数如果降低，数据库压力可能会大。

持久性指标

主要检测的是当前Redis服务器的灾备状态

最后一次持久化到磁盘时间戳越大越好；最后一次持久化以后Redis更改数越少越好。这样灾备时丢的数据少。

错误指标

主要检测的是当前Redis服务器的错误状态

被拒绝的连接数过多就需要考虑调整配置；key失败命中次数越少越好；主从断开持续时间越短越好

性能指标指令

压测指令，直接在server服务器进行测试，监测Redis集群能扛住的访问压力：