redis的持久化有RDB和AOF两种方式。RDB(Redis Database)是redis在指定间隔将当前时间点的内存数据快照保存成一个二级制rdb文件。AOF(Append Only File)是将每一条写指令写入到特定日志文件，然后当服务重启时通过回放这些指令来恢复原来的数据集。redis可以同时开启RDB和AOF。当然如果只是使用redis来当作缓存使用，也可以不开启持久化，RDB和AOF都不开启。
RDB（Redis Database）
默认情况下redis是开启RDB持久化的。将快照文件存储在一个叫dump.rdb的文件。文件名可以通过dbfilename配置项来指定，文件位置可以通过dir配置项来指定。
dbfilename dump.rdb
dir data/6379/
rdb文件的存盘时机可以通过save配置项来配置
save <seconds> <changes>
表示在多少秒内至少有多少个写操作指令发生时触发存盘操作。
如下面默认的配置
#900秒内至少有一次写操作
save 900 1
#300秒内至少有10次写操作
save 300 10
#60秒内至少有10000次写操作
save 60 10000
如果在配置文件中一个save配置也没有，则代表关闭了RDB。
除了通过save配置进行周期性的自动生成RDB文件，还可以通过save和bgsave两个指令来手动触发快照的生成。
快照生成过程：
当Redis触发RDB持久化时，会fork一个子线程用来处理快照生成。这个子进程负责将内存中的数据dump到一个临时rdb文件中。当dump完成后，新的rdb文件会替换原来的rdb文件。
快照生成过程中redis可以处理写操作吗？
rdb持久化的子进程是由主进程fork出来的，可以共享主线程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。而在这个过程中，主线程仍然可以直接修改原来的数据。这里Redis 借助操作系统提供的写时复制技术（Copy-On-Write, COW），如果主线程要修改一块数据，那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件。
RDB持久化可能会对Redis的性能造成一些影响，特别是在写操作较多的情况下。尽管Redis可以继续处理请求，但创建快照时的I/O操作可能会导致延迟。
AOF(Append Only File)
开启AOF日志比较简单，在配置文件添加如下配置即可
appendonly yes
开启AOF日志后每个写操作都将记录到aof日志文件中。
执行几条写命令
127.0.0.1:6380> set name hello
OK
127.0.0.1:6380> set nums 2
OK
127.0.0.1:6380> set nums 3
OK
127.0.0.1:6380> set nums 4
OK
查看aof日志文件，日志文件在data配置项指定的目录下，文件名是appendonly.aof
set^M
$4^M
name^M
$5^M
hello^M
*3^M
$3^M
set^M
$4^M
nums^M
$1^M
2^M
*3^M
$3^M
set^M
$4^M
nums^M
$1^M
3^M
...
这里看到每个执行的写命令都会记入到AOF日志文件中。
写入策略
AOF通过appendfsync 参数来控制日志持久化到文件的策略，该参数有以下结果选项可以配置：
always：每次写操作都会将 AOF 文件同步到磁盘。这确保了数据的持久性，但会显著增加 I/O 操作，可能影响性能。
everysec：每秒钟将 AOF 文件同步到磁盘一次。这是一个折衷方案，提供了较好的性能和数据持久性。大多数情况下推荐使用这个选项，因为它在性能和数据安全性之间提供了平衡。
no：不强制将 AOF 文件同步到磁盘，而是依赖操作系统的缓存机制。这种设置可能会带来较高的性能，但数据丢失的风险也更大，因为可能会丢失最近未同步到磁盘的操作。
日志重写
AOF日志会将每一个写命令写入日志文件，随着时间的推移，日志文件会越来越大。redis数据集中的数只需要保存最终的结果即最新的结果信息，中间的过程没必要记录，比如一个计数的key从0累计到100中间会有99条set指令是过程记录，如果这些记录在aof中存放，在日志重放过程中也没必要保留，只需要知道当前key值是100即可。这时候就需要日志rewrite来优化AOF日志，基本上一个key使用一个写入命令，来简化AOF日志。
和日志重写相关的配置有以下两个
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage：设置触发 AOF 重写的百分比，默认值为 100，意味着 AOF 文件增长了一倍时会触发重写。auto-aof-rewrite-min-size：设置触发 AOF 重写的最小文件大小，默认值为 64MB。
AOF日志重写是由后台线程 bgrewriteaof 来完成的，不会阻塞主线程。
总结
RDB持久化对Redis的性能影响相对较小，因为它是通过创建数据库的快照来实现的。这种方式在生成快照的过程中，Redis会在后台执行，而不会对主线程的操作产生显著影响。RDB文件是经过优化的二进制格式，能够快速加载。相较于AOF文件，RDB在恢复数据时通常比AOF更快，适合需要快速恢复的场景。RDB文件可以方便地用于备份和迁移数据，因为它们是单个文件，易于复制和移动。也适合用于离线备份和灾难恢复。RDB持久化不会像AOF那样持续不断地记录操作日志，因此对磁盘I/O的压力较小，适合对I/O性能有严格要求的场景。RDB提供的数据一致性较好，因为在快照生成时，Redis会冻结数据库状态，使得快照的一致性得到保证。RDB也有一些缺点，比如数据恢复到最近一次快照的时间点可能会丢失一定量的数据。
AOF 通过记录每个写操作来持久化数据，通常可以通过配置将数据丢失降到最小。数据恢复更加精确。AOF 文件可能比 RDB 文件大，恢复速度相对也会比较慢。
在实际应用中，许多 Redis 部署会同时使用 RDB 和 AOF，这样可以兼顾性能和数据安全。通过这种方式，可以利用 RDB 的快速备份和恢复能力，同时通过 AOF 提供更高的数据完整性保障。
