前引

        1、redis持久化的文件是什么

                dump.rdb appendonly.aof

        2、这两中文件有什么异同

                save 秒 1

                alaways everysec no

        3、文件存放的位置

                dir ./

        4、默认的存放位置:命令启动的地方

                dir 自定义的路径

                rdb 和aof 文件 存放在同一个路径下面

        5、rdb文件默认备份的策略是什么，如何修改这个策略

                        save 600 1

        6、备份的原理是什么

                Redis备份的原理是通过将Redis数据库中的数据持久化到磁盘上，从而实现数据的备份和恢复。

        7、aof持久化的流程

        AOF持久化的流程主要包括以下几个步骤：

1. 在Redis服务器启动时，会根据配置的持久化策略，打开或者创建一个AOF文件，用于记录所有修改数据库的指令。

2. 当客户端对数据库进行增删改操作时，Redis会将这些操作转换成相应的指令，并追加到AOF文件的末尾。

3. Redis在执行完每条写命令后，会调用fsync()函数，强制将AOF缓冲区的内容写入到磁盘上。这样会导致性能稍微有些下降，但可以更好地保证数据不丢失。

4. 当AOF文件变得太大时，Redis会自动触发AOF重写（AOF Rewrite）操作。AOF重写是指将AOF文件中的历史指令重新生成一份新的AOF文件，并且只保留产生快照后的数据，从而避免了AOF文件的膨胀和无效指令的累积。

5. 在Redis关闭时，也会调用fsync()函数，将最后一次操作的指令保存到AOF文件中。

        通过AOF持久化方式，Redis可以在重启后，通过执行AOF文件中的指令，恢复出先前的数据库状态。虽然相比RDB持久化方式，AOF持久化的文件较大，但是它可以保证更高的数据完整性和可靠性，并且可以提供更好的读写性能。

主从复制的原理

一 Redis持久化之RDB

                Redis 提供了2个不同形式的持久化方式。

                RDB（Redis DataBase）

                AOF（Append Of File）

        1.RDB是什么

                在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

        2. 备份是如何执行的

                Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

        3.Fork

                Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

                在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”

                一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

        4. RDB持久化流程

        5. dump.rdb文件

                在redis.conf中配置文件名称，默认为dump.rdb

                文件在哪里启动这个文件就在哪里

        6. 配置位置

                rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下

                redis.conf：

                dir "/myredis/"

        7. 如何触发RDB快照；保持策略

                7.1 配置文件中默认的快照配置时间间隔

                7.2 命令save bgsave

                save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。

                bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。

                可以通过lastsave 命令获取最后一次成功执行快照的时间

                7.3 flushall命令

                执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

                7.4 SNAPSHOTTING快照

                7.5. Save

                        格式：save 秒 写操作次数

                        RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，

                        默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。

                禁用

                        不设置save指令，或者给save传入空字符串

                        7.6. stop-writes-on-bgsave-error

                        当Redis无法写入磁盘的话(磁盘已满)，直接关掉Redis的写操作。推荐yes.

                        7.7 rdbcompression 压缩文件

                        对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会进行压缩。

如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.

                        7.8. rdbchecksum 检查数据的完整性

                        在存储快照后，还可以让redis来进行数据校验，如果数据已经损坏就不需要再进行持久化的操作，这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

推荐yes.

                        7.9. rdb的备份

                                先查询rdb文件的目录

                                将*.rdb的文件拷贝到别的地方

                                rdb的恢复

                                关闭Redis

                                先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb

                                启动Redis, 备份数据会直接加载

                        7.10. 优势

                                适合大规模的数据恢复

                                对数据完整性和一致性要求不高更适合使用

                                节省磁盘空间

                                恢复速度快

                        7.11 劣势

                                Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

                                虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

                                在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

二 Redis持久化之AOF

        2.1. AOF（Append Only File）

                2.1.1. 是什么

                        以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

                2.1.2. AOF持久化流程

                        （1）客户端的请求写命令会被append追加到AOF缓冲区内；

                        （2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

                        （3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

                        （4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

                2.1.3. AOF默认不开启

                        可以在redis.conf中配置文件名称，默认为 appendonly.aof

                        AOF文件的保存路径，同RDB的路径一致。

                2.1.4. AOF和RDB同时开启，redis听谁的？

                        AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

                2.1.5. AOF启动/修复/恢复

                        AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

                正常恢复

                        修改默认的appendonly no，改为yes

                        将有数据的aof文件复制一份保存到对应目录

                        恢复：重启redis然后重新加载

                异常恢复

                        修改默认的appendonly no，改为yes

                        如遇到AOF文件损坏，通过

                                /usr/redis/bin/redis-check-aof --fix 文件的位置/appendonly.aof进行恢复

                备份被写坏的AOF文件

                恢复：重启redis，然后重新加载

                2.1.6. AOF同步频率设置

                        appendfsync always

                        始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

                        appendfsync everysec

                        每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

                        appendfsync no

                        redis不主动进行同步，把同步时机交给操作系统。

                2.1.7. Rewrite压缩

                        1是什么：

                                AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

                        2重写原理，如何实现重写

                                AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

                        no-appendfsync-on-rewrite：

                        如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

                        如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

                        触发机制，何时重写

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）

->40m 80

auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,

如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

                        3、重写流程（背）

                        （1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

                        （2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。

                        （3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

                        （4）1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

                        （5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。