nosqlredis高级篇

RDB&AOF

本文字数: 1.6k 阅读时长: 5 分钟
阅读次数次

2 RDB持久化

2.1 是什么？

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里（内存的东西不保存关机就没了，为什么redis开机还有数据？因为内存中的数据集快照被写进了磁盘，开机从磁盘加载回内存。）

2.2 相关配置

1
2
3
4
5
6
7
8
redis.conf的SNAPSHOTTING
after 900 seconds if at least 1 key changed
after 300 seconds if at least 10 keys changed
after 60 seconds if at least 10000 keys changed
save 900 1
save 300 10
save 60 10000
save + second + changes

2.3 执行原理（fork）

  • 1.redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
    rdb保存的是dump.rdb文件，比如每隔5分钟，我们存一份5条记录，又过了5分钟我们存一份20条记录，这时候我们就用20条替换上一条新替换旧
  • 2.整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
  • 3.如果需要进行大规模数据恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
  • 4.RDB的缺点是最后一次持久化后的数据可能丢失。
    （准备备份的时候这块儿出故障了，就没有备份）

redis为了避免上下文切换的时间消耗，用单线程加epoll的方式处理请求，在save的时候会阻塞，这时redis不能接受的，所以必须用bgsave复制一份子进程作为工具进行rdb

fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程 和gihub的fork类似，系统有时候本来就慢紧张，还做备份，这时候fork一份就会崩溃

2.4 如何触发

  • 1.配置文件中默认的快照配置
    冷拷贝后重新使用（主机和备份机器一定是两台）可以cp dump.rdb dump_new.rdb
  • 2.命令save或bgsave
    save:可以迅速生成dump.rdb，save的时候会只管保存其它的全部阻塞，在save的时候无法进来新的数据
    bgsvae:redis会在后台异步进行快照操作，快照同时还可以响应客户端的需求，可以通过lastsave命令获取最后一次成功执行快照的时间
  • 3.执行flushall和shutdown也会产生dump.rdb
    但dump.rdb这时候是空的，没用

2.5 如何恢复

将备份文件dump.rdb移动到redis安装目录并启动服务即可（config get dir获取当前路径）

2.6 优缺分析

  • 优点

1.适合大规模的数据恢复
2.对数据的完整性和一致性要求不高
（比如你突然kill redis）这样当前两分钟的数据就丢失了，没有备份进去

  • 缺点

1.在一定时间间隔做数据备份，如果redis意外down掉，就会丢失最后一次快照后的所有修改
2.Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。

3.AOF持久化

Append Only File
新技术的出现一定会弥补老技术的不足

3.1 是什么？

以日志的形式来记录每个写操作，将redis执行过的所有指令记录下来（读操作不做记录），只许追加文件，但不改写文件，redis启动之初会读取该文件重构数据，换言之，redis重启的话就根据日志文件的内容将写指令从头到尾执行一遍以完成数据恢复工作。

3.2 相关配置

1
2
3
4
5
6
# redis.conf
appendonly yes
appendsync
1.always 同步持久化,每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好.
2.Everysec 出厂默认,异步操作,每秒记录,如果一秒内宕机,会有数据丢失
3.no

3.3 AOF恢复

  • 1.正常恢复
    启动:设置yes 修改默认appendonly no,改为yes
    将有数据的aof文件复制一份保存到对应目录config get dir
    恢复:重启redis然后重新加载

  • 2.异常恢复
    启动
    备份被写坏的AOF文件
    修复:redis-check-aof –fix appendonly.aof进行修复
    恢复:重启redis加载

3.5 AOF重写

AOF有个缺点:一直往里面写越写越多,越来越大
这时候我们就需要压缩精简,而AOF已经提供好了精简算法

3.5.1 是什么

新增重写机制防止AOF越写越大,当AOF文件大小超过设定的阀值,redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof

3.5.2 重写原理

AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据,每条记录有一条的set语句,重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写进了一个新的aof文件,这点和快照很相似.

3.5.3 触发机制

redis会记录上次重写时的AOF大小,默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发.
设置重写的基准值和百分比
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64MB
(大公司肯定不止64MB)3G是起步

3.6 相较RDB的优劣

优势:每秒同步,每修改同步,不同步
劣势:相同数据集的数据AOF文件要远大于rdb文件,恢复速度远远慢于rdb文件,aof运行效率要慢于rdb,每秒同步策略较好,不同步频率和rdb相同.

分享到