Redis不只是缓存,还有n多种你没发现的妙用( 二 )


Redis不只是缓存,还有n多种你没发现的妙用

文章插图
 
# user1的用户分数为 10zadd ranking 10 user1zadd ranking 20 user2# 取分数最高的3个用户zrevrange ranking 0 2 withscores过期策略定期删除
redis 会将每个设置了过期时间的 key 放入到一个独立的字典中,以后会定期遍历这个字典来删除到期的 key 。
定期删除策略
Redis 默认会每秒进行十次过期扫描(100ms一次),过期扫描不会遍历过期字典中所有的 key,而是采用了一种简单的贪心策略 。
从过期字典中随机 20 个 key;
删除这 20 个 key 中已经过期的 key;
如果过期的 key 比率超过 1/4,那就重复步骤 1;
惰性删除
除了定期遍历之外,它还会使用惰性策略来删除过期的 key,所谓惰性策略就是在客户端访问这个 key 的时候,redis 对 key 的过期时间进行检查,如果过期了就立即删除,不会给你返回任何东西 。
定期删除是集中处理,惰性删除是零散处理 。
为什么要采用定期删除+惰性删除2种策略呢?
如果过期就删除 。假设redis里放了10万个key,都设置了过期时间,你每隔几百毫秒,就检查10万个key,那redis基本上就死了,cpu负载会很高的,消耗在你的检查过期key上了
但是问题是,定期删除可能会导致很多过期key到了时间并没有被删除掉,那咋整呢?所以就是惰性删除了 。这就是说,在你获取某个key的时候,redis会检查一下 ,这个key如果设置了过期时间那么是否过期了?如果过期了此时就会删除,不会给你返回任何东西 。
并不是key到时间就被删除掉,而是你查询这个key的时候,redis再懒惰的检查一下
通过上述两种手段结合起来,保证过期的key一定会被干掉 。
所以说用了上述2种策略后,下面这种现象就不难解释了:数据明明都过期了,但是还占有着内存
内存淘汰策略这个问题可能有小伙伴们遇到过,放到Redis中的数据怎么没了?
因为Redis将数据放到内存中,内存是有限的,比如redis就只能用10个G,你要是往里面写了20个G的数据,会咋办?当然会干掉10个G的数据,然后就保留10个G的数据了 。那干掉哪些数据?保留哪些数据?当然是干掉不常用的数据,保留常用的数据了
Redis提供的内存淘汰策略有如下几种:
  1. noeviction 不会继续服务写请求 (DEL 请求可以继续服务),读请求可以继续进行 。这样可以保证不会丢失数据,但是会让线上的业务不能持续进行 。这是默认的淘汰策略 。
  2. volatile-lru 尝试淘汰设置了过期时间的 key,最少使用的 key 优先被淘汰 。没有设置过期时间的 key 不会被淘汰,这样可以保证需要持久化的数据不会突然丢失 。(这个是使用最多的)
  3. volatile-ttl 跟上面一样,除了淘汰的策略不是 LRU,而是 key 的剩余寿命 ttl 的值,ttl 越小越优先被淘汰 。
  4. volatile-random 跟上面一样,不过淘汰的 key 是过期 key 集合中随机的 key 。
  5. allkeys-lru 区别于 volatile-lru,这个策略要淘汰的 key 对象是全体的 key 集合,而不只是过期的 key 集合 。这意味着没有设置过期时间的 key 也会被淘汰 。
  6. allkeys-random 跟上面一样,不过淘汰的策略是随机的 key 。allkeys-random 跟上面一样,不过淘汰的策略是随机的 key 。
持久化策略Redis的数据是存在内存中的,如果Redis发生宕机,那么数据会全部丢失,因此必须提供持久化机制 。
Redis 的持久化机制有两种,第一种是快照(RDB),第二种是 AOF 日志 。快照是一次全量备份,AOF 日志是连续的增量备份 。快照是内存数据的二进制序列化形式,在存储上非常紧凑,而 AOF 日志记录的是内存数据修改的指令记录文本 。AOF 日志在长期的运行过程中会变的无比庞大,数据库重启时需要加载 AOF 日志进行指令重放,这个时间就会无比漫长 。所以需要定期进行 AOF 重写,给 AOF 日志进行瘦身 。
RDB是通过Redis主进程fork子进程,让子进程执行磁盘 IO 操作来进行 RDB 持久化,AOF 日志存储的是 Redis 服务器的顺序指令序列,AOF 日志只记录对内存进行修改的指令记录 。即RDB记录的是数据,AOF记录的是指令
RDB和AOF到底该如何选择?
  1. 不要仅仅使用 RDB,因为那样会导致你丢失很多数据,因为RDB是隔一段时间来备份数据
  2. 也不要仅仅使用 AOF,因为那样有两个问题,第一,通过 AOF 做冷备没有RDB恢复速度快; 第二,RDB 每次简单粗暴生成数据快照,更加健壮,可以避免 AOF 这种复杂的备份和恢复机制的 bug


    推荐阅读