redisrdb（redisrdb和aof的区别）

本篇文章给大家谈谈redisrdb，以及redisrdb和aof的区别对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Redis RDB持久化模式缺陷
• 2、Redis的持久化机制 (RDBamp;AOFamp;混合模式)
• 3、Redis 持久化之AOF与RDB的区别
• 4、redis的RDB和AOF两种持久化机制优缺点分析

Redis RDB持久化模式缺陷

error:MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails

强制把redis快照关闭了导致不能持久化的问题

解决:127.0.0.1:6379 config set stop-writes-on-bgsave-error no

一、RDB持久化模式缺陷

1.问题描述：

并发200路，模拟不断写Redis，持续4小清伏氏时后，接口调用开始出现大量失败，错误信息如下：

{"data":{"sendResult":null},"base":{"returncode":"99999","returndesc":"系统异常：MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error."},"qrybase":{"total":0,"count":0,"start":0}}

1

2.原因分析：

解读错误信息，以为是磁盘不够用引起，结果发现磁盘还剩余42%，如下所示：

于是根据错误信息提示开启Redis日志，继续压测，接口依然报错，但可从Redis日志信息中

Can’t save in background: fork: Cannot allocate memory

进程使用内存不当有关，查看Redis主进程占用内存如下：占用近55%*4G内存

具体原因：Redis在保存数据到硬盘时为了避免主进程假死，需要Fork一份主进程，然后在Fork进程内完成数据保存到硬盘的操作，如果主进程使用了2.2GB的内存，Fork子进程的时候需要额外的2.2GB，此时内存就不够了，Fork失败，进而数据保存硬盘也失败了。

3.缓解方案（不能根本解决问题）：

3.1 修改redis.conf文件中配置项stop-writes-on-bgsave-error no （默认值为yes），即当bgsave快照操作出错时停止写数据到磁盘，这样后面写错做均会失败，为了不影响后续写操作，故需将该项值改为no

3.2 修改内核参数（如下3种方式），但需要root权限：

（1） 编辑/etc/sysctl.conf ，改vm.overcommit_memory=1，然后sysctl -p 使配置文件生效

（2）答散sysctl vm.overcommit_memory=1

（3）echo 1 /proc/sys/vm/overcommit_memory

1

2

3

二、AOF持久化模式缺陷

1.问题1描述：

Redis主从节点均开启AOF模式，并发200路，模拟不断写Redis，持续15分钟后，接口调用开始出现大量失败，且Redis所在的Linux虚拟服务器挂起。

接口报错如下：

{"data":null,"base":{"returndesc":"系统异常","returncode":"999999"},"qrybase":null}

Biz（dubbo）接口报错如厅乱下：

2015-06-05 11:28:28.760 [DubboServerHandler-X.X.X.X:20882-thread-173] ERROR  - error while validate jedis!

redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out

1

2

3

4

原因分析：

从dubbo接口报错信息来看，是由于接口API操作Redis超时导致。从系统日志和IO监控来看，均说明上述问题是由于IO瓶颈（系统IO过于繁忙）所致，如下所示：

从系统日志也能看出，IO阻塞时间超过了120秒，由于系统安全机制导致机器挂起。

总结

测试结果证明AOF模式存在最明显缺陷，即访问压力大时IO会成为性能瓶颈，进而导致服务不可用。

3.缓解方案（不能根本解决问题）

编辑/etc/sysctl.conf ，添加如下配置：

vm.dirty_background_ratio = 5

vm.dirty_ratio = 10

1

2

然后sysctl -p 使配置文件生效。

问题2描述：

无论采用AOF模式还是RDB（快照模式），当两文件（.aof或.rdb）大小超过系统内存80%，Redis进程会被系统Kill掉，导致服务不可用。

总结

上述问题说明我们在使用Redis时需要事先做好系统内存的容量规划，因为一旦Redis宕掉会导致大量数据丢失且是不可恢复的。

Redis的持久化机制 (RDBamp;AOFamp;混合模式)

RDB（Redis DataBase，快照方式） 是将某一个时刻的内存数据，以二进制的方式写入磁盘。 AOF（备迹Append Only File，文件追加方式） 是指将所有的操作命令，以文本的形式追加到文件中。

RDB

RDB 默认的保存文件为 dump.rdb，优点是以二进制存储的，因此 占用的空间更小 、数据存储更紧凑，并且与 AOF 相比，RDB 具备 更快的重启恢复能力 。

AOF

AOF 默认的保存文件为 appendonly.aof，它的优点是存储频率更高，因此 丢失数据的风险就越低 ，并且 AOF 并不是以二进制存储的，所以它的存储信息更易懂。缺点是 占用空间大 ， 重启之后的数据恢复速度比较慢 。

混合

在 Redis 4.0 就推出了混合持久化的功能。Redis 混合持久化的存储模式是， 开始的数据以 RDB 的格式进行存储 ，因此只会占用少量的空间， 并且之后的命令会以 AOF 的方式进行数据追加 ，这样就可以减低数据丢失的风险，同时可以提高数据恢复的速度。

Fork

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，迟滚明并作为原进程的子进程。

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时（ 默认值 64M ），Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。Redis 会fork出一条新进程来将 文件重写Rewrite (也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记码告录有一条的set语句。重写aof文件的操作，并没有读取旧的aof文件， 而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

Redis 持久化之AOF与RDB的区别

Redis有两种持久化策略，即aof与rdb，当我们使用redis不小心宕机的时候，你会发现粗没旁一个类似redis.dump.rdb的文件，它其实就是redis持久化的一个镜像文件，就是把内存上的数据备份一份到硬盘察巧上，等待下次启动时读取出来，先说说两者的区别

RDB方式

AOF方式

从这两种方式的工作原理可以看出他们的优缺点，先说说RDB

再说说AOF 的优点

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开redis.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no #从不同步。岩橡高效但是数据不会被持久化。

[img]

redis的RDB和AOF两种持久化机制优缺点分析

redis持久化的意义主要是为了做 灾难恢复、数据恢复 其实可以把它归类到高可用的一个环节。

RDB持久化机制，对redis中的 数据 执行周期性的持久化。

AOF机制对 每条写入命令 作为日志，以append-only的模式写入一个日志文件，在redis重启对时候，可以通过回放AOF日志中写入的指令来重新构建整个的数据集。

如果同时使用AOF和RDB两种持久化机制 ，那么在redis重启的时候，会使用AOF来重新构建数据，因为AOF中的数据更加的完整。

优点：

（1）RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备。可以将文件存储到云端，本地磁盘等等。

（2）RDB机制对redis对外提供读写服务时候的影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB的持久化即可。

（3）相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加的快速。

缺点：

（1）如果想让redis出现故障，尽可能的少丢失数据戚蔽坦，那么RDB没有AOF好。因为一般来说，RDB数据快照文件，基本上都是每隔5分钟或者更长的时间，生成一次，这个时候，如果一旦发生宕机，那么就会把这段时间内的数据都丢失掉。

（2）RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。

优点：

（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行fsync操作，最多丢失1秒钟的数据。

（2）AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易受损，即使文件尾部受损，也能很容易恢复，打开文件，把后面损坏的数据删除即可。

（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log 的时候，会对其中的指令进行压缩，创建出一份需要恢复数据对并渣最小日志出来，再创建新日志文件的时候，老日志文件还是会照常写入指令，当新的日志文件生成好之后，会将旧日志文件中后面写入的指令合并到新的日志文件中，这个新的merge后的日志文件，会在ready的时候，与旧的日志文件进行交换。之后就会把旧的日志文件删除掉。

（4）AOF文件中保存的是执行的指令，所以这个特性非常适高桐合做灾难性的误操作紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么久可以立即拷贝这个AOF文件出来，将最后一条flushall命令删除，然后再将AOF文件放回去，就可以通过恢复机制，自动的恢复所有数据了。

缺点：

（1）对于同一份数据来说，AOF的日志文件通常要比RDB的数据快照文件要大。

（2）AOF开启之后，Redis服务支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然每秒一次fsync的性能也还是很高的。

（3）以前的AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来，所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge，而是基于当时内存中的数据进行指令的重新构建，这样健壮性能更好一些。

综合使用两者，用AOF来保证数据尽可能的少丢失，作为第一选择，其次在AOP丢失或者损坏的情况下，用RDB来更加快速的恢复数据。

关于redisrdb和redisrdb和aof的区别的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。