redis篇(二):redis内部原理机制

redis

内存回收

过期策略

  1. 定时过期

    通过redis的expire设置过期时间,每个key都需要创建一个定时器,到期删除,对内存友好。但是会占用大量cpu处理过期数据,影响缓存的响应时间和吞吐量

  2. 惰性删除

    访问key时判断是否过期需要清除,节省cpu资源,对内存不友好。大量过期key未被访问导致不释放

    获取数据时候的expireIfNeed方法以及写入key发现内存不足调用activeExpireCycle释放部分内存

  3. 定期过期

    间隔一定时间扫描expire字段项中的key,清除过期的key。通过调整间隔扫描时间,达到cpu和内存的最优。与定期删除的不同在于不需要实时去清除过期数据。间隔时间为redis.conf中的hz字段(单位为秒,默认为10,可配置)

    image-20200619160143595
  • redis同时使用惰性删除以及定期过期

淘汰策略

达到极限时候淘汰算法来清除数据,最大内存通过配置文件的maxmemory参数设置,maxmemory_policy指定淘汰策略

LRU,Least Recently Used:最近最少使用

LFU,Least Frequently Used,最不常用,根据使用频率计算,4.0 版本新增

  1. 淘汰策略

    淘汰策略 说明
    volatile-lru 设置expire数据中使用次数最少
    allkeys-lru 所有数据中使用次数最少
    volatile-ttl 设置expire数据中淘汰即将过期的数据
    volatile-random 设置expire数据中随机淘汰
    allkeys-random 所有数据随机淘汰
    no-enviction 所有写入操作报错,读操作正常
    volatile-lfu 设置expire数据中选择最不常用的
    allkeys-lfu 在所有的键中选择最不常用的

    传统LRU算法内部原理:通过链表维护缓存,最新缓存放在头部。如果缓存被访问,则迁移到链表头部。淘汰数据从尾部开始淘汰即可。淘汰对象追加到AOF文件当中

redis volatile-lru/volatile-lfu/volatile-ttl/allkeys-lru/allkeys-lfu淘汰策略原理:获取样本根据排序权值idel进行排序,从最后的元素开始淘汰,相比LRU链表成本低


redis-lru淘汰方式:根据配置的采样值 maxmemory_samples随机获取一定数量,淘汰热度最低的值

  • 热度判断:redisObject维护了value的热度值,server.lruclock是定时任务(每100ms调用一次)更新的unix时间戳(源码:server.c#updateCachedTime)单位秒,24位只能存储194天,超过则从头计算
  • 存在问题:lru采用随机取样,因此取样数量越大,淘汰数据越精确,消耗的cpu也就越高


redis-lfu淘汰方式:server.lruclock高16位存储时间(分钟),低8位用于存储频次(读写时更新)

根据衰减因子 lfu-decay-time(N分钟),频次会根据时间减少N

Random:随机删除

持久化机制

redis的两种持久化方案:RDB(Redis DataBase)快照、AOF(Append Only File)

默认是RDB方式

RDB

image-20200619163609121

内存数据写入磁盘,生成.rdb文件,重启加载该文件恢复

RDB文件解析:

  1. REDIS:载入时用于判断是否是RDB文件
  2. db_version:用于记录RDB版本号
  3. databses:存储数据内容
  4. EOF:结束标志,程序加载到这个标志代表RDB文件已经载入完毕
  5. check_sum:校验标志,检验传入值和自己计算出来的值是否一致,用来判断文件是否损坏

触发时机:根据redis.conf配置的save参数定时备份(配置格式save 100 1)代表100秒内存在1次修改就备份

  • shutdown触发,保证服务器正常关闭
  • redis定时任务serverCron(每100毫秒执行一次)判断是否需要执行备份

指令触发:save和bgsave指令

  • save指令会阻塞进程,不建议使用
  • bgsave:redis进程fock子进程进行备份,fock之后的数据不写入,阻塞之间只有fock子进程的过程这段很短时间的阻塞。查看最近快照时间命令:lastsave。查看上次成功后进行的修改次数:dirty
  • 执行bgsave期间执行save会被服务器拒绝:防止产生竞争条件

优势

  1. 适合备份和灾难恢复
  2. 主进程不需要进行磁盘io操作
  3. RDB恢复数据量大时效率大于AOF

劣势

  1. fock子线程的阻塞以及成本
  2. 一定量的数据丢失:两次备份过程中shutdown导致的部分丢失

AOF

img

执行更改的redis操作指令追加到AOF文件当中,重启通过执行AOF中的指令恢复数据

开启方式:配置文件中appendonly yes

文件增大问题:redis重写机制,保证AOF文件大小超过指定阈值后进行内容压缩,只保留可恢复的最小指令集。

原理:读取最新数据,通过一条命令去替换过程中的命令,生成新的AOF文件

例子:

  1. 初始数据SET name a
  2. 过程指令APPEND name b、APPEND name c、APPEND name d
  3. 当前name的值应该是abcd 则AOF进行压缩后只会存APPEND name bcd这条指令

缓存写入aof文件的时机:根据配置文件决定,默认是everysec

image-20200619165511657

重写过程中发生的写入:存储在缓冲区当中,机制可配置

优势:丢失数据最多是同步频率的时间,默认1秒

缺点:文件大,高并发下RDB性能好

  • 方案选择:最好结合使用:优先使用aof,aof处于关闭状态则使用rdb

你可能感兴趣的:(redis篇(二):redis内部原理机制)