乐趣区

关于redis:Redis持久化及内存优化-springboot实战电商项目mall4j

springboot 实战电商我的项目 mall4j(https://gitee.com/gz-yami/mall4j)

Redis 长久化及内存优化

通过 redis 的配置文件来进行的一些长久化及内存优化操作,如有谬误欢送领导。

1. 为什么须要长久化

如果将用户数据保留到内存中,在服务器断电或者宕机时则会导致内存数据将清空, 导致缓存数据清空。

2. 对于长久化文件应用流程

在咱们装置了 redis 之后,所有的配置都在 redis.conf 文件中,外面保留了 RDB 和 AOF 两种长久化机制的各种配置。

 命令: 
    save: 示意以后数据长久化一次,生成 RDB 文件。bgsave: 内存数据在后盾长久化一次,生成 RDB 文件。命令区别:

       save: 当执行 save 指令时不容许用户持续 set 操作,陷入阻塞。bgsave: 当执行 bgsave 时,示意告诉 redis 须要进行长久化操作了,这时 redis 会依据用户的应用状况进行长久化,不会陷入阻塞,相似于 gc(垃圾回收机制)。长久化文件应用规定:

   当程序失常运行时会生成长久化文件,如果当服务器宕机后重启时,会依据配置文件中指定的长久化文件,进行数据的复原。

3. RDB 模式

3.1 阐明:

RDB 劣势

  1. RDB 模式是 redis 默认的长久化策略,文件紧凑,全量备份,非常适合用于进行备份和劫难复原。
  2. 生成 RDB 文件的时候,redis 主过程会 fork() 一个子过程来解决所有保留工作,主过程不须要进行任何磁盘 IO 操作。
  3. RDB 在复原大数据集时的速度比 AOF 的复原速度要快。
  4. RDB 模式每次操作时记录内存数据的快照,长久化文件较小。

RDB 问题:

1. 耗时,内存耗费,IO 性能耗费,将内存中的所有数据转储到硬盘上须要破费肯定的工夫工夫。Bgsave 模式 fork()子过程占用额定的内存,大量的硬盘读写也会耗费 IO 性能。

2. 无法控制的数据失落,在停机期间,上次快照之后写入的内存数据将失落。

3.2 批改长久化文件的名称和长久化文件保留的门路

3.3 RDB 模式默认快照形式

save 900 1   在 900s 之内,至多有 1 个 key 发生变化,则将快照写入磁盘。save 300 10   在 300 之内,至多有 10 个 key 发生变化,则将快照写入磁盘。save 60 10000  在 60s 之内,至多有 10000 个 key 发生变化,则将快照写入磁盘。

4. AOF 模式

4.1 什么是 AOF

Redis 的 RDB 模式全量备份总是耗时的,AOF 模式是对 RDB 模式的补充。当开启 AOF 模式(两种都关上时 AOF 的优先级高于 RDB 模式)时,每次执行 redis write 命令时,该命令会同时记录日志(以 AOF 结尾的日志文件)。当 Redis 产生故障时,只有执行日志回放,就能够复原数据。

4.2 开启 AOF 模式

批改 Redis 配置文件,改为 yes 即可。

4.3 AOF 的长久化策略

     #appendfsync always   #每次有数据发生变化时都会写入 appendonly.aof

        #appendfsync everysec  #默认形式,每秒同步一次到 appendonly.aof

        #appendfsync no    #不同步,数据不会长久化
        no-appendfsync-on-rewrite no  #当 AOF 日志文件行将增长到指定百分比时,redis 通过调用 BGREWRITEAOF 是否主动重写 AOF 日志文件。

通常应用 everysec 策略,这也是 AOF 的默认策略。

4.4 AOF 日志重写性能

当 AOF 的日志文件过大,redis 会主动重写 AOF 日志,append 模式一直的将更新记录写入到老日志文件中,同时 redis 还会创立一个新的日志文件用于追加后续的记录。

Aof 重写能够大大减小最终日志文件的大小。从而缩小磁盘耗费并放慢数据恢复。例如,咱们有一个计数服务,该计数服务具备许多主动递增操作,例如将密钥主动递增到 1 亿,这对于 AOF 文件来说是 1 亿 incr。Aof 重写仅记录一个记录。

4.5 两种 AOF 重写的办法

  • Bgrewriteaof 命令触发 AOF 重写

Redis 客户端将 bgrewriteaof 命令发送到 Redis,并且 Redis 服务器派生一个子过程来实现 AOF 重写。此处的 AOF 重写是将 Redis 内存中的数据追溯到 AOF 文件。而不是重写 AOF 文件以生成要替换的新 AOF 文件。

  • AOF 重写配置

    • auto-aof-rewrite-min-size:重写 AOF 文件所需的大小
    • auto-aof-rewrite-percentage:AOF 文件增长
    • aof\_current\_size:计算 AOF 的以后大小(字节)
    • aof\_base\_size:上一次启动和重写 AOF 的大小(字节)
  • AOF 主动重写的触发工夫应同时满足以下两点:

    • aof\_current\_size > auto-aof-rewrite-min-size
    • aof\_current\_size – aof\_base\_size/aof\_base\_size > auto-aof-rewrite-percentage

5. RDB 和 AOF 比照

命令 RDB AOF 阐明
启动优先级 当同时启用 RDB 和 AOF 时,重新启动 Redis 后抉择 AOF 进行复原。在大多数状况下,它保留的数据比 RDB 更新
体积 RDB 以二进制模式存储并压缩。只管 AOF 被 AOF 重写,然而它的容量绝对较大。毕竟它是以日志记录的模式
复原速度 RDB 体积小,复原速度较快。AOF 量大,复原迟缓。
数据安全 丢数据 依据策略决定 RDB 在最初一个快照后会失落数据。AOF 依据 Always,everysec 和 No 的策略来决定是否失落数据。
轻重 Aof 是一个追加日志,因而它是一个轻量级的操作。RDB 是一项占用大量 CPU 的操作,会占用大量磁盘以及对内存耗费会比拟大。

6. Redis 内存优化策略

Redis 反对多种内存驱赶策略以限度内存使用量,局部基于 LRU 和 LFU 的算法。

6.1 LRU 算法

LRU 是 Least Recently Used 的缩写,即最近起码应用,是一种罕用的页面置换算法,抉择最近最久未应用的页面予以淘汰。该算法赋予每个页面一个拜访字段,用来记录一个页面自上次被拜访以来所经验的工夫 t,当须淘汰一个页面时,抉择现有页面中其 t 值最大的,即最近起码应用的页面予以淘汰。

工夫 T: 数据自上一次到当初的工夫。

6.2 LFU 算法

阐明:LFU 算法是 redis5 当前才提出的。

LFU(least frequently used (LFU) page-replacement algorithm)。即最不常常应用页置换算法,要求在页置换时置换援用计数最小的页,因为常常应用的页应该有一个较大的援用次数。然而有些页在开始时应用次数很多,但当前就不再应用,这类页将会长工夫留在内存中,因而能够将援用计数寄存器定时右移一位,造成指数衰减的均匀应用次数。

6.3 Redis 内存优化

策略 阐明
noeviction (default) 如果在尝试插入更多数据时内存溢出,则返回谬误
allkeys-lru(recommended if unsure) 从所有数据中删除最近起码应用的数据
allkeys-lfu 从所有数据中删除最不罕用的数据
allkeys-random 从所有数据中随机删除数据
volatile-lru 删除所有数据中最近起码应用的数据,并设置“过期”字段
volatile-lfu 从设置了“过期”字段的所有数据中删除最不罕用的数据
volatile-random 设定了“过期”字段的数据随机删除
volatile-ttl 在设置了“过期”字段的所有数据中,删除最短的生存工夫数据。

5.4 批改 redis 配置文件

批改 maxmemory-policy 属性,抉择适合的策略即可。

springboot 实战电商我的项目 mall4j(https://gitee.com/gz-yami/mall4j)

退出移动版