Redis的两种持久化方式
- RDB（Redis DataBase 数据快照模式）：定期存储，保存的是数据本身，存储文件是紧凑的；
- AOF（Append only file 追加模式）：每次修改数据时，同步到硬盘(写操作日志)，保存的是数据的变更记录；
RDB
RDB定时备份内存中的数据集。服务器启动的时候，可以从 RDB 文件中恢复数据集
优点：
- 存储的文件是紧凑的
- 适合用于备份，方便恢复不同版本的数据
- 适合于容灾恢复，备份文件可以在其他服务器恢复
- 最大化了Redis的性能，备份的时候启动的是子线程，父进程不需要执行IO操作
- 数据保存比AOF要快
缺点：
- 如果Redis因为没有正确关闭而停止工作时，到上个保存点之间的数据将会丢失
- 由于需要经常fork子线程来进行备份操作，如果数据量很大的话，fork比较耗时，如果cpu性能不够，服务器可能是卡顿。所以数据量大的时候，一个服务器不要部署多个Redis服务
创建快照的方式：
客户端发送BGSAVE指令，服务端会fork一条子线程将快照写入磁盘
客户端发送SAVE指令，服务端在主线程进行写入动作。一般不常使用，一般在内存不够去执行BGSVAE的时候才用
设置SAVE配置项，如SAVE 300 100，那么当“300秒内有100次写入”时，Redus会自动触发BGSAVE命令。如果有多个配置项，任意一个满足，都会触发备份
AOF
AOF记录服务器的所有写操作。在服务器重新启动的时候，会把所有的写操作重新执行一遍，从而实现数据备份。当写操作集过大（比原有的数据集还大），Redis 会重写写操作集；
优点：
- 使用AOF模式更加的灵活，因为可以有不同的fsync策略；
- AOF是一个日志追加文件，所有不需要定位，就算断电也没有损坏问题，哪怕文件末尾是一个写到一半的命令，redus-check-aof工具也可以很轻易的修复；
- 当AOF文件很大的，Redis会自动在后台进行重写。重写是绝对安全的，因为Redis是继续往旧的文件里面追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦创建完成，Redis就会切换到新文件，开始往新文件进行追加操作；
- AOF包含一个又一个的操作命令，易于理解和解析；
缺点：
- 对于同样的数据集，AOF文件通常要大于RDB文件
- AOF可能比RDB要慢，这取决于fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭sfync，即使在很高的负载下也和RDB一样快。不过，即使在很大的写负载情况下，RDB还是能提供很好的最大延迟保证
- AOF通过递增的方式更新数据，而RDB快照是从头开始创建，RDB会更健壮和稳定（所以适用于备份）
参考链接
Redis的持久化策略
原文：https://www.cnblogs.com/z-dk/p/14772097.html
