Redis学习12——Redis持久化

一、概述

Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据
不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。

Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或
将二者结合使用。

1.RDB持久化（默认支持，无需配罝）

该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。

2.AOF持久化

该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文
件来重新构建数据库，以保证启动后数据库屮的数据是完整的。

3、 无持久化

我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功
能加强版的memcached 了。

4、 redis可以同时使用RDB和AOF

---

二、RDB

2.1 优势

1.一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完
美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30
天的数据。通过这样的备份策略，一旦系统出现灾难性故陣，我们可以非常容易的进行恢复。

2.对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后
再转移到其它存储介质上

3.性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork (分叉）
出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操
作了。

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

2.2 劣势

1.如果你想保证数据的高可用性，即域大限度的避免数据丢失，那么RDB将不是一个很好的选择
因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2.由于RDB是通过fork 子进程来协助完成数椐持久化工作的，因此，如果当数据集较大时，可能
会导致整个服务器停止服务几百毫秒，其至是1秒钟

2.3 配置说明

查看 redis.conf

 216 #   save "" 217  218 save 900 1 219 save 300 10 220 save 60 10000

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

save 300 10 #每300秒(S分钟)至少有10个key发生变化，则dump内存快照

save 60 10000 #每60秒(1分钟)至少有10000个key发生变化，则dump内存快照

---

保存位置和名称如下

 252 # The filename where to dump the DB 253 dbfilename dump.rdb 254  255 # The working directory. 256 # 257 # The DB will be written inside this directory, with the filename specified 258 # above using the 'dbfilename' configuration directive. 259 # 260 # The Append Only File will also be created inside this directory. 261 # 262 # Note that you must specify a directory here, not a file name. 263 dir ./

保存的名称是：dump.rdb

位置是：redis.conf 同级目录下

---

三、AOF

3.1 优势

1.该机制可以带来更髙的数据安全性，即数据持久性。Redis中提供了3中同步策略，即**每秒同步、
每修改同步和不同步**。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一
旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其
视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效
率上是最低的。

2.由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，
也不会破坏日志文件中己经存在的内容。然而如果我们本次操作只是写入了一半数据就出现，
系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof 工具来帮助
我们解决数据一致性的问题。

3.如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写
入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。
因此在进行rewrite切换时可以更好的保证数据安全性。

4、 AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通
过该文件完成数据的重建。

3.2 劣势

1.对于相同数量的数据集而言，AOF文件通常要大于RDB文件

2、 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高
的，同步禁用策略的效率和RDB—样高效。

3.3 配置AOF

redis.conf

 670 # Please check http://redis.io/topics/persistence for more information. 671  672 appendonly no 673  674 # The name of the append only file (default: "appendonly.aof") 675  676 appendfilename "appendonly.aof"....... 701 # appendfsync always 702 appendfsync everysec 703 # appendfsync no

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

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

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

重写AOF:若不满足重写条件时，可以手动重写，命令：bgrewriteaof

---

redis配置文件详解