⑩①Redis持久化 RDB + AOF
Redis数据快照 - RDB
RDB：
-
RDB全称 Redis Database Backup file，即Redis数据备份文件，也被叫做Redis数据快照。
-
总的来说就是将内存中的数据都记录到磁盘中形成快照文件，当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。（在指定的时间间隔，执行数据集的时间点快照，
dump.rdb文件） -
# 由Redis主进程执行RDB，会阻塞所有命令 save # 开启子进程执行RDB，避免主进程受到影响 bgsave -
RDB执行原理：
设置RDB触发规则：
-
Redis内部有触发RDB的机制，可以通过
redis.conf配置文件进行设置：
RDB的优缺点：
- 优点：
-
- ①RDB保存时执行的是全量快照，适合大规模的数据恢复；
- ②可以按照业务定时备份；
- ③对数据完整性和一致性要求不高；
- ④RDB文件在内存中的加载速度比AOF文件快得多；
- 缺点：
-
- ①快照间的数据会丢失，原因是一定时间间隔备份一次，若期间redis宕机，就会丢失最近一次快照至当前这段时间的数据；
- ②内存数据的全量同步，若数据量太大会I/O严重而影响性能；
- ③RDB依赖主进程fork，数据集较大可能导致服务请求的瞬间延时，且fork时内存中的数据被克隆，占用两倍空间；
Redis追加文件 - AOF
AOF：
- AOF全称 Append Only File，即追加文件。 Redis处理的每一个写命令都会记录在AOF文件中 ，也可以将其看作日志文件。
- 只许追加AOF文件而不能修改AOF文件 ，Redis启动之初会读取该文件重新构建数据。（AOF保存的是
appendonly.aof文件） - 默认情况下，Redis AOF是没有开启的，开启需要修改Redis配置文件
redis.conf，修改内容为appendonly yes。
使用与策略：
- redis配置文件：
redis.conf中：
# 是否开启AOF功能 默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
# AOF的三种写回策略
# 1. 每执行一次写命令，立即记录到AOF文件
appendfsync always
# 2. 写命令执行完先放入AOF缓冲区，然后每间隔1秒将缓冲区数据写入AOF文件
appendfsync everysec
# 3. 写命令执行完先放入AOF缓冲区，由操作系统决定何时将数据写入AOF文件
appendfsync no
# AOF自动重写
# 1. AOF文件比上次文件 增长超过多少百分比会触发AOF重写
auto-aof-rewrite-percentage 100
# 2. AOF文件体积超过多少会触发AOF重写
auto-aof-rewrite-min-size 64mb
# AOF重写期间是否同步？no:期间可同步、yes：期间不同步。
no-appendfsync-on-rewrite no
AOF工作原理：
AOF优缺点：
- 优点：
-
- ①更好地保护数据不丢失、性能高、可做紧急恢复；
- 缺点：
-
- ①相同数据集的数据而言，aof文件远大于rdb文件，恢复速度也慢于rdb；
- ②aof运行效率慢于rdb，每秒同步策略效率较好，不同步策略效率与rdb相同；
RDB + AOF 混合模式
混合使用：AOF + RDB：
-
开启混合模式（修改
redis.conf配置文件） -
-
# yes表示开启，设置为no表示禁用 aof-use-rdb-preamble yes
-
-
执行原理（RDB镜像做全量持久化，AOF做增量持久化）：
-
- 先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写