Redis持久化
Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以 Redis 提供了持久化功能!
RDB(Redis DataBase)
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是Snapshot快照，它恢复时是将快照文件直接读到内存里。Redis默认为RDB模式。
Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中,待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
RDB的缺点是最后一次持久化后的数据可能天失。
1、测试持久化操作
- 修改配置文件
#vi redis.confsave 60 5 #只要60s内修改了5次key，就会触发rdb操作
dbfilename dump.rdb #RDB持久化文件
- 删除默认的rdb文件
#cd /usr/local/bin/dump.rdb
# ls
dump.rdb redis-benchmark redis-check-aof redis-check-rdb redis-cli redis-sentinel redis-server
# rm -rf dump.rdb
# ls
redis-benchmark redis-check-aof redis-check-rdb redis-cli redis-sentinel redis-server
- 创建KEY，60s内创建完成
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> set k5 v5
OK
- 生成新的dump.rdb文件
# ls
dump.rdb redis-check-aof redis-cli redis-server redis-benchmark redis-check-rdb redis-sentinel2、触发机制
- save的规则满足的情况下，会自动触发rdb规则；
- 执行 flusha 命令，也会触发rdb规则；
- 退出redis,也会产生 rdb 文件；
3、如果恢复rdb文件
只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检査dump.rdb 恢复其中的数据。
- 获取RDB文件的目录
127.0.0.1:6379> CONFIG get dir
1) "dir"
2) "/usr/local/bin"
4、优点&缺点
优点
- 适合大规模的数据恢复
- 对数据的完整性要不高
缺点 - 需要一定的时间间隔进程操作，如果redis意外宕机了，这个最后一次修改数据就没有的了
- fork进程的时候，会占用一定的内容空间
AOF(Append Only File)
将我们的所有命令都记录下来，类似mysql二进制文件，恢复的时候就把这个文件全部在执行一遍。
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来(读操作不记录)，只许追加文件但不可以改写文件。
redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
Aof保存的是 appendonly.aof 文件
1、测试AOF
- 修改配置文件
#vi redis.conf
appendonly yes
- 重启服务
# redis-cli -p 6379
127.0.0.1:6379> SHUTDOWN
not connected> exit
# redis-server /data/apps/redis-7.0.15/redis.conf
- 数据写入
# redis-cli -p 6379
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "yes"
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k6 v6
OK
- 生成aof文件
# ls
appendonly.aof redis-benchmark redis-check-aof redis-check-rdb redis-cli redis-sentinel redis-server
2、aof修复工具
如果这个 aof 文件有错位，造成 redis无法启动，我们需要修复这个aof文件，redis 给我们提供了一个工具。
redis-check-aof --fix appendonly.aof
3、优缺点
优点
- 每一次修改都同步，文件的完整会更加好!
- 每秒同步一次，可能会丢失一秒的数据
- 从不同步，效率最高的!
缺点 - 相对于数据文件来说，aof远远大于 rdb,修复的速度也比 rdb慢!
- Aof 运行效率也要比 rdb 慢，所以我们redis默认的配置就是rdb持久化!
4、重写机制
如果 aof 文件大于 64m，会fork一个新的进程来将我们的文件进行重写
参考
https://blog.csdn.net/m0_62218217/article/details/129899051
