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 劣势
- RDB 模式是 redis 默认的长久化策略,文件紧凑,全量备份,非常适合用于进行备份和劫难复原。
- 生成 RDB 文件的时候,redis 主过程会 fork() 一个子过程来解决所有保留工作,主过程不须要进行任何磁盘 IO 操作。
- RDB 在复原大数据集时的速度比 AOF 的复原速度要快。
- 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)