redis--高可用之持久化

redis高可用相关知识

在web服务器中，高可用是指服务器可以正常访问的时间，衡量的标准是在多长时间内可以提供正常服务(99.9%、99.99%、99.999%等等)。

但是在Redis语境中，高可用的含义似乎要宽泛一些，除了保证提供正常服务( 如主从分离、快速容灾技术)，还需要考虑数据容量的扩展、数据安全不会丢失等。
 

redis持久化

1.持久化是什么

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

特点：冷备份（必须要停服务才能数据备份）

2.持久化的两种方式

• RDB持久化：原理是将Reids在内存中的数据库记录定时保存到磁盘上。（定时对内存中的数据生成快照，以文件形式保存在硬盘中）
• AOF持久化（append only file）：原理是将Reids 的操作日志以追加的方式写入文件，类似于MySQL的binlog。（类似于Mysql的二进制日志）（以追加的方式将写和删的操作命令记录到AOF文件中）
   

rdb的持久化

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

rdb的触发机制：

（1）手动触发

save命令和bgsave命令都可以生成RDB文件。

• save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。
• 而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程（即Redis主进程）则继续处理请求。
• bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用。
   

save是使用主进程创建。杜绝使用！！！！！！！

示意图：

（2）自动触发

在自动触发RDB持久化时，Redis 也会选择bgsave而不是save来进行持久化。

自动触发最常见的情况是在配置文件中通过 save m n 指定当m秒内发生n次变化时，会触发bgsave。

bgsave：

bgsave就是主从复制的机制

创建一个子进程，让子进程创建rdb文件

bgsave特点：

主进程会通过fork机制创建一个子进程，子进程的创建过程中，主进程会阻塞，子进程创建完毕，主进程会停止阻塞。子进程来创建rdb文件。创建完成之后，通知主进程更新通知信息

vim /etc/redis/6379.conf      #编辑配置文件
 ​
 ----219行--以下三个save条件满足任意一一个时，都会引起bgsave的调用
 save 900 1      #当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
 save 300 10     #当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
 save 60 10000   #当时间到60秒时，如果redis数据发生了至少10000次变化， 则执行bgsave
 ​
 ----242行--是否开启RDB文件压缩
 rdbcompression yes
 ​
 ----254行--指定RDB文件名
 dbfilename dump.rdb
 ​
 ----264行--指定RDB文件和AOF文件所在目录
 dir /var/lib/redis/6379  

若将修改为 save 60 2会有怎么样的结果？
Save 60 2 的含义是，60秒内，有两次更新才会记录bgsave

接下来60秒内创建2个以上的文件

如果只有一个创建然后exit，就会等待900秒

配置文件内有所更新，而且连带第一次的一起更新

AOF持久化

• RDB持久化是将进程数据写入文件，而AOF持久化，则是将Redis执行的每次写、删除命令记录到单独的日志文件中，查询操作不会记录。
• 当Redis重启时再次执行AOF文件中的命令来恢复数据。（重放命令进行恢复）
• 与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。

AOF的开启配置

vim /etc/redis/6379.conf
 ----700行---修改，开启AOF
 appendonly yes
 ----704行---指定AOF文件名称
 appendfilename "appendonly.aof"
 ----796行---是否忽略最后一条可能存在问题的指令
 aof-load-truncated yes   
 #Redis恢复时，发现AOF文件的末尾被截断了，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能发生redis机器运行崩溃，AOF文件的末尾被截断了，这种情况下，yes会继续执行并恢复尽量多的数据，而no会直接恢复失败报错退出。
 ​
 ​
 /etc/init.d/redis_6379 restart    #重启redis
 ls /var/lib/redis/6379/      #查看是否生成了aof文件

AOF缓存区的同步文件策略存在三种同步方式，它们分别是：

• appendfsync always：命令写入aof_buf后立即调用系统fsync操作同步到AOF文件。安全性高，性能低。
• appendfsync no：当缓冲区被填满或超过了指定时限后（默认30秒），才将缓冲区的数据写入到硬盘里。性能高，但安全性低。
• appendfsync everysec：每秒同步一次，是性能和数据安全性的平衡，因此是Redis的默认配置。
   

appendfsync always
 写入过程中，立即调用ｒｅｄｉｓ系统的ｆｓｙｎｃ操作写入到ａｏｆ文件，这次写入都执行同步，硬盘的性能有瓶颈。硬盘的寿命也会大大降低
 
appendfsync everysec
命令写入，调用write操作，write操作结束后，线程会返回，ｆｓｙｎｃ同步文件由专门的线程每秒调用一次。这是一个折中的策略，是性能和安全性的平衡，是ｒｅｄｉｓ的默认配置，也是推荐配置
 
 
 appendfsync no
 写入操作会调用系统的ｗｒｉｔｅ操作，但是不对ａｏｆ文件进行同步，操作系统来同步，同步周期是30秒，文件同步时间不可控，缓冲区会堆积大量数据，数据的安全无法保证

aof的备份恢复

vim /etc/redis/6379.conf
cd /var/lib/redis/6379
#检查文件是否生成
 
实现数据恢复
进入redis
set test1 1
set test2 2
set test3 3
vim /var/lib/redis/6379/appendonly.aof
#配置文件会记录所有redis的操作
flushall
/etc/init.d/redis_6379 stop
#停止redis服务
vim /var/lib/redis/6379/appendonly.aof
#根据为位置点删除flushall这个操作
/etc/init.d/redis_6379 restart
#重启服务
进入redis查看文件恢复
实验已经完成！

aof的重写功能

• 随着时间流逝，Redis服务器执行的写命令越来越多，AOF文件也会越来越大；过大的AOF文件不仅会影响服务器的正常运行，也会导致数据恢复需要的时间过长。
• 文件重写是指定期重写AOF文件，减小AOF文件的体积。需要注意的是，AOF 重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作！
• 关于文件重写需要注意的另一点是：对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；即使没有文件重写，数据也可以被持久化并在Redis启动的时候导入。因此在一些现实中，会关闭自动的文件重写，然后通过定时任务在每天的某一时刻定时执行。
   

注意：

重写会消耗性能，影响业务，不能在业务高峰期进行重写。所以一般会关闭自动重写，由定时任务在每天的某一时刻定时执行重写功能。

重写触发条件

• 手动触发： 直接调用bgrewriteaof命令，该命令的执行与bgsave有些类似：都是fork子进程进行具体的工作，且都只有在fork时阻塞。------redis-cli bgrewriteaof
• 自动触发： 通过设置auto-aof-rewrite-min-size选项和auto-aof-rewrite-percentage选项来自动执行BGREWRITEAOF。
   

• 只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个选项同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。

vim /etc/redis/6379.conf
 ----771行----
  771 auto-aof-rewrite-percentage 100
  772 auto-aof-rewrite-min-size 64mb
 ​
 -----------------------以下是注释--------------------------------
 ● auto-aof-rewrite-percentage 100  
 #文件的大小超过基准百分之多少后触发bgrewriteaof。默认这个值设置为100，意味着当前aof是基准大小的两倍的时候触发bgrewriteaof。把它设置为0可以禁用自动触发的功能。
 #即当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作。
 #注意：例如上次文件达到100M进行重写，那么这次需要达到200M时才进行重写。文件需要越来越大，所以一般不使用自动重写。如果使用自动重写，需要定期手动重写干预一次，让文件要求恢复到100M。
 ​
 ● auto-aof-rewrite-min-size 64mb      #当文件大于64M时才会进行重写
 #当前aof文件大于多少字节后才触发。
 #当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF

文件重写压缩AOF文件的原因

• 过期的数据不再写入文件。
• 无效的命令不再写入文件：如有些数据被重复设值（set mykey v1, set mykey v2）、 有些数据被删除了（set myset vl, del myset）等。
• 多条命令可以合并为一个：如sadd myset v1, sadd myset v2, sadd myset v3可以合并为sadd myset v1 v2 v3。（sadd添加集合）
   

核心：

重写之后，ａｏｆ文件当中命令减少了，内容自然减少，空间也少了，自然而然恢复速度也增加了（重写不是必须）

RDB和AOF的优缺点

RDB的优缺点

优点：

RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。当然，与AOF相比， RDB最 重要的优点之一是对性能的影响相对较小。

（体积小，恢复速度更快，对性能影响较小。）

缺点

• RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流。
• 此外，RDB文 件需要满足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。
• 对于RDB持久化，一方面是bgsave在进行fork操作时Redis主进程会阻塞，另一方面，子进程向硬盘写数据也会带来IO压力。

（实时性差、兼容性差、在fork子进程时会阻塞父进程。）
 

AOF优缺点

优点：

• 秒级持久化，一旦执行，立刻写入，兼容性好（命令写入），文本格式保存的命令。

缺点：

• 文件大。恢复速度慢。AOF持久化需要频繁的向磁盘写数据，磁盘的I/O压力也很大。对redis主进程的性能也会有一定的影响。