redis 持久化

redis的高可用：

在集群当中有有一个非常重要的指标，提供正常服务的时间的百分比（365天）99.9%

redis的高可用的含义更加宽泛，正常访问是指标之一，数据容量的扩展，数据的安全性。

在redis当中实现高可用的技术：持久化，主从复制，哨兵模式，cluster集群

持久化：持久化是最简单的高可用方法，主要作用是数据实现备份，也就是把redis缓存在内存中的数据保存到本地的硬盘当中。（冷备份）

redis持久化的方式：

一，RDB持久化：redis在内存中的数据定时保存到磁盘。（自动执行，手动执行）

在指定的时间间隔内，将内存中当前进程中的数据生成快照保存到硬盘（快照持久化）用二进制压缩存储。保存的文件名后缀.rdb。redis启动时，可以直接读取快照文件，实现数据恢复。

rdb的触发机制：

手动机制：save bgsave都可以生成RDB文件。

save创建RDB文件时，redis的主进程将会被阻塞，期间redis将无法进行读写操作，直到rdb文件创建完成为止。（生成中不用，大忌）

在库save

会在/var/lib/redis/6379/目录下生成一个dump.rdb文件

把文件复制到opt，目录下

在库中flushall清除

再退出exit

冷备份要先关闭服务 /etc/init.d/redis_6379 stop

把opt目录下的文件复制到/var/lib/redis/6379/

再打开服务/etc/init.d/redis_6379 restart

就恢复了

bgsave面试中问有那些持久化方式 rdb就说bgsave方式

父进程会提供fork机制创建一个子进程，子进程的创建过程中，父进程会阻塞，子进程创建完毕之后，主进程会解除阻塞。由子进程来

fork创建子进程是核心

bgsave就是主从复制的机制

自动触发：

配置文件vim /etc/redis/6379.conf

save 900 1

900秒 当时间到900秒时，redis的数据至少发生了一次变化，就执行bgsave

save 300 10

300秒 当时间到300秒时，redis的数据至少发生了10次变化，就执行bgsave

save 60 10000

60秒 当时间到60秒时，redis的数据至少发生了10000次变化，就执行bgsave

rdbcompression yes

开启RDB的文件压缩功能，在高并发场景建议关闭。

保留持久化文件的位置

面试题：生成中变化越多，执行的时间要越短一般120秒内执行了1000保存一次

除了配置文件中的save m n之外

主从复制，从节点执行全量复制操作，直接点会执行bgsave，把rdb文件传送2给从节点

关闭进程。shutdown之后，会自动执行rdb的持久化。

启动时加载失败：

rdb文件被损坏，日志中会打印错误，redis会拒绝启动。

redis-check-rdb 修复RDB的持久化文件

二，AOF持久化：redis的操作日志，以追加的方式写入一个AOF的文件，类似于mysql的binlog（生产中常用的）

aof持久化是将redis的每一次读 写 删除命令记录到一个单独的.aof为结尾的文件。查询操作由主进程记录。当redis重启时，再次执行AOF文件中的命令来恢复数据。

AOF的实时性更好，也是主流的持久化方案。

开启aof持久化功能

aof-load-truncated yes

用于判断AOF文件，如果被截断时的行为。

yes：发现被截断（写入过程中查询异常，导致文件未能完全写入。），redis会尽可能的恢复文件中的数据，redis会继续运行

no：发现截断，redis将拒绝启动。

数据的完整性比较高，no

注重数据服务器的可用性 yes，可用性比较重要。

面试题：出现截断怎么办？

看你的要求，是注重完整性还是可用性最好是用yes，可用性比较好

在文件中根据位置点进行恢复。

rdb是redis的默认持久化文件，但是一旦开启aof持久化，那么redis会以aof持久化文件作为最高优先级。

AOF的重写功能：

1，随着时间增长，AOF文件当中的数据也会不断的增加。AOF的文件也会越来越大。过大的AOF的文件不仅仅会响应服务器的运行，也会导致数据恢复的时间过长。

文件重写是值定期的重写AOF文件，减小AOF文件的体积。AOF重写是把redis进程内的数据，转化为写的命令。同步到新的AOF文件当中（不会额外的生成一个新的文件，只是在源内容中进行压缩）。不会对原有的AOF文件进行任何读写的操作。

*文件重写虽然是AOF持久化强烈推荐的，但不是必须的。没有重写并不影响redis启动时读取数据。在实际工作中，会关闭自动的文件重写。通过定时任务来完成。

AOF同步文件的策略三种方式

appendfsync always:写入过程中，立刻调用redis系统的fsync操作写入到AOF文件，如果每次写入都执行同步，硬盘的性能有瓶颈。硬盘的寿命也会单独降低。

appendfsnc no：写入操作调用系统的write操作，不对AOF文件进行同步，操作系统来同步，同步周期30秒，文件同步的实际不可控，缓冲区会挤压大量数据，数据的安全也无法保证

appendfsnc everysec：命令写入，调用write操作，write操作结束后，线程会返回。FSYNC同步文件操作由专门的线程，每秒调用一次。这是一个折中策略，是性能和安全性的平衡，是redis的默认配置。也是推荐配置。

重写的触发条件？

1，手动触发

redis-cli bgrewriteaof

生产中可以配合定时任务

设置定时任务要关默认配置

auto-aof-rewrite-percentage 0

2，自动触发

配置文件

auto-aof-rewrite-percentage 100

文件的读写超过基准的百分比，默认值就是100，我觉得大小超过两倍时，执行bgrewriteaof。设置为0，禁用自动触发。

100M 200M 400M

auto-aof-rewrite-min-size 64mb

文件大于基准值，才会重写。这个值是AOF文件重写的最小值。避免开始启动redis后，我忘记太小，然后频繁的进行重写。

AOF重写为什么能够压缩文件：

1，重写过程中，过期的数据不会写入文件

2，无效的命令不再写入文件，数据被重复设置 set test=1 set test 2,删除的数据也不会写入 set test 1 del test

（作业）

3，多条命令合并成一个。sadd test v1 sadd test v2 sadd test v3 sadd test v1 v2 v3

重写之后，AOF的文件命令减少了，空间也少了，恢复速度也增加了。（重写不是必须的。也就是重启redis速度慢一点）

总结：

RDB和AOF之间的有缺点：

RBD的优点：文件体积小，网络传输速度很快，适合全量复制。恢复速度也比AOF要快。

缺点：在于数据快照的方式，做不到实时的持久化，数据如此重要，不能够容忍丢失的。另外一点RDB满足特定的格式，兼容性很差。

老版本的RDB不支持新版本。（redis的版本一定要一致）5.0.7

AOF优点：秒级持久化。兼容性好（读写操作都是文本格式保存命令行，通用）。

缺点：文件大，恢复速度慢。AOF持久化需要平凡的向磁盘写入数据，磁盘的I/O压力也很大。对redis的性能也会有一定的影响。

redis的持久化也算是高可用的一种，通过备份文件来恢复数据，冷备份。

rdb ：save线上禁用。bgsave：

AOF（主流 实时）写入的是操作的命令，除了差set del 会记录 get select不记录。实时记录，恢复方式类似于MySQL的bin-log

重写：推荐但是不必须的。重写也是主进程场景一个子进程，在过程中生产的数据以及同步策略都会写入到AOF文件中。