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

命令RDBAOF阐明
启动优先级低高当同时启用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）