一. redis持久化的介绍
Redis持久化是指将内存中Redis数据库的运行数据写入硬盘文件。Redis持久化的意义主要在于故障恢复。例如，如果您部署一个Redis作为缓存，其中可能会有一些重要的数据。如果没有持久性，当redis遇到灾难性故障时，它将丢失所有数据。
Redis持久性的两种方式：
RDB:redis数据库的默认持久化方法，将数据以二进制形式写入文件，每隔一段时间写入一次。AOF:仅附加文件将用户的每个操作记录为文本文件，并在数据恢复时读取文件的摘要。
00-1010 2.1简介
RDB持久性是指在指定的时间间隔内将内存中数据集的快照写入磁盘。它也是默认的持久性方法。这种方法是通过快照将内存中的数据写入二进制文件，默认文件名为dump.rdb。
此配置在redis.conf配置文件中默认为：
保存900 1 # 900秒(15分钟)后，如果至少有一个键发生变化，Redis会自动触发BGSAVE命令创建快照。保存300 10 # 300秒(5分钟)后，如果至少有10个按键发生变化，Redis会自动触发BGSAVE命令创建快照。保存60个10000 # 60秒(1分钟)后，如果至少有10000个按键发生变化，Redis会自动触发BGSAVE命令创建快照。
当条件满足时，当redis需要执行RDB时，服务器将执行以下操作：
Redis调用系统的fork()函数来创建一个子进程。子进程将数据集写入临时RDB文件。当子进程写完临时RDB文件时，redis用新的RDB文件替换旧的RDB文件，并删除旧的RDB文件。redis在快照过程中不会修改RDB文件，只会在快照结束后用新快照替换旧快照，这意味着RDB随时都是完整的。
2.2优点和缺点
# RDB的优势：
1.RDB将生成多个数据文件，每个文件代表redis在某一时刻的数据。这种多数据文件的方法非常适合冷备份。
2.rdb在对外提供读写服务时对redis影响不大，因为redis的主进程只需要一个fork的子进程，就可以让子进程持久化RDB到磁盘io。
3.在恢复大型数据集方面，RDB比AOF更快。
# RDB劣势
1.如果redis想在失败时尽可能少地丢失数据，RDB不如AOF。例如，当快照在1:00拍摄时，它在1:10崩溃，此时将丢失10分钟的数据。
2.每次RDB分叉出一个子进程来执行RDB快照文件时，如果文件非常大，它可能会导致客户端提供的服务暂停几毫秒或几秒钟。
与快照持久性相比，AOF持久性具有更好的实时性，因此成为主流的持久性方案。默认情况下，Redis不会在AOF(仅附加文件)模式下打开持久性。您可以通过仅追加参数在redis.conf配置文件中打开：
仅附录是
Redis的配置文件中有三种不同的AOF持久化方法，分别是：
每次发生数据修改时，Appendfsync总是#写入AOF文件，这将严重降低Redis的速度。appendfsync everysec #每秒同步一次，并向硬盘显示多个写命令。appendfsync no #让操作系统决定何时同步。
为了兼顾数据和写入性能，用户可以考虑appendfsync everysec的选项，它允许Redis每秒同步一次AOF文件，Redis的性能几乎不受影响。而且，即使系统崩溃，用户最多也只会丢失一秒钟内生成的数据。当硬盘忙于写操作时，Redis会优雅地放慢速度，以适应硬盘的最大写速度。
redis中的数据是有一定限制的，所以不可能说redis中的数据无限增长，导致AOF文件无限增长。内存大小是一定的，当达到一定大小时，redis会采用消除策略自动清除内存中的数据。a
OF是存放每条写命令的，所以会不断的增大，当大到一定程度时，AOF会做rewrite操作,rewrite操作就是基于当时redis的数据重新构造一个小的AOF文件，然后将大的AOF文件删除。3.2 优缺点
# AOF的优点： 1. AOF可以更好的保护数据不丢失，一般AOF会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失1秒的数据。 2. AOF以appen-only的模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。 3. AOF日志文件的命令通过非常可读的方式进行记录，这个非常适合做灾难性的误删除紧急恢复，如果某人不小心用flushall命令清空了所有数据，只要这个时候还没有执行rewrite，那么就可以将日志文件中的flushall删除，进行恢复。 # AOF的缺点 1. 对于同一份文件AOF文件比RDB数据快照要大。 2. AOF开启后支持写的QPS会比RDB支持的写的QPS低，因为AOF一般会配置成每秒fsync操作，每秒的fsync操作还是很高的 3. 数据恢复比较慢，不适合做冷备。四. 补充说明
4.1 RDB和AOF选择
不要仅仅使用RDB这样会丢失很多数据。也不要仅仅使用AOF，因为这样会有两个问题，第一通过AOF做冷备没有RDB做冷备恢复的速度快；第二RDB每次简单粗暴生成数据快照，更加健壮。综合AOF和RDB两种持久化方式，用AOF来保证数据不丢失，作为恢复数据的第一选择；用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，可以使用RDB进行快速的数据恢复。4.2 AOF 重写机制
4.2.1 介绍
为了解决AOF文件体积膨胀的问题，Redis提供了AOF重写功能：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。
AOF重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有AOF文件进行任何分析操作。
4.2.2 AOF重写触发的方式
a. 手动触发：用户通过调用bgrewriteaof手动触发
b. 自动触发：如果全部满足的话，就触发自动的AOF重写操作：
没有RDB持久化/AOF持久化在执行，没有bgrewriteaof在进行； 当前AOF文件大小要大于redis.conf配置的auto-aof-rewrite-min-size大小； 当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比（在配置文件设置了auto-aof-rewrite-percentage参数，不设置默认为100%） # redis.conf配置文件中的相关设置 auto-aof-rewrite-percentage 100 # 大于原来的100%就自动重写 auto-aof-rewrite-min-size 64m # 自动重写的最小尺寸