这是我参与更文挑战的第24天，活动详情查看： 更文挑战
上一篇中提到Redis持久化的三种方式：
-
AOF日志：记录所有的操作命令，并以文本的形式追加到文件中
-
RDB快照 ：将某一时刻的内存数据，以二进制方式写入磁盘
-
混合持久化：Redis4.0版本后新增混合持久化方式，集成RDB和AOF的优点
为什么需要持久化？
redis缓存的谁都存储在内存当中，如服务器关闭或者Redis服务器守护进程退出，那么内存中的数据就会丢失。
适用场景：把Redis当作数据库使用，储存重要业务数据时，更加需要进行将数据持久化，防止造成影响。如果仅当作缓存使用，可不用考虑持久化。
AOF
AOF：Append Only File
AOF日志实现方式
AOF持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以Redis协议追加保存到以aof为后缀的文件，在Redis服务器重启时，会加载并运行aof文件的命令，以恢复数据。
注意内容：
MySQL数据库都是“写前日志”，即在写数据之前，先把修改的数据记到日志文件中。如mysql的redo log。而这一点和redis是相反的。Redis先执行命令，把数据写入内存，再把日志写入文件
为什么Redis先执行命令，再把数据写入日志？
- redis写日志之前，无需对命令进行语法检查
- redis只记录成功的命令
- 先执行后记录文件，避免阻塞当前的写操作
这样做，产生的不好的后果：
- 数据可能丢失
- 可能阻塞其他操作
开启AOF持久化方式
Redis默认不开启AOF持久化，我们自己修改redis.conf配置文件进行启动持久化
# 启动AOF机制
appendonly yes
# AOF文件名
appendfilename “appendonly.aof”
## 写入策略
appendfsync always
## 默认不重写aof文件
no-appendfsync-on-rewrite no
## 保存目录
dir ~/redis/
写入策略三种方式
appendfsync always
#appendfsync everysec
#appendfsync no
- always：客户端的每个写操作都保存到aof文件中，这种策略安全，但每个写请求都有IO操作，所以也很慢
- everysec：appendfsync的默认写入策略，每秒写入一次AOF文件
- no：由操作系统负责何时写入AOF文件，Redis服务器不负责写入，所以此方式不安全，不推荐使用
AOF优缺点：
AOF优点：
- AOF只追加日志文件，对服务器性能影响小，速度比RDB方式要快，消耗内存较少
AOF缺点：
- AOF生成的日志文件太大
- 恢复数据的速度比RDB慢
