为什么要持久化Redis
redis的数据是存放在内存中,而内存中的数据断电即失,如果服务器宕机后恢复了,但redis数据却没了,我们不可能在去把数据一行行再重新写入,所有就有了redis持久化,将redis的数据存入在磁盘中,当服务器宕机时,保存在磁盘中数据依然保留,我们可以随时恢复数据。
Redis持久化策略
在适当的时机采用适当的手段把内存中的数据持久化到磁盘中,每次redis服务启动时,都可以把磁盘上的数据再次加载到内存中。
RDB策略
在指定时间间隔内,redis服务执行指定次数的写操作,会自动触发一次持久化操作。
save <seconds><changes> : 配置持久化策略
save 3600 1 :3600s 内至少有1个key更改进行持久化操作
save 300 100 :300s 内至少有100个key更改进行持久化操作
save 60 10000 :60s 内至少有100个key更改进行持久化操作
dbfilename: 配置redis RDB持久化数据存储的文件
dir: 配置redis RDB持久化文件所在目录
AOF策略
采用操作日志来记录进行的每一次写操作,每次redis服务启动时,都会重新执行一遍操作日志的指令。
appendonly: 配置是否开启AOF策略
appendfsync: 配置同步频率everysec
appendfsync always:每修改同步,每一次发生数据变更都会持久化到磁盘上,性能较差,但数据完整性较好
appendfsync everysec: 每秒同步,每秒内记录操作,异步操作,如果一秒内宕机,有数据丢失
appendfsync no:不同步
appendfilename:配置操作日志文件
RDB和AOF策略比较
RDB策略优点与缺点
优点
- 恢复数据快,如果有大量数据需要恢复,RDB方式要比AOF方式恢复速度要快。
- 性能好, RDB可以最大化Redis性能,父进程做的就是fork子进程,然后继续接受客户端请求,让子进程负责持久化操作,父进程无需进行IO操作。
- 备份数据占用内存小,RDB是一个非常紧凑(compact)的文件,它保存了某个时间点的数据集,非常适合用作备份,同时也非常适合用作灾难性恢复,它只有一个文件,内容紧凑,通过备份原文件到本机外的其他主机上,一旦本机发生宕机,就能将备份文件复制到redis安装目录下,通过启用服务就能完成数据的恢复。
缺点
- 需要内存大,RDB持久化是使用子进程,它会占用与父进程相同的内存,且每次RDB持久化时,父进程都会fork一个子进程,由子进程来进行实际的持久化操作,如果数据集庞大,那么fork出子进程的这个过程将是非常耗时的,就会出现服务器暂停客户端请求,将内存中的数据复制一份给子进程,让子进程进行持久化操作。
- RDB这种持久化方式不太适应对数据完整性要求严格的情况,因为,尽管我们可以用过修改快照实现持久化的频率,但是要持久化的数据是一段时间内的整个数据集的状态,如果在还没有触发快照时,本机就宕机了,那么对数据库所做的写操作就随之而消失了并没有持久化本地。
AOF策略优点与缺点
优点
- AOF文件是一个只进行追加操作的日志文件,对文件写入不需要进行seek,即使在追加的过程中,写入了不完整的命令(例如:磁盘已满),可以使用redis-check-aof工具可以修复。
- Redis可以在AOF文件变得过大时,会自动地在后台对AOF进行重写:重写后的新的AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的,因为Redis在创建AOF文件的过程中,会继续将命令追加到现有AOF文件中,即使在重写的过程中发生宕机,现有的AOF文件也不会丢失。一旦新AOF文件创建完毕,Redis就会从旧的AOF文件切换到新的AOF文件,并对新的AOF文件进行追加操作。
- AOF文件有序地保存了对数据库执行的所有写入操作。这些写入操遵循Redis协议的格式保存,易于对文件进行分析;例如,如果不小心执行了FLUSHALL命令,但只要AOF文件未被重写,通过停止服务器,移除AOF文件末尾的FLUSHALL命令,重启服务器就能达到FLUSHALL执行之前的状态。
缺点
- AOF持久的文件占用内存大。
- 效率较低,一般情况下,每秒同步策略效果较好。不使用同步策略的情况下,AOF与RDB速度一样快。
RDB与AOF如何选择
RDB效率高,占用内存低,但持久化有延迟,会有丢失数据的风险。
AOF效率相对低,占用内存大,但持久化方案多,最多只会丢失1s的数据。
具体如何选择,需要根据使用环境,建议两种持久化策略同时使用。