redis数据持久化

最后更新于:2022-04-01 21:50:00

## 两种持久化方法的基本原理 * RDB持久化:将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化 * AOF定义:以日志的形式记录每个操作,将Redis执行过的所有指令全部记录下来(读操作不记录),只许追加文件但不可以修改文件.Redis启动时会读取AOF配置文件重构数据,换句话说,就是Redis重启就会根据日志内容从头到尾执行一次来完成数据的恢复工作。 >一.RDB与AOF同时开启 默认先加载AOF的配置文件 二.相同数据集,AOF文件要远大于RDB文件,恢复速度慢于RDB 三.AOF运行效率慢于RDB,但是同步策略效率好,不同步效率和RDB相同 ### RDB持久化基本配置实现 1. RDB持久化(以快照的方式) 策略(默认):   save 900 1 (15分钟变更一次)   save 300 10 (5分钟变更10次)   save 60 10000 (1分钟变更1万次) 2. RDB默认配置文件名称:   dbfilename dump.rdb > 如果关闭RDB持久化方式,就把配置注释掉 ### AOF持久化配置实现 1. 表示是否开启AOF持久化:   appendonly yes(默认no,关闭) 2. AOF持久化配置文件的名称:   appendfilename "appendonly.aof" 3. AOF持久化策略(默认每秒):   appendfsync always (同步持久化,每次发生数据变更会被立即记录到磁盘,性能差但数据完整性比较好)   appendfsync everysec (异步操作,每秒记录,如果一秒钟内宕机,有数据丢失,性能与数据安全折中,推荐)   appendfsync no (不同步) 4. AOF配置文件损坏修复方法:   进入redis安装路径 执行 redis-check-aof --fix AOF配置文件名称 5. AOF的Rewrite(重写) : * 定义:AOF采用文件追加的方式持久化数据,所以文件会越来越大,为了避免这种情况发生,增加了重写机制 * 当AOF文件的大小超过了配置所设置的阙值时,Redis就会启动AOF文件压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof * 原理:当AOF增长过大时,会fork出一条新的进程将文件重写(也是先写临时文件最后rename),遍历新进程的内存数据,每条记录有一条set语句。 * 重写AOF文件并没有操作旧的AOF文件,而是将整个内存中的数据内容用命令的方式重写了一个新的aof文件(有点类似快照) * 触发机制:Redis会记录上次重写时的AOF文件大小,默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发 ```      auto-aof-rewrite-percentage 100 (一倍)      auto-aof-rewrite-min-size 64mb ``` ## RDB与AOF的选择: * 做备份:当数据量大,且对恢复速度有要求,并且数据的一致性要求不高的话,可以只使用RDB * 只做缓存:不用开启任何的持久化方式 * 两者都开启的建议:RDB数据不实时,同时使用两者时服务器只会找AOF文件. > 可不可以只使用AOF?作者建议不要,因为RDB更适合备份数据库(AOF在不断变化,不好备份) ## 优化: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/ecc9a3b44bb80ba3da0f345486d0a875_966x270.png) * 建议一种使用方式:redis主从结构,只在slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1 这条规则 * 在高并发大数据量写的情况下,不建议配置自动保存RDB。在RDB保存时会fock创建一个子进程,此操作过程父进程会阻塞! ## 参考    [redis数据丢失及解决](http://blog.csdn.net/xiangliangyu/article/details/8165644)
';