Redis 原理缓存过期、一致性hash、雪崩、穿透、并发、布隆、缓存更新策略、缓存数据库一致性_redis雪崩

redis过期策略

redis的过期策略可以通过配置文件进行配置

一、定期删除

redis会把设置了过期时间的key放在单独的字典中，定时遍历来删除到期的key。
1）.每100ms从过期字典中 随机挑选20个，把其中过期的key删除；
2）.如果过期的key占比超过1/4，重复步骤1
为了保证不会循环过度，导致卡顿，扫描时间上限默认不超过25ms。根据以上原理，系统中应避免大量的key同时过期，给要过期的key设置一个随机范围。

二、惰性删除

过期的key并不一定会马上删除，还会占用着内存。 当你真正查询这个key时，redis会检查一下，这个设置了过期时间的key是否过期了? 如果过期了就会删除，返回空。这就是惰性删除。

三、内存淘汰机制

当redis内存超出物理内存限制时，会和磁盘产生swap，这种情况性能极差，一般是不允许的。通过设置 maxmemory 限制最大使用内存。超出限制时，根据redis提供的几种内存淘汰机制让用户自己决定如何腾出新空间以提供正常的读写服务。
（1）noeviction： 拒绝写操作， 读、删除可以正常使用。默认策略，不建议使用；
（2）allkeys-lru： 移除最近最少使用的key，最常用的策略；
（3）allkeys-random：随机删除某个key，不建议使用；
（4）volatile-lru：在设置了过期时间的key中，移除最近最少使用的key，不建议使用；
（5）volatile-random：在设置了过期时间的key中，随机删除某个key，不建议使用；
（6）volatile-ttl： 在设置了过期时间的key中，把最早要过期的key优先删除。

四、用java手写一个LRU算法实现

public class LRUCache<K,V> extends LinkedHashMap<K,V> {
    private int cacheSize;
    public LRUCache(int cacheSize){
        super(10,0.75f,true);
        //设置hashmap大小，true是让linkedhashmap按照访问顺序排序
        this.cacheSize = cacheSize;
    }
    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        //当map中数量大于指定缓存个数的时候，自动删除最老的数据
        return size()>cacheSize;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

redis分布式算法

如果有3个redis服务节点，分别是redis0，redis1，redis2 。现在一个资源，对他进行hash之后除3取余，余数分别是0，1，2 ，根据余数将该资源存储到对应的redis节点上。
因此此时的命中率为20%，即redis节点数从4个变成5个时，原有资源仍存放在对应redis节点上的概率为20%，剩下80%需要重新分配，影响较大。因此删除或增加一个redis节点，用传统的算法会使大量的缓存丢失，对后台服务器造成大量冲击。数据量达到百万千万级时，如果业务代码是穿透型的，会有大量的数据穿过cache直击DB，把数据库搞垮。（Hash链方式）

一致性hash算法原理

采用hash环算法
Hash链，只经过了1次hash，即把key hash到对应的机器编号。
而Hash环有2次Hash：
（1）用机器的IP导致 对2的32次方取模。
（2）把key也hash到这个环上。然后在这个环上进行匹配，看这个key和哪台机器匹配。
这样，每个机器负责对应段上的数据。

详见：https://blog.csdn.net/qq_48168706/article/details/123392472

他们在这个环形空间的位置会是固定的，因此则会形成如下存储关系：存储key的环形缓存和，存储值得值得环形缓存，因为hash算法一直，所以存储的对应位置也相同；

如果此时架构变动，移除一个cache节点B，此时产生变化的object4将会存储到cacheC上。因此，产生影响的范围是cacheB与cacheA之间的范围，影响相对小很多。
优点：避免在缓存服务器地址变化导致整个缓存在hash，缓存雪崩的问题；
而此时如果不是移除节点，而是新增一个节点cacheD，object2不在存放在cacheC上，而是会存放到cacheD上，此时影响的范围也知会在cacheB到cacheD之间。所以无论增加或删除一个节点，影响的范围都是很小的。

Hash倾斜性

但是hash算法又有倾斜性，上图中ABC3个cache节点分布的都比较均匀，而实际的情况会是如下图所示，ABC他们可能会挨得非常紧。从图中来看将会有大量的数据落在A上，不具有随机性，3个cache节点的负载性能都不均匀。

虚拟节点

因此需要增加虚拟节点。每个cache节点都会生成一个虚拟节点，并重新hash，重新散布到环形hash空间上，如下图，相对均匀了一些。 但即便是增加虚拟节点，还是会出现hash倾斜性的问题。的确，因此实际编码过程中配置一定的虚拟节点与真实节点的比例，随着数据越来越多，虚拟节点越来越低，使影响降到最低。
Consistent hashing命中率
(1-n/(n+m))*100%
服务器台数是n，而新增的服务器台数是m。当变动的服务器台数m越大，命中率越大，所以在变动时影响越来越小。当分布式集群越来越大时，一致性hash算法的优势就越明显。

redis分布式连接池取的ShardedJedis对象，而这个对象最终继承自Sharded，源码中也可以看出，初始化分块时，会有160乘以权重的虚拟节点。一般场景中会设置100-500个虚拟节点

Redis雪崩、穿透、并发等5大难题

缓存雪崩

数据未加载到缓存中，或者缓存同一时间大面积的失效，从而导致所有请求都去查数据库，导致数据库CPU和内存负载过高，甚至宕机。

应对办法

缓存的高可用性

缓存层设计成高可用，防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。

缓存降级

可以利用ehcache等本地缓存(暂时支持)，但主要还是对源服务访问进行限流、资源隔离（熔断）、降级等。
当访问量剧增、服务出现问题仍然需要保证服务还是可用的。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级，这里会涉及到运维的配合。
比如推荐服务中，很多都是个性化的需求，假如个性化需求不能提供服务了，可以降级补充热点数据，不至于造成前端页面是个大空白。
在进行降级之前要对系统进行梳理，比如：哪些业务是核心(必须保证)，哪些业务可以容许暂时不提供服务(利用静态页面替换)等，以及配合服务器核心指标，来后设置整体预案，比如：
（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

3.Redis备份和快速预热

1)Redis数据备份和恢复
2)快速缓存预热
4.提前演练
最后，建议还是在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，对高可用提前预演，提前发现问题。

缓存穿透

缓存穿透是指查询一个一不存在的数据。例如：从缓存redis没有命中，需要从mysql数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。
解决思路：
如果查询数据库也为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库。设置一个过期时间或者当有值的时候将缓存中的值替换掉即可。
可以给key设置一些格式规则，然后查询之前先过滤掉不符合规则的Key。

缓存并发

这里的并发指的是多个redis的client同时set key引起的并发问题。其实redis自身就是单线程操作，多个client并发操作，按照先到先执行的原则，先到的先执行，其余的阻塞。当然，另外的解决方案是把redis.set操作放在队列中使其串行化，必须的一个一个执行

缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。
这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
解决思路：
1、直接写个缓存刷新页面，上线时手工操作下；
2、数据量不大，可以在项目启动的时候自动进行加载；
目的就是在系统上线前，将数据加载到缓存中。
以上就是缓存雪崩、预热、降级等的介绍。

布隆过滤器

布隆过滤器是一种空间效率很高的随机数据结构，它利用位数组和哈希函数来判断一个元素是否存在于集合中，主要用于在大规模数据中判断一个元素是否存在。

原理

布隆过滤器基于一个位数组和若干个哈希函数，其中位数组是一个由0和1组成的数组，初始值全部为0。当一个元素加入到布隆过滤器中时，会通过多个哈希函数生成多个哈希值，然后将这些哈希值对应的位数组位置设置为1。当一个元素要查询是否存在于布隆过滤器中时，也会通过多个哈希函数生成多个哈希值，然后查询这些哈希值对应的位数组位置是否都为1。如果任何一个位数组位置不为1，那么该元素肯定不存在于布隆过滤器中。如果所有位数组位置都为1，那么该元素可能存在于布隆过滤器中。因为多个元素可能会被哈希到同一个位数组位置上，所以存在误判的情况，但是不会漏掉任何一个元素。

布隆过滤器优点

布隆过滤器相比其他数据结构有如下优点：

• 空间效率高：布隆过滤器只需要一个位数组和若干个哈希函数，所以它的空间效率很高。
• 查询效率高：布隆过滤器的查询效率非常高，因为它只需要对位数组进行查询，而不需要真正的查询数据。
• 可扩展性强：布隆过滤器可以根据需要动态调整位数组大小。

布隆过滤器缺点

布隆过滤器相比其他数据结构有如下缺点：

• 无法删除元素：因为布隆过滤器的位数组中只能将元素对应的位设置为1，不能设置为0，所以无法删除元素。
• 存在误判率：由于布隆过滤器使用的是哈希函数，所以在处理大量数据时，误判率是无法避免的。即使增加哈希函数的数量和布隆过滤器的大小，误判率也无法完全消除。

Redis布隆过滤器实现

Redis提供了布隆过滤器的实现，可以通过Redis的命令进行操作。下面是Redis布隆过滤器常用命令：

• 2.1 BF.ADD 将元素添加到布隆过滤器中。

语法：

BF.ADD key element [element …]
参数：

key：布隆过滤器的名称。
element：要添加的元素。
返回值：

如果元素已经存在于布隆过滤器中，返回0。
如果元素不存在于布隆过滤器中，将元素添加到布隆过滤器中并返回1。
示例：

BF.ADD myfilter fooBF.ADD myfilter bar

• 2.2 BF.EXISTS 判断元素是否存在于布隆过滤器中。

语法：

BF.EXISTS key element
参数：

key：布隆过滤器的名称。
element：要查询的元素。
返回值：

如果元素存在于布隆过滤器中，返回1。
如果元素不存在于布隆过滤器中，返回0。
示例：

BF.EXISTS myfilter fooBF.EXISTS myfilter baz

• 2.3 BF.MADD 将多个元素添加到布隆过滤器中。

语法：

BF.MADD key element [element …]
参数：

key：布隆过滤器的名称。
element：要添加的元素。
返回值：

返回一个数组，表示每个元素是否添加成功。如果元素已经存在于布隆过滤器中，返回0；如果元素不存在于布隆过滤器中，将元素添加到布隆过滤器中并返回1。
示例：

BF.MADD myfilter foo bar baz

• 2.4 BF.MEXISTS 判断多个元素是否存在于布隆过滤器中。

语法：

BF.MEXISTS key element [element …]
参数：

key：布隆过滤器的名称。
element：要查询的元素。
返回值：

返回一个数组，表示每个元素是否存在于布隆过滤器中。如果元素存在于布隆过滤器中，返回1；如果元素不存在于布隆过滤器中，返回0。
示例：

BF.MEXISTS myfilter foo bar baz

• 2.5 BF.INFO 获取布隆过滤器的信息。

语法：

BF.INFO key
参数：

key：布隆过滤器的名称。
返回值：

返回布隆过滤器的信息，包括布隆过滤器的大小、哈希函数的个数和误判率等。
示例：

BF.INFO myfilter

缓存更新策略

内存淘汰(无需编码)

超时剔除(无需编码)

主动更新(需要编码)

需要我们手动编写业务逻辑，在修改数据库的同时，更新缓存。主动更新策略有三种

1. Cache Aside Pattern：由缓存的调用者，在更新数据库的同时更新缓存。

2. Read/Write Through Pattern：缓存和数据库整合为一个服务，由服务来维护一致性。调用者调用服务，不用关心一致性问题。

3. Write Behind Caching Pattern：调用者只操作缓存，由其他线程异步的将缓存数据持久化到数据库，最终保持一致。

一般在数据一致性要求比较低的场景下可以使用内存淘汰机制，比如商城首页的分类信息，这些东西基本上是不会变化的。如果一致性要求比较高，我们可以采用主动更新+超时剔除兜底的方式来处理。

在企业中使用最多的主动更新策略是 Cache Aside Pattern。也就是我们自己编码来保证数据的一致性。

操作缓存和数据库时有三个问题需要我们考虑

1. 删除缓存还是更新缓存
   1）更新缓存：每次更新数据库都更新缓存，无效写操作比较多。
   这种方式的缺点很明显，举个例子：假如我更新了100次数据库，然后又同时更新了100次缓存，但是在更新的时候并没有人来查这个数据，那么我更新这100次缓存好像也没啥用吧，相当于前99次都是无用功，只有最后一次才是有用的。这就是无效写操作过多的原因。

2）删除缓存：更新数据库时让缓存失效，查询时再更新缓存。（延迟加载）一般选择这个方案
这个方案比较合理一点，可以避免过多的无效写操作，缓存删除后，只要没人来查询这条数据，数据就不会被写入缓存，这样就可以避免大量无效的写操作。

缓存和数据库的一致性

1）单体系统，将缓存与数据库操作放在一个事务中。
2)分布式系统，利用TCC等分布式事务方案。

先操作缓存还是数据库

1.先删除缓存，再操作数据库

这种方式存在很明显的问题，假设有两个并发操作，线程A更新，线程B查询。线程A先删除缓存，然后还没来得及更新数据库，CPU资源被线程B抢走，线程B查询缓存发现没有命中(因为已经被线程A删除了)，查询数据库，然后把结果写入到缓存中。这个时候线程A终于抢到CPU资源了，然后更新数据库，此时就会造成数据不一致问题。

2. 先操作数据库，再删除缓存（使用最多的方式）

这种处理方式使用的频率是最高的，因为出错的概率非常小，只有一种比较极端的情况才会出现数据一致性问题。
同样有两个并发请求，线程A查询、线程B更新，当线程A查询的时候，缓存刚好失效，然后就去查询数据库拿到数据，在准备写入缓存的时候，CPU资源被线程B抢走，线程B开始更新数据库，然后删除缓存(这一步其实等于无用，因为缓存已经过期)。此时线程A再次获取到CPU资源，然后写入缓存，此时写入的是更新前的旧数据，会产生数据一致性问题。
看起来这确实也是一个问题，但是我们仔细分析一下这种情况都需要满足哪些条件：

1. 并发读写操作
2. 读缓存时，缓存刚好失效
3. 写数据库操作要比写缓存快
   写数据库是操作磁盘，写缓存是操作内存的，所以不太可能会出现写磁盘的速度快于写内存的。因此使用这种方式出现数据一致性的概率是很小的。

3.延时双删策略

延迟双删策略是分布式系统中数据库存储和缓存数据保持一致性的常用策略，但它不是强一致。其实不管哪种方案，都避免不了Redis存在脏数据的问题，只能减轻这个问题，要想彻底解决，得要用到同步锁和对应的业务逻辑层面解决。

前面两种方案的不足点我们进行了分析，第二种方式的使用频率比较高，但是也有一些小缺陷，虽然说发生的概率很低，但是这个概率到了线上会不会发生也不好说，所以就有了延时双删策略对第二种方式做补充。

所谓延时双删就是先进行缓存清除，再执行数据库操作，最后（延迟N秒）再执行缓存清除。延迟N秒的时间要大于一次写操作的时间，这个延时N秒就是了完善保证第二种策略中不足，可以保证线程A的写缓存和线程B的修改数据库、删除缓存都执行完毕，然后再删除缓存一次，就可以保证后面再来的查询请求可以查询到最新数据。
ps: 一般的延时时间设置为3S左右，具体情况要根据业务场景取最佳值。