RDB 文件的优势和劣势

一、优势

1.RDB 是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。

2.生成RDB 文件的时候，redis 主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO 操作。

3.RDB 在恢复大数据集时的速度比AOF 的恢复速度要快。

二、劣势

1、RDB 方式数据没办法做到实时持久化/秒级持久化。因为bgsave 每次运行都要执行fork 操作创建子进程，频繁执行成本过高。

2、在一定间隔时间做一次备份，所以如果redis 意外down 掉的话，就会丢失最后一次快照之后的所有修改（数据有丢失）。

如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF 方式进行持久化。

AOF

Append Only File

AOF：Redis 默认不开启。AOF 采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改Redis 数据的命令时，就会把命令写入到AOF 文件中。

Redis 重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。

AOF 配置

配置文件redis.conf

# 开关
appendonly no
# 文件名
appendfilename "appendonly.aof"

AOF 文件的内容（vim 查看）：

问题：数据都是实时持久化到磁盘吗？

由于操作系统的缓存机制，AOF 数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。什么时候把缓冲区的内容写入到AOF 文件？

参数

说明

appendfsync everysec

AOF 持久化策略（硬盘缓存到磁盘），默认everysec
 no 表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；
 always 表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低；
 everysec 表示每秒执行一次fsync，可能会导致丢失这1s 数据。通常选择everysec ，
兼顾安全性和效率。

问题：文件越来越大，怎么办？

由于AOF 持久化是Redis 不断将写命令记录到AOF 文件中，随着Redis 不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及AOF 恢复要求时间越长。

例如set leon 666，执行1000 次，结果都是leon=666。

为了解决这个问题，Redis 新增了重写机制，当AOF 文件的大小超过所设定的阈值时，Redis 就会启动AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。

可以使用命令bgrewriteaof 来重写。

AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF 文件。

# 重写触发机制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

参数	说明
auto-aof-rewrite-percentag e	默认值为100。aof 自动重写配置，当目前aof 文件大小超过上一次重写的aof 文件大小的百分之多少进行重写，即当aof 文件增长到一定大小的时候，Redis 能够调用bgrewriteaof 对日志文件进行重写。当前AOF 文件大小是上次日志重写得到AOF 文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size	默认64M。设置允许重写的最小aof 文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。

问题：重写过程中，AOF 文件被更改了怎么办？

另外有两个与AOF 相关的参数：

参数	说明
no-appendfsync-on-rewrite	在aof 重写或者写入rdb 文件的时候，会执行大量IO，此时对于everysec 和always 的aof 模式来说，执行fsync 会造成阻塞过长时间，no-appendfsync-on-rewrite 字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。设置为yes 表示rewrite 期间对新写操作不fsync, 暂时存在内存中,等rewrite 完成后再写入，默认为no，建议修改为yes。Linux 的默认fsync 策略是30 秒。可能丢失30 秒数据。
aof-load-truncated	aof 文件可能在尾部是不完整的，当redis 启动的时候，aof 文件的数据被载入内存。重启可能发生在redis 所在的主机操作系统宕机后，尤其在ext4 文件系统没有加上data=ordered 选项，出现这种现象。redis 宕机或者异常终止不会造成尾部不完整现象，可以选择让redis 退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof 文件被导入的时候，会自动发布一个log 给客户端然后load。如果是no，用户必须手动redis-check-aof 修复AOF 文件才可以。默认值为yes。

AOF 数据恢复

重启Redis 之后就会进行AOF 文件的恢复。

AOF 优势与劣势

优点：

1、AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失1 秒的数据而已。

缺点：

1、对于具有相同数据的的Redis，AOF 文件通常会比RDF 文件体积更大（RDB存的是数据快照）。

2、虽然AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。在高并发的情况下，RDB 比AOF 具好更好的性能保证。

两种方案比较

那么对于AOF 和RDB 两种持久化方式，我们应该如何选择呢？

如果可以忍受一小段时间内数据的丢失，毫无疑问使用RDB 是最好的，定时生成RDB 快照（snapshot）非常便于进行数据库备份，并且RDB 恢复数据集的速度也要比AOF 恢复的速度要快。

否则就使用AOF 重写。但是一般情况下建议不要单独使用某一种持久化机制，而是应该两种一起用，在这种情况下,当redis 重启的时候会优先载入AOF 文件来恢复原始的数据，因为在通常情况下AOF 文件保存的数据集要比RDB 文件保存的数据集要完整。

RDB 文件的优势和劣势相关推荐

Mono for Android 优势与劣势
Mono for Android 优势与劣势最近有兴趣了解一下Mono for Andriod,也就是使用.NET平台来开发Andriod程序.Mono for Android API 几乎映射标准 ...
JSP的优势与劣势浅析
本文简单介绍了JSP技术,并对JSP的优势与劣势进行了简单的分析.JSP页面由HTML代码和嵌入其中的Java代码所组成. JSP(JavaServer Pages)是由Sun Microsystem ...
使用框架开发的优势和劣势
http://www.gbin1.com/technology/jquery/prosconsframeworks/有些时候可能大家都会问自己,如果有新的方式缩短工作时间为什么还需要每天做重复的事情呢 ...
JSP的优势和劣势与php的比较
一 jsp的优势与劣势由于JSP页面的内置脚本语言是基于Java编程语言的,而且所有的JSP页面都被编译成为Java Servlet,JSP页面就具有Java技术的所有好处,包括健壮的存储管理和 ...
JSP的优势和劣势与php的比较
一 jsp的优势与劣势由于JSP页面的内置脚本语言是基于Java编程语言的,而且所有的JSP页面都被编译成为Java Servlet,JSP页面就具有Java技术的所有好处,包括健壮的存储管理和 ...
Btrfs 与 Ext4 - 功能、优势和劣势
文件系统控制从存储设备存储和检索数据的位置.方式和时间.日常系统进程需要一个高效的文件系统.Linux 内核支持多种文件系统.最常用的是 Ext4.Btrfs.XFS 和 ZFS,这是 2018 年发 ...
redis 生成dump.rdb文件
1.使用CRT远程登录装有bairedis的机器. 2.登录redis,执行命令bairedis-cli -h 127.0.0.1 -p 6379,其中127.0.0.1为redis的ip地址,637 ...
python编程语言能干什么-python编程语言的优势与劣势--python能干啥
首先先发表小编的观点吧嘿嘿:python并不适合作为第一编程语言,但是第二编程语言的首选 (哥哥们先别喷我,且听我慢慢说来~~~) 先解释一下啥是第一第二编程语言吧: 通常从事开发的程序员都会学不止一 ...
Redis集群CentOS系统配置企业级数据备份方案以及数据恢复的操作(在开启AOF功能下恢复冷备RDB文件数据，保持AOF和RDB双开情况下恢复数据及错误的数据恢复步骤详解)
1. 设置每小时保存一份 /var/redis/6379/dump.rdb 文件至指定目录(我这边存放在 /usr/local/redis_backup 目录下),并删除48小时前的文件. 为 ...

RDB 文件的优势和劣势

RDB 文件的优势和劣势相关推荐

最新文章

热门文章