redis持久化的两种方式以及优缺点

1.radis持久化的两种方式

1. RDB持久化方式—能在指定的时间间隔内对数据进行快照存储

2. AOF持久化方式—会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)

   在同时开启这两种持久化方式时,在redis重启时会优先载入AOF文件恢复原始数据,AOF文件保存的数据集要比RDB文件保存的数据集要完整

命令	RDB持久化	AOF持久化
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定
轻重	重	轻

2.RDB持久化方式的优缺点

1. RDB优点
   ①RDB是一个非常紧凑的文件,淘宝村某个时间点的数据集,非常适用于数据集的备份.
   ② RDB是一个非常进奏的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3(可能加密),非常适用于灾难恢复.
   ③RDB在保存RDB文件时,父进程唯一需要做的就是fork出一个紫禁城,接下来的工作全部由紫禁城来做,父进程不需要在做其他的IO操作,RDB持久化方式可以最大化redis的性能.
   ④于AOF相比,在恢复大的数据集是,RDB更快一些.

2. RDB缺点
   ① 如果你希望在redis意外停止工作(例如电源中断)的情况下丢失的数据量最小,那RDB不适合,虽然可以配置不同的save时间点(例:每隔5分钟并且对数据集有100个写操作),是redis要完整保存整个数据集的比较繁重的工作,通常需要每隔5分钟或者更久做一次完整的保存,玩意redis在意外宕机,可能会丢失几分钟的数据.
   ②RDB需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这情况会在持续1秒,AOF也需要fork,但是可以调节重写日志文件的频率来提高数据集的耐久度.

3. AOF持久化方式的优缺点

1. AOF的优点
① 使用AOF会让redis更加耐久,可以使用不同的fsync策略:无fsync,每秒fsync,每次写的时候fsync,使用默认的每秒fsync策略,redis的性能依然很好(fsync是有后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障,最多丢失1s的数据.
② AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满,写的过程中宕机等)未执行完整的写入命令,也可以使用redis-check-aof工具修复这些问题.
③ redis可以再aof在文件体积变大的时,自动的在后台对AOF进行重写:重写后的新aof文件包含了恢复当前数据集所需的最小命令集合.整个重写操作是绝对安全的,因为redis在创建新aof文件的过程中,会继续将命令追加到现有的aof文件里面,即使重写过程中发声停机,现有的aof文件也不会丢失.而一旦新aof文件创建完毕,redis就会从就aof文件切换到新aof文件,并开始对新的aof文件进行追加操作.
④ AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态.

2. AOF缺点
① 对相同的数据集来说,AOF文件的体积通常要大于RDB文件的体积
② 根据所使用的fsync策略,AOF的速度可能慢于RDB.在一般情况下,每秒fsync的性能依然很高,而关闭fsync可以让AOF的速度和RDB一样快,即使在高负荷之下也是如此.不过在处理巨大的写入载入时,RDB可以提供更有保证的最大延迟时间(latecy).