redis的持久化

1 持久化方式

1.1 RDB

在指定时间间隔内生成数据集的时间点快照。

1.2 AOF

记录每一条指令，新指令以追加的方式写入文件。重启服务器时重新执行指令恢复数据集。Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

1.3 RDB与AOF并用

同时开启两种持久化方式的重启redis优先使用AOP文件还原数据集，因为AOP文件比RDB文件保存的数据更加完成。

我们也可以关闭持久化功能，让数据只在服务器运行时存在

2 RDB的优点

• 当redis出现问题时能够将数据还原到不同的版本，可以自己设置多久备份一次数据和多久备份一个RDB文件
• 适用于灾难恢复，可以将文件转移到另一个数据中心。
• 可以最大化Redis的性能，因为备份时主进行只需要fork一个子进程出来，将备份工作交给子进程。
• 恢复大数据集时速度比AOF快

3 RDB的缺点

• 当redis出现故障时丢失的数据多，因为是隔一个时间段进行备份数据，redis出现故障时一段时间的数据将会丢失（备份工作量大，至少5分钟备份一次）。
• 如果数据量大主线线程fork比较耗时。

4 AOF的优点

• 当redis出现故障时数据丢失少，默认是每一秒同步一次命令。
• redis-check-aof工具也可以轻易地修复日志因为某些原因而包含了未写入完整的命令的问题。
• AOF文件过大时自动在后台对AOF进行重写，恢复当前数据集所需的最小命令集合，重写操作绝对安全。
• AOF 文件有序地保存了对数据库执行的所有写入操作，可读性高。

5 AOF的缺点

• 相同的数据集，AOF文件体积通常大于RDB。
• 使用fsync 策略，AOF的速度可能会慢于RDB,频繁的写入影响redis性能。
• AOF存在bug，导致无法将数据集恢复成保存时的原样。例如阻塞命令 BRPOPLPUSH source destination timeout 就曾经引起过这样的 bug 。

6 如何选择RDB和AOF

• 如果以保证数据安全为目标，同时开启两种持久化功能。
• 更关注于数据，并且能够承受数分钟的数据丢失，则使用RDB持久化。
• 不推荐单独使用AOF持久化。 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。