redis的两种持久化机制目录
- （1）系统默认开启
- （2）客户端快照方式之bgsave
- （3)客户端快照方式之save
- （4）shutdown指令,关闭redis服务
- （5）修改快照文件的名字和生成位置
- （6）快照持久化方式存在的问题：
- 四、redis持久化机制_AOF 只追加日志文件
一、为什么redis要持久化
redis:开源的 内存型 键值型 nosql型数据库
数据库存储在内存中 Client操作的数据也是内存中 效率高 不安全【突发情况 数据丢失】
提供了一种机制：将存中的数据存储到磁盘中 持久化机制
二、redis 两种持久化机制
Redis官方提供了两种不同的持久化方法来将数据存储到硬盘里面分别是:
- 快照(Snapshot： [ˈsnæpʃɒt])持久化
- AOF持久化 (Append Only File) 只追加日志文件
三、redis持久化机制之快照持久化（snapshot）
1、特点
这种方式可以将某一时刻的所有数据都写入硬盘中,当然这也是redis的默认开启持久化方式 ,保存的文件是以**.rdb** 形式结尾的文件因此这种方式也称之为RDB方式 。
其实就是类似于linux中的快照，保存当前redis的数据
2、快照生成方式
系统默认开启
客户端方式：bsave,save指令
shutdown指令
（1）系统默认开启
在redis-conf 中 save设置触发快照持久化的时机
#插入一个linux小知识点，给linxu下的vi显示序号 [root@localhost redis]# vi ~/.vimrc set hlsearch "高亮度反白 set backspace=2 "可随时用退格键删除 set autoindent "自劢缩排 set ruler "可显示最后一行癿状态 set showmode "左下角那一行癿状态 set nu "可以在每一行癿最前面显示行号啦！ set bg=dark "显示丌同癿底色色调 syntax on "迚行语法检验，颜色显示。
vi redis.conf
save 900 1 （15分钟内一次写操作） 默认使用bgsave命令
save 300 10 （5分钟10次写操作） 默认使用bgsave命令
save 60 10000 （1分钟内有10000次写操作） 默认使用bgsave命令
（2）客户端快照方式之bgsave
客户端方式: bgsave(bg相当于前端的bgcolor:背景颜色)
客户端可以使用BGSAVE命令来创建一个快照,当接收到客户端的BGSAVE命令时,redis会调用fork¹来创建一个子进程,然后子进程负责将快照写入磁盘中,而父进程则继续处理命令请求。
名词解释: fork当一个进程创建子进程的时候,底层的操作系统会创建该进程的一个副本,在类unix系统中创建子进程的操作会进行优化:在刚开始的时候,父子进程共享相同内存,直到父进程或子进程对内存进行了写之后,对被写入的内存的共享才会结束服务
bgsave指令特点：创建子进程完成快照，初始和主进程使用相同的内存，client发出写操作后会再次分配内存
bgsave好处 ：1、保证redis服务一直可用 2、完成快照效率高
（3)客户端快照方式之save
客户端还可以使用SAVE命令来创建一个快照,接收到SAVE命令的redis服务器在快照创建完毕之前将不再响应任何其他的命令
- 特点：不会创建子进程 由主进程完成快照
- 好处:创建快照效率高
- 缺陷：redis无法对外提供服务
（4）shutdown指令,关闭redis服务
shutdown指令，关闭redis服务，同时默认触发快照持久化，默认使用的是save指令
（5）修改快照文件的名字和生成位置
名字：dbfilename dump.rdb （253行）
位置：dir./ 表示启动redis服务命令的当前目录
（6）快照持久化方式存在的问题：
持久化需要有触发时机，如果在第一次触发后到第二次触发前发生 发生突发情况 期间的所有数据都会丢失
丢失不定量数据
四、redis持久化机制_AOF 只追加日志文件
快照持久化：将某个时间点的数据状态存储到一个rdb文件中
AOF持久化：将Client的所写命令存储到一个日志文件中
1、aof持久化默认不开启
在redis的默认配置中AOF持久化机制是没有开启的，需要在配置中开启
2、开启aof持久化
在redis的配置文件中进行配置 redis/redis.conf
appendonly yes 开启aof持久化
默认日志文件的名字：appendonly.aof
#先安装vim，方便查找redis.conf中的文件位置 yum install -y vim
vim redis.conf 进入672行，将appendonly no改为yes，开启追加日志持久化
2、日志追加频率
- always 每写一个命令追加一次日志文件
- everysec 美妙追加一次日志文件
- no 由操作系统决定
- 修改同步频率
修改appendfsync everysec|always|no 指定
（1）always 【谨慎使用】
说明: 每个redis写命令都要同步写入硬盘,严重降低redis速度
解释: 如果用户使用了always选项,那么每个redis写命令都会被写入硬盘,从而将发生系统崩溃时出现的数据丢失减到最少;遗憾的是,因为这种同步策略需要对硬盘进行大量的写入操作,所以redis处理命令的速度会受到硬盘性能的限制;
注意: 转盘式硬盘在这种频率下200左右个命令/s ; 固态硬盘(SSD) 几百万个命令/s; 1k ssd
警告: 使用SSD用户请谨慎使用always选项,这种模式不断写入少量数据的做法有可能会引发严重的写入放大问题,导致将固态硬盘的寿命从原来的几年降低为几个月。
**特点：保证数据的安全 **
决定：效率会降低
（2）everysec 【推荐】
说明:每秒执行一次同步显式的将多个写命令同步到磁盘
解释： 为了兼顾数据安全和写入性能,用户可以考虑使用everysec选项,让redis每秒一次的频率对AOF文件进行同步;redis每秒同步一次AOF文件时性能和不使用任何持久化特性时的性能相差无几,而通过每秒同步一次AOF文件,redis可以保证,即使系统崩溃,用户最多丢失一秒之内产生的数据。
特点：保证突发状况下最多丢失一秒内的数据
（3) no 【不推荐】
说明: 由操作系统决定何时同步
解释：最后使用no选项,将完全有操作系统决定什么时候同步AOF日志文件,这个选项不会对redis性能带来影响但是系统崩溃时,会丢失不定数量的数据,另外如果用户硬盘处理写入操作不够快的话,当缓冲区被等待写入硬盘数据填满时,redis会处于阻塞状态,并导致redis的处理命令请求的速度变慢。
特点：由操作系统决定，不推荐
（4）开启日志之后效果图
添加数据详情
五、AOF重写机制
1、redis数据持久化方式
快照 拍摄数据状态
aof 追加写命令
2、使用AOF出现的问题
写命令一直追加到AOF文件中 导致文件越来越大 问题：存储 加载
解决：进行AOF重写
AOF重写：压缩原有的AOF日志文件
3、触发AOF重写机制
（1）手工Client触发
bgrewriteraof指令
（2）配置Server自动触发
auto-aof-rewrite-percentage 100 后续AOF重写机触发时机 aof文件到达前一次文件的100%触发AOF重写 auto-aof-rewrite-min-size 64mb 第一次AOF重写机制触发时机，当AOF文件达到64MB时自动触发
默认的触发机制
第一次：64M—>44MB
第二次 88MB——》68MB
第三次：136MB——》116MB
后续重写机制触发的百分比不要太小 400
第一次：64M—>44MB
第二次 176MB——》156MB
第三次：624MB——》600MB
第四次：2400MB——》2000MB
六、AOF重写原理
注意：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,替换原有的文件这点和快照有点类似。
# 重写流程 `- 1. redis调用fork ，现在有父子两个进程 子进程根据内存中的数据库状态快照，往临时文件中写入重建数据库状态的命令 - 2. 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。 - 3. 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。 - 4. 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。`
AOF重写机制原理总结
不会读取原有的AOF文件，fork子进程去拍摄快照去转换当前的数据，生成一个临时文件，主进程继续处理请求，追加原有文件，同时也会缓存新执行的命令，最后用临时文件+缓存命令 替换原有AOF文件 实现AOF重写
