redis 练习笔记（六）--- redis 持久化

一，概述

redis支持RDB和AOF两种持久化机制，持久化可以避免因进程退出而造成数据丢失；

二，RDB

1. rdb概述

RDB持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程，有手动触发和自动触发

2.手动触发

    i. save:

 阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它

  ii. bgsave 

 redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时间很短（微秒级），是save的优化,在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave;

3. RDB文件操作

i. 在配置文件设置rdb文件存放路径

（默认是与redis.conf 同级）

ii.在redis客户端输入bgsave命令 生成dump.rdb 文件

lastsave可以查看bgsave命令是否执行成功，返回的是最后生成.rdb文件的时间戳

iii. 将生成好的dump.rdb备份以下，不要与redis.conf同目录，否则关闭redis服务会默认再执行一次bgsave,覆盖掉刚刚手动生成的dump.rdb

iv.关闭服务器后，将刚刚备份好的dump.rdb与redis.conf同级，再重启redis即可恢复备份数据。

 

优点：

   a.压缩后的二进制文件，适用于备份，全量复制，灾难恢复

   b.RDB恢复数据远快于AOF方式

缺点：

   a. 无法做到实时持久化，每次都要创建子进程，频繁操作成本很高

   b. 保存后的二进制文件，存在rdb文件版本兼容问题 

 

三，AOF

1.AOF概述

针对RDB不适合实时持久化，redis提供了AOF持久化方式来解决

2.AOF操作流程

i.修改redis.conf配置文件，开启AOF,: appendonly yes (默认为no)

(aof默认生成文件名：appendonly.aof)

ii. 客户端做set hset 都会被强制记录到 appendonly.aof，实时同步

iii. 需要备份数据时，dir目录下找到备份文件copy一下

iv. 需要恢复备份数据重启服务器之前将备份aof文件放到redis.conf同级目录即可自动恢复。

3. AOF原理

 

a. 所有的写入命令(set hset)会append追加到aof_buf缓冲区中

b. AOF缓冲区向硬盘做sync同步 

c. 随着AOF文件越来越大，需定期对AOF文件rewrite重写，达到压缩

d. 当redis服务重启，可load加载AOF文件进行恢复

 

redis重启时恢复加载AOF与RDB顺序及流程：

a，当AOF和RDB文件同时存在时，优先加载

b，若关闭了AOF，加载RDB文件

c，加载AOF/RDB成功，redis重启成功

d，AOF/RDB存在错误，redis启动失败并打印错误信息

 

4. AOF配置详解

appendonly	yes/no 是否启用AOF
appendfsync	always   每收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用 everysec 每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐 no    完全依赖os，性能最好,持久化没保证（操作系统自身的同步）
no-appendfsync-on-rewrite	yes/no 正在导出rdb快照的过程中,是否停止同步aof
auto-aof-rewrite-percentage	100   aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size	64mb  aof文件,至少超过64M时,重写

 

 

 

 

http://bbs.dongnaoedu.com/?thread-503.htm