Redis的RDB和AOF的区别

一、Redis提供了哪些持久化机制

1，RDB持久化：

是在指定的时间间隔内将内存中的数据集快照到磁盘中。

2，AOF持久化：

该机制是以日志追加的形式记录服务器的每一个写操作，当redis服务器启动之初会读取该文件，并加载到数据库中，以保证数据库的数据是完整的。

3，无持久化：

通过配置文件来关闭redis的持久化机制。

redis服务器默认是RDB持久化机制。

二、RDB机制的优势和劣势

优势：

a，该机制只有一个文件，对于文件备份归档是相当完美的方式

b，对于灾难恢复而言是便捷的，可以非常轻松的将一个单独的文件压缩后再转移到其他的存储介质上。

c，性能最大化。对于redis服务进程而言，在开始持久化时，他唯一需要做的是fork出子线程，之后再由子进程来完成持久化操作，这样最大的避免了服务进程执行IO操作。

d，相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

劣势：

a，如果想最大程度的避免数据丢失，那RDB不是一个好的选择。因为系统一旦在定时持久化前发生宕机现象，此前没有写入磁盘的数据将会丢失。

b，由于RDB是通过fork子进程来协助完成数据持久化工作的，因此当数据集较大时，会导致redis服务停止服务几百毫秒，甚至一秒钟。

三、AOF机制的优势和劣势

优势：

a，该机制可以带来更高的数据安全性。Redis提供3种同步策略，即每秒同步，每次修改同步，不同步。

事实上，每秒同步也是异步完成的，效率也是非常高。所差的是，当这一秒内系统出现宕机现象，会丢失这一秒的数据。

而每修改同步，即每次修改操作都会立刻同步到磁盘，可想而知这种效率是最低的。

不同步，即不做任何同步操作。

b，该机制写入日志文件是采用append模式，因此即使在写入的过程中发生宕机现象，也不会对之前已写入的数据造成破坏。如果对写入一半的数据就发生系统奔溃，也不用担心，可以在下一次redis启动时，使用redis-check-aof工具来帮助我我们解决数据一致性问题。

c，如果日志文件过大，redis可以自动启用rewrite机制。即redis以append模式不断的将修改的数据写入到老的磁盘中，

同时redis又会创建一个新的文件用于记录此期间所有修改命令的执行，因此在进行rewrite切换时可以更好的保证数据的安全性。

d，AOF是一个包含格式清晰，易于理解的日志文件用于记录所有的修改操作。当然，我们可以通过此文件进行数据的重建。

劣势：

a，对于相同大小的数据集而言，AOF文件通常要大于RDB文件。

b，对于不同同步策略而言，AOF在运行效率上往往比RDB要慢。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率同RDB效率一样高效。

四、其他

1，AOF文件

Redis默认的同步机制是RDB机制，若要设置AOF机制，则需要修改配置文件的以下条目：

将 appendonly no 改为 appendonly yes

2，AOF配置

在Redis配置中有三种同步机制，他们是：

appendfsync always：每次有修改数据发生时写入到AOFf文件；

appendfsync everysec：每秒钟同步一次数据，这是AOF缺省策略；

appendfsync no：不同步数据，高效但是数据不会持久化；

3，如何修复损坏的AOF文件

1）将现有的AOF文件额外拷贝一份出来；

2）使用命令 "redis-check-aof --fix <文件名>"来修复损坏的AOF文件；

3）用修复后的AOF文件来重新启动Redis服务。

4，Redis的数据备份

可以通过copy 的方式在线备份正在运行的Redis数据文件，这是因为RDB文件一旦被生成就不会被修改。Redis总是把最新的数据dump到一个临时文件中，之后用rename函数原子性的将临时文件名改为原来的数据文件名。因此可以说，在任意时候拷贝Redis数据文件都是安全的和一致的。鉴于此，我们可以通过创建cron job（定时任务）的方式定时备份redis数据文件，并将备份文件copy到安全的磁盘介质中。

最后

以上就是繁荣小熊猫为你收集整理的Redis的RDB和AOF的区别的全部内容，希望文章能够帮你解决Redis的RDB和AOF的区别所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。