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 比照

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 内存优化

5.4 批改 redis 配置文件

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

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