1.RDB
快照读
1、是什么 在指定的时间间隔内将内存中的数据集快照(snapshot)进磁盘里，恢复的时候是将快照文件读到磁盘里。
2、Fork
1）、fork的作用是复制一个与当前进程一样的进程。新进程的所有数据都与原进程一致，并作为原进程的子进程。
2）、Redis 会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,
在用这个临时文件替换上次持久化好的文件;
3、RDB 保存的是dump.rdb文件（默认保存位置）
4、如何触发:
1）、redis.conf配置文件中，有触发机制（SNAPSHOTTING）,共三种，默认900 1,300 10,60 10000
保存900 1 ＃900 秒内如果超过 1 个 Key 被修改，则启动快照保存
保存300 10 ＃300 秒内如果超过 10 个 Key 被修改，则启动快照保存
保存60 10000 ＃60 秒内如果超过 10000 个 key 被修改，则启动快照保存
2）、命令触发 ：save、bgsave、flushall。
区别：
a：save 只管保存，执行此命令时，停止IO操作，会造成数据阻塞。
b：bgsave redis 在后台异步进行快照操作，快照同时响应客户端请求，通过 lastsave 命令获取最后一次成功执行快照的时间。
c：执行flushALl命令，也会产生dump.rdb文件，但是文件里是空的没有意义。
5、恢复备份文件：将备份文件(dump.rdb)移动到redis安装目录并启动服务即可;
6、优点：
1）、适合大规模的数据恢复，是一个紧凑压缩的二进制文件，Redis加载RDB恢复数据远远快于AOF的方式。
2）、对数据的完整性和一致性要求不高
总结：
会生成多个数据文件，每个数据文件分别都代表了某一时刻 Redis 里面的数据，这种方式，很适合做冷备，完整的数据运维设置定时任务，定时同步到远端的服务器，比如阿里的云服务，这样一旦线上挂了，你想恢复多少分钟之前的数据，就去远端拷贝一份之前的数据就好了。
RDB 对 Redis 的性能影响非常小，是因为在同步数据的时候他只是 fork 了一个子进程去做持久化的，而且他在数据恢复的时候速度比 AOF 来的快。
缺点：
1）、RDB 模式是在一定间隔时间做一次备份，如果 redis 意外 down 掉，会丢失最后一次快照之后修改的所有数据
2）、内存变大，fork 的时候，内存中的数据被克隆了一份，需要考虑2倍的膨胀性。
总结：
RDB 都是快照文件，都是默认五分钟甚至更久的时间才会生成一次，这意味着你这次同步到下次同步这中间五分钟的数据都很可能全部丢失掉。AOF 则最多丢一秒的数据，数据完整性上高下立判。
7、停止：redis-cli config set save “”
2.AOF
当前读
1、是什么 以日志的形式来记录每个操作，将redis执行过的每个 “写” 命令记录下来 (读操作不记录)，不可以改写文件，可以追加redis 在启动的时候，会读取该文件重新构建数据库。
2、文件信息
＃开启AOF持久化存储方式
a、默认文件名：appendonly.aof
b、配置位置：将 redis.config 文件中的 appendonly no 改为 yes.(默认是no)
3、AOF持久化存储方式参数说明
1）、每修改同步(appendfsync always):同步持久化、收到写命令后就立即写入磁盘，效率最差，效果最好
2）、每秒同步(appendfsync everysec):异步操作，每秒记录，如果1秒内宕机，有数据丢失 [生产常用此种]
3）、不同步(appendfsync no) 从不同步：完全依赖操作系统，效率最佳，效果没法保证；
4、修复文件
redis-check-aof —fix appendonly.aof(注意是 —fix),之后重启redis然后在重新加载。
修复原理：redis-check-aof —fix 此命令会将文件中不符合规则的语法删掉。
5、rewrite 重写机制:
1）、是什么
避免出现文件越来越大的情况，新增的重写机制（AOF采用文件追加方式），当AOF文件大小超过设定的阈值，redis启动AOF文件的内容压缩，只保留可以恢复数据的最小指令（bgrewriteof命令）
2）、触发机制
redis 会记录上次重写是的 AOF 大小，当 AOF 文件是上次 rewrite 后大小的一倍，且文件大小大于64M时触发。
(redis.conf默认重写大小是64M，一般公司生产配置3G)
3）、重写的原理
a：创建新文件
AOF 文件持续增长过大时（文件追加），会 fork 出一个新进程将文件重写（先写一个临时文件，再将此文件rename），遍历新进程内存中的数据，记录每个写操作。重写的 aof 文件没有读取旧文件，而是将内存中的数据重新写进写的 aof 文件中。
b：同步数据
在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新 AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新AOF 文件的末尾，使得新旧两个 AOF 文件所保存的数据库状态一致。最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作
6、优缺点
优点：
可以实时持久化。
总结：
RDB 五分钟一次生成快照，但是 AOF 是一秒一次去通过一个后台的线程 fsync 操作，那最多丢这一秒的数据。AOF 在对日志文件进行操作的时候是以 append-only 的方式去写的，他只是追加的方式写数据，自然就少了很多磁盘寻址的开销了，写入性能惊人，文件也不容易破损。AOF 的日志是通过一个叫非常可读的方式记录的，这样的特性就适合做灾难性数据误删除的紧急恢复了，比如公司的实习生通过 flushall 清空了所有的数据，只要这个时候后台重写还没发生，你马上拷贝一份AOF 日志文件，把最后一条 flushall 命令删了就完事了。
缺点：
a、对于相同数据集的数据来说，AOF 文件要远远大于 RDB 文件，恢复速度比 RDB 慢
b、AOF 的运行速度要慢于 RDB，每秒同步策略较好。不同步效率和 RDB 相同。
引用
若有收获，就点个赞吧
0 人点赞
