redis淘汰+过期双向保证高可用 |此篇告诉你为什么redis那么快(一)

港控/mmm° 2022-10-10 12:45 95阅读 0赞

# 前言 #

> `redis`和数据相比除了他们的结构型颠覆以外！还有他们存储位置也是不相同。传统数据库将数据存储在硬盘上每次数据操作都需要`IO`而`Redis`是将数据存储在内存上的。这里稍微解释下IO是啥意思。IO就是输入流输出流方式将数据在硬盘和内存之间进行交互！而`redis`直接在内存上就剩下了`IO`操作。这也是`redis`快的原因之一吧

*  内存相对于硬盘来说很宝贵。我们平时的电脑也是硬盘是内存的几百倍。既然内存很宝贵而`redis`又将数据存储在内存上那么`redis`肯定不能肆无忌惮的进行存储 。这就需要`redis`和开发者们作出相应的优化
 *  首先`redis`在配置文件(`redis.conf`)中通过`maxmemory`参数指定`redis` 设置整个对内存的支配大小！
 *  其次就是要求我们开发者在想`redis`中填值的时候根据自己的需求设置相应的key过期时间。这样不必要的数据就会被`redis`过期驱逐策略清楚。从而节省内存供别人使用

**本文凌驾于`redis`基础之上，这里笔者默认大家都已经安装了`redis`. 并实际使用过`redis`**

# 内存分配 #

*  `maxmemory` 指定大小。在`redis.conf`配置文件中可以直接指定。他的单位时byte。

![image-20210617144838455][]

*  上图中注释部分是给大家的解释，实际中\#配置需要换行哈！！！友情提示
 *  另外我们可以连接上`redis`通过`config`命令来设置

![image-20210617145851812][]

*  两种方式都可以设置，前者是全局设置重启之后仍然有效！后者是临时设置重启之后就会重新加载`redis.conf`中的配置。

# 键过期 #

*  上面我们从`redis`本身角度出发设置了内存限制，这样不用担心他们吞噬系统内存！下面就需要我们开发者设计角度约束自己了。

## 设置过期时间 ##

expire key time

*  设置过期时间默认单位时S 。
 *  然后通过ttl 命令可以查看剩余过期时间

![image-20210617151445320][]

*  经过多次执行`ttl`能够观察到剩余时间在不断的减少！当减少到0的时候就被给驱逐策略驱逐！注意这里说的是驱逐策略驱逐并不是意味着立马被删除

## 更新过期时间 ##

*  `del key` 直接将key删除了那么该key对应的过期自然也就不存在了！这种情况笔者也算作是更新过期时间
 *  `set` `getset`等命令重新设置key、value方式会覆盖过期时间 ， 直接被覆盖成-1

![image-20210617152121178][]

*  `set` 、 `getset`包括`del`严格意义是覆盖过期时间。真正做到更新过期时间的还是expire .在expire是已最新为准的！
 *  上面其实都修改了key才会应发原本的过期时间失效的！因为此key非彼key 。 但是`append`、`incr` 等命令是改变值这种命令是不会影响到原来的过期设置的

![image-20210617152731013][]

# 淘汰策略 #

*  根据上面配置我们可以将我们的`redis`最大内存设置为`1MB` , 设置大小随便最好能小点。然后我们通过`Java`小程序不断向`redis`中填充。最终当内存不够使用时就会报错

![image-20210617161613440][]

*  报错就是因为内存满了，新增的key被`redis`拒绝了！不仅仅是新增的被拒绝，就算此时我们想改变已经在`redis`中的key的值也是不可用的

public static void main(String[] args) { 
        Jedis jedis = new Jedis("39.102.60.114", 6379);
        jedis.auth("Qq025025");
        Integer index = 1;
        while (true) { 
            String uuid = UUID.randomUUID().toString();
            jedis.set(index.toString(), uuid);
            System.out.println(index++);
        }
    }

![image-20210617162804867][]

*  不管是append 还是set 都是报`OOM command not allowed when used memory > maxmemory` 。代码中打印和`redis`键个数一致；说明我们默认的淘汰策略是直接拒绝
 *  总结下来就是：当`redis`内存被使用满了后，任何的写操作都会被拒绝！
 *  当没有足够内存时难道就这么直接拒绝吗？上面也提到了需要我们程序员自己根据需求设置键过期已释放内存供其他有需要的key使用！那么设置了过期key之后这些key又是怎么被清除的呢？ 这就牵扯出我们的淘汰策略

![image-20210617163430236][]

## volatile-lru【最近很少使用】 ##

> 当内存告警时`redis`会将近期很少使用且设置了过期时间的key剔除出去，即使该key还没有到过期时间。如果没有符合的key也就是执行之后内存仍然不足时将会和默认淘汰策略`noeviction`抛出一样的错误`OOM command not allowed when used memory > maxmemory`

*  首先我们在`redis.conf`中配置我们最近很少使用策略. `maxmemory-policy volatile-lru` 。 然后重启我们的`redis`服务 。重启之后`flushall`清空所有数据，我们在通过上面的`Java`程序重新生成下数据！

![image-20210617165407096][]

*  Java程序中我们设置前100个key添加过期时间

public static void main(String[] args) { 
        Jedis jedis = new Jedis("39.102.60.114", 6379);
        jedis.auth("Qq025025");
        Integer index = 1;
        while (true) { 
            String uuid = UUID.randomUUID().toString();
            if (index < 100) { 
                jedis.setex(index.toString(),360, uuid);
            } else { 
                jedis.set(index.toString(), uuid);
            }
            System.out.println(index++);
        }
    }

![image-20210617171334220][]

*  简单分析下为什么程序计数器大于`redis`库中的key数量！就是因为我们为前100设置了过期时间。当内存不足时`redis`就会将当前设置了过期时间的key中最近最少使用的key进行剔除！所以我们计数器会大于键数量。因为有部分键被清除了！我们获取前100的key都是null ， 说明被删除了！ 那么为什么本次计数器不是比上次多100 。 那是因为我们每次存储进来的是uuid， 所占长度都不是固定的。还有本身淘汰策略也是占用内存的

![image-20210617173746769][]

## 策略总结 ##

*  上面演示了最近最少使用的淘汰策略！除此之外还有其他的策略

noeviction：拒绝写请求，正常提供读请求，这样可以保证已有数据不会丢失（默认策略）；
    2. volatile-lru：尝试淘汰设置了过期时间的key，虽少使用的key被淘汰，没有设置过期时间的key不会淘汰；
    3. volatile-ttl：跟volatile-lru几乎一样，但是他是使用的key的ttl值进行比较，最先淘汰ttl最小的key；
    4. volatile-random：其他同上，唯一就是他通过很随意的方式随机选择淘汰key集合中的key；
    5. allkeys-lru：区别于volatile-lru的地方就是淘汰目标是全部key，没设置过期时间的key也不能幸免；
    6. allkeys-random：这种方式同上，随机的淘汰所有的key。

*  使用哪种淘汰策略需要我们结合自己的项目场景来配合使用！！！

# 过期删除 #

*  上面我们从【键过期】、【淘汰策略】两个角度分析了`redis` 。 仅仅这两方面还没有完全高效使用内存！淘汰策略是濒临内存不足时触发。那么当设置了过期时间的键真正到了过期时间而此时内存尚够使用？这种场景是不是需要将过期键删除呢？
 *  因为`redis`是单线程，那么在键过期的时候如何不影响对外服务的同时清除过期键呢？答案是【不行】。严格意义是无法解决的因为单线程同时只能做一件事！既然无法解决那么我们可以达到一种协调状态！如果同一时刻出现一个过期键那么清除键很快这时候阻塞外部服务的时间很短可能毫秒级设置纳秒级！
 *  但是如何同一时间发生上万键过期，如果想要删除上万键那肯定需要花费一定时间这时候就会阻塞对外服务！这肯定是不能接受的，阻塞时间过长会导致客户端连接超时报错的。这在并发场景下更是无法接受的！所以`redis`如何应对同一时间过多数据过期的场景，他的删除过期键的方法略有不同！

## 定时清除 ##

*  针对每个过期键设置一个定时器，在过期时就会进行清理该键！
 *  该做法能够做到数据实时被清理从而保证内存不会被长期占用！提高了内存的使用率！
 *  但是问题也随之而来，每一个`key`需要设置一个定时器进行跟踪。`redis`这里笔者猜测应该是启用另外线程来进行定时跟踪！这里有清除的还请帮忙解答下？
 *  当同一时间过期`key`很多的时候！我们的CPU就需要不断的执行这些定时器从而导致CPU资源紧张。最终会影响到`redis`服务的性能

## 定期清除 ##

![image-20210618101552195][]

*  定期删除就是上面我们图示效果，`redis`会每隔`100ms`执行一次定时器，定时器的任务就是随机抽取20个设置过期的`key` 。 判断是否进行清除。上面图示中说明中写错了不是10S ， 而是每隔`100ms` 。请原谅我的粗心!!!

![image-20210618102943955][]

*  定期删除和定时删除作用是相反的！定期删除是将key集中进行处理同时为了保证服务的高可用在处理时加入的时间限制。每次执行总时长不能超过`25ms` 。 也就是说对于客户端来说服务端的延迟不会超过`25ms` 。
 *  他的优点就是不需要CPU频繁的进行操作key清除！因为他是定期进行清除所以就会导致一部分数据没有来得及清除从而导致内存使用上会被一直占用！

## 惰性清除 ##

*  关于惰性删除我们在平时开发中也经常使用这种方式！当数据过期时`redis`并不急着去清除这些数据，而是等到该key被再次请求时进行删除！这样在最终效果上是没有问题的。
 *  优点和定期清除一样他保证了CPU不必频繁的进行切换！但是缺点也很明显会导致很多已经过期的key任然在`redis`中。

## 惰性清除+定期清除 ##

*  我们开头说过了既要高可用又要实时清理过期key 这是无法做到的！既然无法做到我们就需要在CPU和内存中间做一个权衡！`redis`内部是使用惰性清除和定期清除两种方式结合使用，最终保重CPU和内存之间的一种平衡！

# 总结 #

*  相信大家对上面三个概念有点模糊了。【键过期】、【淘汰策略】、【过期清除】
 *  首先【键过期】是`redis`给我们开发者提供的功能。我们可以根据自己的业务需求合理的设置键的过期时间，从而保证内存的高可用
 *  其次【过期清除】在我们之前设置的过期的key如何进行合理的清除，并不能一股脑一下子进行清除因为数据过大会导致服务的卡顿。这个时候我们需要通过定期清除减缓清除key代码的卡顿。在`redis.conf`中我们可以设置 `hz 10` 代表`1S`中平均执行几次这也是我们上面所说的`100MS`的由来。但是仅仅定期删除会产生遗漏数据所以我们还需要加上惰性清除，最终保证对客户端来说数据是准确实时清除的。
 *  那么关于【淘汰策略】又是啥呢？在上面过期清除是如果用户一直不请求过期的key ，并且随着业务产生越来越多的过期key . 这时候`redis`服务中还会堆积很多过期的无效key 。这个时候如果内存不够用了的话那又该怎么办呢？这时候我们需要设置淘汰策略比如果`volatile-lru` . 就会将最近最少使用的设置过期key进行清除从而保证尽可能的接收更多的有效数据！
 *  这就是为什么会设计三者的原因！好好理解上面三个主题我们再去想想为什么会发生【缓存雪崩】、【缓存奔溃】、【缓存击穿】就好理解一点了呢？
 *  关于上述的`redis`常见的灾难场景，我们下章节继续分析如何产生的、并且如何进行修复进行展开讨论。

[image-20210617144838455]: /images/20221005/92898a76de5949bfa50660a4722b4ea1.png
[image-20210617145851812]: /images/20221005/190cec1a94984324b2082929b280aafd.png
[image-20210617151445320]: /images/20221005/c57b05e8e92c4470b93bca6324fbd812.png
[image-20210617152121178]: /images/20221005/244cc29636dc439d8aa61b63f4dfbf11.png
[image-20210617152731013]: /images/20221005/c549abcc3f954bd9b26f70749c337712.png
[image-20210617161613440]: /images/20221005/0cbeb2b2299b45fc9f2d16e41a15e127.png
[image-20210617162804867]: /images/20221005/bb54121a4af14ab9b7c3513cbef22169.png
[image-20210617163430236]: /images/20221005/2aabebf79b9c45b18cfdb3ee42e8a33e.png
[image-20210617165407096]: /images/20221005/c6c4fc0594674dd6b404637f8cef8711.png
[image-20210617171334220]: /images/20221005/069abc2c47d04bed82ee6b9e84053d88.png
[image-20210617173746769]: /images/20221005/6480565a009b4d42b081a0752f411c64.png
[image-20210618101552195]: /images/20221005/cd1c642c645848bea7e3879a5f42e312.png
[image-20210618102943955]: /images/20221005/68e8311e988e431fb9761ba806743f26.png