aof rdb 区别（redis的RDB和AOF两种持久化机制优缺点分析）

本文目录

• redis的RDB和AOF两种持久化机制优缺点分析
• redis两种持久化方式的区别是什么
• redis的 rdb 和 aof 持久化的区别
• redis存储方式有哪些
• 缓存-redis 三种模式搭建和运行原理
• Redis持久化的方式有哪些优缺点分别是什么

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来更加快速的恢复数据。

redis两种持久化方式的区别是什么

redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。（推荐学习：Redis视频教程）
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
RDB持久化和AOF持久化的区别：
1、存储数据
RDB持久化保存键空间的所有键值对(包括过期字典中的数据),并以二进制形式保存，符合rdb文件规范，根据不同数据类型会有不同处理。
AOF持久化保存redis服务器所执行的所有写命令来记录数据库状态,在写入之前命令存储在aof_buf缓冲区。
2、持久化时间选择
RDB持久化通过conf的save选项设置持久化行为(单位时间内的修改次数)。
AOF持久化通过conf的appendfsync选项设置持久化行为(单位时间内的修改次数)。
3、数据还原
RDB持久化：服务器载入rdb文件，阻塞线程，在载入完成之前不接受任何命令。
AOF持久化：服务器创建不带网络连接的伪客户端，读取aof文件中的所有命令并执行(redis服务开启aof持久化在服务器启动时会选择aof文件恢复数据库状态)
4、过期键
RDB持久化在写入或读取时会忽略过期键
AOF持久化不会忽略过期键，在键被惰性删除或定期删除时向aof文件追加一条删除命令
5、文件大小
RDB持久化随着存储数据量的变化而变化(根据不同数据类型有不同的数据压缩优化)
AOF持久化随着执行命令的增加而增加(通过aof重写进行优化)
更多redis相关技术知识，请访问Redis使用入门教程栏目学习！

redis的 rdb 和 aof 持久化的区别

Redis中的数据是存储在计算机内存中的，如果我们不进行配置，就会出现重启Redis后数据丢失的情况，这里就需要Redis中的持久化技术，它是将数据存储到磁盘中的，当Redis重启后仍可以从磁盘中获取数据，从而达到持久化的效果。
RDB和AOF有什么区别呢?
RDB持久化是在指定的时间间隔内，将内存中的数据集快照写入磁盘，实际操作过程是有一个fork子进程，先将数据集写入临时文件中，写入成功后再替换之前的文件，用二进制压缩存储。
而AOF持久化是以日志的形式记录在服务器所处理的每一个写、删操作，查询操作不会被记录，以文本的方式记录，可以打开文件看到详细的操作记录。
RDB的优点在于它的速度比较快，而且存储的是一个二进制文件，传输起来较方便;而缺点是RDB无法保证数据的绝对安全，有时候就是1秒也会造成很大的数据丢失。
AOF的优点在于比RDB更安全，一般不会出现数据丢失的现象，就算出现了数量也不会太大，当然了，官方是推荐同时开启AOF和RDB的;而缺点是AOF持久化的速度相比RDB要慢，存储的是一个文本文件，到了后期文件会比较大，传输困难。
需要注意的是，在重启Redis之后，需要加载一个持久化文件，有限会选择AOF文件，如果先开启了RDB再开启AOF，RDB先执行了持久化，那RDB文件中的内容会被AOF覆盖掉。

redis存储方式有哪些

Redis其实就是一个用C语言写的一个程序，这个程序用来存储 key-value数据，数据先放在内存，然后写入磁盘指定位置。
下面我们梳理一下Redis存储两种方式： RDB和AOF （推荐学习：Redis视频教程）
第一种方式：RDB(Redis DataBase)
RDB是将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。
rdis database存储方式，是将数据存储在一个xxx.rdb的文件中。文件中保存的数据就是redis中的内存数据。默认的存储方式，效率高，对磁盘的访问比较合理，对内存数据的监控也是有一定临界值的，保证数据尽可能不丢失。
redis.conf
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
# Note: you can disable saving completely by commenting out all "save" lines.
# It is also possible to remove all the previously configured save
# points by adding a save directive with a single empty string argument
# like in the following example:
# save ""
# 持久数据的规则. RDB持久规则. 存储数据的文件由dbfilename参数决定
save 900 1
save 300 10
save 60 10000
# RDB持久数据的文件命名. 可以使用绝对路径配置，如果没有路径配置，在命令运行的相对位置开始寻址存在。
dbfilename dump.rdb第二种方式：AOF（appendonly file)
AOF是将执行过的指令记录下来，数据恢复时按照从前到后的顺序再将指令执行一遍，实现数据恢复。
其中，AOF默认关闭，开启方法，修改配置文件redis.conf：appendonly yes
append of file 存储方式。对磁盘和IO的资源需求，比rdb方式高很多。对redis服务器的性能有很大的影响。Aof和rdb可以同时开启，但是，在redis重启的时候，会优先读取aof中保存的数据变化日志。不推荐同时启用，对磁盘的压力和IO的压力太高。推荐使用rdb。
# 是否启用append of file持久化方式.默认关闭.
# 每秒持久一次数据. 以追加的方式,持久到数据文件.
appendonly no
# aof持久方式的文件名称.
appendfilename "appendonly.aof"更多Redis相关技术文章，请访问Redis入门教程栏目进行学习！

缓存-redis 三种模式搭建和运行原理

标签： redis 缓存 主从 哨兵 集群

本文简单的介绍redis三种模式在linux的安装部署和数据存储的总结，希望可以相互交流相互提升。

对于Centos7在安装redis之前需要进行一些常用工具的安装：

关闭防火墙

正式安装redis

在redis进行maketest时候会出现一系列的异常，有如下解决方案：

用redis-server启动一下redis，做一些实验没什么意义。

要把redis作为一个系统的daemon进程去运行的，每次系统启动，redis进程一起启动，操作不走如下：

RDB和AOF是redis的一种数据持久化的机制。 持久化 是为了避免系统在发生灾难性的系统故障时导致的系统数据丢失。我们一般会将数据存放在本地磁盘，还会定期的将数据上传到云服务器。
　　 RDB 　是redis的snapshotting，通过redis.conf中的save配置进行设置，如 save 60 1000:

AOF 　是以appendonly方式进行数据的储存的，开启AOF模式后，所有存进redis内存的数据都会进入os cache中,然后默认1秒执行一次fsync写入追加到appendonly.aof文件中。一般我们配置redis.conf中的一下指令：

AOF和RDB模式我们一般在生产环境都会打开，一般而言，redis服务挂掉后进行重启会优先家在aof中的文件。

当启动一个slave node的时候，它会发送一个PSYNC命令给master node,如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据;否则如果是slave node第一次连接master node，那么会触发一次full resynchronization;
　　开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。
　　slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。

master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制,但是如果没有找到对应的offset，那么就会执行一次resynchronization。

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了，可以有如下配置：

slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

在redis.conf配置文件中，上面的参数代表至少需要3个slaves节点与master节点进行连接，并且master和每个slave的数据同步延迟不能超过10秒。一旦上面的设定没有匹配上，则master不在提供相应的服务。

sdown达成的条件很简单，如果一个哨兵ping一个master，超过了 is-master-down-after-milliseconds 指定的毫秒数之后，就主观认为master宕机
　　sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了 quorum 指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机

如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master
　　
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个slave来做切换，这个slave还得得到majority哨兵的授权，才能正式执行切换；

（2）SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态
（3）SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致

4.3.2 slave的永久下线

让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行.

redis的集群模式为了解决系统的横向扩展以及海量数据的存储问题，如果你的数据量很大，那么就可以用redis cluster。
　　redis cluster可以支撑N个redis master,一个master上面可以挂载多个slave，一般情况我门挂载一个到两个slave，master在挂掉以后会主动切换到slave上面，或者当一个master上面的slave都挂掉后，集群会从其他master上面找到冗余的slave挂载到这个master上面，达到了系统的高可用性。

2.1 redis cluster的重要配置

2.2 在三台机器上启动6个redis实例

将上面的配置文件，在/etc/redis下放6个，分别为: 7001.conf，7002.conf，7003.conf，7004.conf，7005.conf，7006.conf

每个启动脚本内，都修改对应的端口号

2.3 创建集群

解决办法是 先安装rvm，再把ruby版本提升至2.3.3

使用redis-trib.rb命令创建集群

--replicas: 表示每个master有几个slave

redis-trib.rb check 192.168.31.187:7001 查看状体

3.1 加入新master

以上相同配置完成后，设置启动脚本进行启动；然后用如下命令进行node节点添加：

3.2 reshard一些数据过去

3.3 添加node作为slave

3.4 删除node

Redis持久化的方式有哪些优缺点分别是什么

   持久化的目的主要是做灾难恢复，数据恢复。由于Redis的数据全都放在内存里面，如果Redis挂了，没有配置持久化的话，重启的时候数据会全部丢失。
    突然间，大量的请求过来，缓存全都无法命中，造成缓存雪崩，mysql无法承载大量的请求，造成整个系统崩溃。如果把Redis持久化做好，即使Redis故障了，也能够立即重启，对外提供服务。
Redis持久化分为两种：

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

RDB的优缺点：

AOF的优缺点：

RDB和AOF如何选择？

rdb是Redis DataBase缩写
功能核心函数rdbSave(生成RDB文件)和rdbLoad（从文件加载内存）两个函数

Aof是Append-only file缩写
每当执行服务器(定时)任务或者函数时flushAppendOnlyFile 函数都会被调用， 这个函数执行以下两个工作
aof写入保存：
WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件
SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。

存储结构:
内容是redis通讯协议(RESP )格式的命令文本存储。

比较：
1、aof文件比rdb更新频率高，优先使用aof还原数据。
2、aof比rdb更安全也更大
3、rdb性能比aof好
4、如果两个都配了优先加载AOF