详解Redis的两种持久化方式：RDB(快照)和AOF

Redis是一个内存的数据库 数据是临时的 无法被持久写入 当关闭Redis服务器的那一刻数据会被丢失
因而 可以将Redis内存中的数据持久化保存到硬盘上的文件中

Redis持久化存储支持两种方式：RDB和AOF

• RDB是一定时间取存储文件
• AOF是默认每秒去存储历史命令

官方建议两种方式同时使用 没有持久化的redis和memcache一样 相当于一个纯内存的数据库
Redis是支持持久化的内存数据库 也就是说redis需要经常将内存中的数据同步到硬盘来保证持久化

RDB(默认方式) ------------------------------------------------

RDB(snapshotting快照)是将数据写入一个临时文件 当持久化结束后 用这个临时文件替换上次持久化的文件 从而达到数据恢复

简单来说 就是当Redis重启会通过加载dump.rdb文件恢复数据

• 优点：使用单独子进程来进行持久化 主进程不会进行任何IO操作 保证了Redis的高性能
• 缺点：RDB是间隔一段时间进行持久化 如果持久化期间Redis发生故障 会发生数据丢失 因此这种方式更适合数据要求不严谨的时候

默认方式将内存中以快照的方式写入到二进制文件中 默认为dump.rdb
可通过配置来设置自动快照持久化的方式：若redis在n秒内如果m个key修改 就自动做快照

RDB是默认开启的 redis.conf中的具体配置参数如下:
save 900 1：900秒内 若超过1个key被修改 则发起快照保存
save 300 10：300秒内 若超过10个key被修改 则发起快照保存
save 60 10000：60秒内 若超过10000个key被修改 则发起快照保存

使用方式：

编辑redis.conf配置文件

#   after 900 sec (15 min) if at least 1 key changed
在15分钟后若至少有1个key被改变 就会持久化一次
save 900 1

#   after 300 sec (5 min) if at least 10 keys changed
在5分钟后若至少有10个key被改变 就会持久化一次
save 300 10

#   after 60 sec if at least 10000 keys changed
在60秒后若至少有10000个key被改变 就会持久化一次
save 60 10000

dbfilename dump.rdb：持久化数据存储在本地的文件
dir ./：默认持久化数据存储在本地的路径

---

AOF ------------------------------------------------

AOF(append-only file)将执行过的指令记录下来 数据恢复时按照从前到后的顺序再将指令执行一遍 从而实现数据恢复

简单来说 就是当Redis重启会执行之前全部执行过的命令 重建数据库

• 优点：可以保持更高的数据完整性
  若设置追加file的时间是1s 则若redis发生故障 则最多会丢失1s的数据
  且若日志写入不完整 支持redis-check-aof来进行日志修复
  当AOF文件没被rewrite(文件过大时对命令进行合并重写)之前 可以删除其中的某些误操作的命令
• 缺点：AOF文件比RDB文件大 且恢复速度慢

aof比快照方式有更好的持久化性 是由于redis在使用AOF时 redis会将每一个收到的写命令都通过write函数追加到命令中 在redis重新启动时会重新执行文件中保存的写命令在内存中重建这个数据库的内容
这个文件是在redis/bin目录下的appendonly.aof
AOF并不是立即写到硬盘上 但可以通过配置文件修改强制写到硬盘中

使用方式：

编辑redis.conf配置文件
由于AOF机制默认是关闭的 因此需将appendonly no改为appendonly yes

# appendfsync always  每一次操作 收到写命令就立即写入到磁盘 效率最慢 但是保证完整的持久化（最常用）
appendfsync everysec  每隔一秒都进行持久化 性能和持久化兼顾
# appendfsync no  不进行持久化 完全依赖os 性能最好 但持久化没保证

会将数据持久化到目录下的appendonly.aof文件中
注：开启AOF后之前的RDB模式就失效了 且之前的数据会被清空

---

总结：

AOF方式对性能影响较大 而RDB方式有可能丢失部分数据
因此Redis并不能保证所有数据都不丢失 并不能保证数据的绝对安全
还需要用关系型数据库来确保数据的绝对安全

---