redis中AOF和RBD的用法是怎样的

这篇文章给大家介绍redis中AOF和RBD的用法是怎样的，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

redis 典型应用场景：

Rdb文件

Rdb文件就相当于是mysql中的mysqldump将内存中的所有数据都备份到本地磁盘上。

RDB(Redis DataBase)：基于时间的快照，其默认只保留当前最新的一次快照，特点是执 行速度比较快，缺点是可能会丢失从上次快照到当前时间点之间未做快照的数据。

RDB 实现的具体过程 Redis 从主进程先 fork 出一个子进程，使用写时复制机制，子进 程将内存的数据保存为一个临时文件，比如 dump.rdb.temp，当数据保存完成之后再 将上一次保存的 RDB 文件替换掉，然后关闭子进程，这样可以保存每一次做 RDB 快 照的时候保存的数据都是完整的，因为直接替换 RDB 文件的时候可能会出现突然断 电等问题而导致 RDB 文件还没有保存完整就突然关机停止保存而导致数据丢失的情 况，可以手动将每次生成的 RDB 文件进程备份，这样可以最大化保存历史数据。

RDB 模式的优缺点：

优点：

-RDB 快照保存了某个时间点的数据，可以通过脚本执行 bgsave(非阻塞)或者 save(阻 塞)命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不同时间点 的版本。

可以最大化 IO 的性能，因为父进程在保存 RDB 文件的时候唯一要做的是 fork 出一 个子进程，然后的-操作都会有这个子进程操作，父进程无需任何的 IO 操作RDB 在大量数据比如几个 G 的数据，恢复的速度比 AOF 的快

缺点：

-不能时时的保存数据，会丢失自上一次执行 RDB 备份到当前的内存数据

-数据量非常大的时候，从父进程 fork 的时候需要一点时间，可能是毫秒或者秒或者 分钟，取决于磁盘 IO 性能。

AOF文件

AOF文件类似于mysql中的二进制日志，如果redis在上一次完全备份到下一次完全备份的这段时间里面发生的宕机的情况，这段时间所生成的数据就会丢失，而AOF文件可以将这段时间的数据保存下来。

注：：：当开启AOF功能时，redis每次重启都会加载的是AOF文件，而不是RDB文件，当关闭AOF功能时，就算有AOF文件，重启redis也不会加载该文件。‘

按照操作顺序依次将操作添加到指定的日志文件当中，特点是数据安全性相对 较高，缺点是即使有些操作是重复的也会全部记录。

AOF 和 RDB 一样使用了写时复制机制，AOF 默认为每秒钟 fsync 一次，即将执行的命 令保存到 AOF 文件当中，这样即使 redis 服务器发生故障的话顶多也就丢失 1 秒钟之 内的数据，也可以设置不同的 fsync 策略，或者设置每次执行命令的时候执行 fsync， fsync会在后台执行线程，所以主线程可以继续处理用户的正常请求而不受到写入 AOF 文件的 IO 影响

AOF 模式优缺点：

AOF 的文件大小要大于 RDB 格式的文件

根据所使用的 fsync 策略(fsync 是同步内存中 redis 所有已经修改的文件到存储设备)，

默认是 appendfsync everysec 即每秒执行一次 fsync

aof相关配置如下：

############################## APPEND ONLY MODE ###############################

# 是否开启AOF，默认关闭（no）

appendonly yes

# 指定 AOF 文件名

appendfilename appendonly.aof

# Redis支持三种不同的刷写模式：

# appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。

appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。

# appendfsync no     #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。

#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。

#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no

no-appendfsync-on-rewrite no

#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。

auto-aof-rewrite-percentage 100

#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

auto-aof-rewrite-min-size 64mb

关于redis的AOF刷写模式和日志重写：

由于写操作通常是有缓冲的，所以有可能AOF操作并没有写到硬盘中，一般可以通过fsync()来强制输出到硬盘中。而fsync()的频率可以通过配置文件中的flush策略来指定，可以选择每次事件循环写操作都强制fsync或者每秒fsync至少运行一次。

当rewrite子进程开始后，父进程接受到的命令会添加到aof_rewrite_buf_blocks中，使得rewrite成功后，将这些命令添加到新文件中。在rewrite过程中，原来的AOF也可以选择是不是继续添加，由于存在性能上的问题，在rewrite过程中，如果fsync()继续执行，会导致IO性能受损影响Redis性能。所以一般情况下rewrite期间禁止fsync()到旧AOF文件。这策略可以在配置文件中修改。

关于redis中AOF和RBD的用法是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。