redis的两种持久化策略

Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中 的数据库状态也会消失。所以 Redis 提供了持久化功能！ 持久化过程保存什么

1.将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据 （RDB） 2.将数据的操作过程进行保存,日志形式，存储操作过程，关注点在数据的操作过程（AOF）

        RDB方式 概念: 在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将 快照文件直接读到内存里 RDB手动 save指令

命令 :save 作用 :手动执行一次保存操作 save指令相关配置 #Redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行重新hash，可以降低内存的使用。

当你的使用场景中，有非常严格的实时性需要，不能够接受Redis时不时的对请求有2毫秒的延迟的话，把这 项配置为no。如果没有这么严格的实时性要求，可以设置为yes，以便能够尽可能快的释放内存。

activerehashing yes ##对客户端输出缓冲进行限制可以强迫那些不从服务器读取数据的客户端断开连接，用来强制关闭传输缓慢的 客户端。

对于normal client，第一个0表示取消hard limit，第二个0和第三个0表示取消soft limit， normal client默认取消限制，因为如果没有寻问，他们是不会接收数据的。 client-output-buffer-limit normal 0 0 0 

对于slave client和MONITER client，如果client-output-buffer一旦超过256mb，又或者超过 64mb持续60秒，那么服务器就会立即断开客户端连接。 client-output-buffer-limit slave 256mb 64mb 60

对于pubsub client，如果client-output-buffer一旦超过32mb，又或者超过8mb持续60秒，那么服 务器就会立即断开客户端连接。 client-output-buffer-limit pubsub 32mb 8mb 60

redis执行任务的频率为1s除以hz。

在aof重写的时候，如果打开了aof-rewrite-incremental-fsync开关，系统会每32MB执行一次 fsync。这对于把文件写入磁盘是有帮助的，可以避免过大的延迟峰值。

aof-rewrite-incremental-fsync yes dbfilename dump.rdb 说明：设置本地数据库文件名，默认值为 dump.rdb

经验：通常设置为 dump-端口号.rdb dir 说明：设置存储.rdb文件的路径

经验：通常设置成存储空间较大的目录中，目录名称data rdbcompression yes 说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF算法 压缩

经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨 大） rdbchecksum yes 说明：设置是否进行CRC64算法RDB文件格式校验， 该校验过程在写文件和读文件过程均进行

经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数 据损坏风险 save指令工作原理(单线程任务执行序列)

注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用

bgsave指令 命令 ：bgsave 作用 ：手动启动后台保存操作，但不是立即执行 bgsave指令工作原理 注意： bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方 式，save命令可以放弃使用 Fork Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

RDB自动

配置 ：save second changes

作用 : 满足限定时间范围内key的变化数量达到指定数量即进行持久化

参数 : second：监控时间范围 changes：监控key的变化量

位置 : 在conf文件中进行配置 注意： save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的 save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系 save配置启动后执行的是bgsave操作 RDB优点 RDB是一个紧凑压缩的二进制文件，存储效率较高 RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景 RDB恢复数据的速度要比AOF快很多 RDB节省磁盘空间 RDB缺点 Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能 RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据 Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

AOF方式 概念: AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令 达到恢复数据的目的；与RDB相比可以简单描述为改记录数据为记录数据产生的过程AOF的主要作用是 解决了数据持久化的实时性，目前已经是Redis持久化的主流方式 AOF执行过程 客户端的请求写命令会被append追加到AOF缓冲区内；

AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中； AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量； Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

AOF写数据三种策略(appendfsync) always(每次） 每次写入操作均同步到AOF文件中，数据零误差，性能较低 everysec（每秒） 每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高 在系统突然宕机的情况下丢失1秒内的数据 no（系统控制） 由操作系统控制每次同步到AOF文件的周期，整体过程不可控 AOF相关配置 配置 ：appendonly yes|no 作用 ：是否开启AOF持久化功能，默认为不开启状态 配置 ：appendfsync always|everysec|no 作用 ：AOF写数据策略 配置：appendfilename filename 作用：AOF持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof 配置：dir 作用 ：AOF持久化文件保存路径，与RDB持久化文件保持一致即可 AOF写数据遇到的问题 AOF重写 随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体 积。

AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同 一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录 AOF重写作用 降低磁盘占用量，提高磁盘利用率 提高持久化效率，降低持久化写时间，提高IO性能 降低数据恢复用时，提高数据恢复效率 AOF重写规则 进程内已超时的数据不再写入文件 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令

为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素 AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失） AOF重写方式手动重写bgrewriteaof 自动重写 触发机制，何时重写 Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文 件大于64M时触发;重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担 的,因此设定Redis要满足一定条件才会进行重写= auto-aof-rewrite-min-size 设置重写的基准值，最小文件64MB。达到这个值开始重写。 auto-aof-rewrite-percentage 设置重写的基准值,文件达到100%时开始重写（文件是原 来 重写后文件的2倍时触发） AOF优点: 备份机制更稳健，丢失数据概率更低 可读的日志文本，通过操作AOF稳健，可以处理误操作 AOP缺点： 比起RDB占用更多的磁盘空间 恢复备份速度要慢 总结： 官方推荐两个都启用 如果对数据不敏感，可以选单独用RDB 不建议单独用 AOF，因为可能会出现Bug 如果只是做纯内存缓存，可以都不用