持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第8天，点击查看活动详情 Redis作为重要的消息中间件， 并且是内存存储，服务重启可能会丢失数据，数据持久化就成为了重中之重。下面跟随b站黑马的视频学习redis持久化。 Redis一共有两种持久化方式:
- RDB持久化
- AOF持久化
RDB持久化
RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。 快照文件称为RDB文件，默认是保存在当前运行目录。
使用save即可开启，但由于用主线程执行RDB，会阻塞其他所有命令，在redis停机时会先执行一次RDB，具体可以自己试试。
配置RDB
Redis默认配置RDB，RDB的配置可以在redis.conf文件中设置
# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1
save 300 10
save 60 10000 代表60秒内至少执行1000次修改则触发RDB
上述可以触发RDB操作，可以按照自己需要进行修改
# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes
# RDB文件名称
dbfilename dump.rdb
# 文件保存的路径目录
dir ./
关于bgsave
bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。 fork采用的是copy-on-write技术： 当主进程执行读操作时，访问共享内存； 当主进程执行写操作时，则会拷贝一份数据，执行写操作，同时写新RDB文件替换旧RDB文件。
通过对redis的分析我们发现
- RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
- fork的子进程、压缩、写出RDB文件都比较耗时 下面认识一种新的持久化方式
AOF持久化
AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。就是把所有命令集合在一起，但是重启的话要把每个命令执行一下，虽然数据量大时会有点慢而且一些操作显得多余，但是数据全面丢失的可能性很小。 通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。
配置AOF
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
# 表示每执行一次写命令，立即记录到AOF文件，可靠性高但对性能影响很大
appendfsync always
#默认方案 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件 最多只会丢失1s的数据
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘，可能丢失数据但性能最好
appendfsync no
Redis可以设置在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置
# AOF文件比上次文件 增长超过多少百分比则触发重写 默认
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 默认
auto-aof-rewrite-min-size 64mb
总结
可以看到，RDB与AOF各有优劣，目前redis也在测试结合两者使用，在实际开发中可以根据优缺点结合使用。
