Redis学习笔记之持久化机制

持久化机制

上小学的时候，我们每天都要做数学题，为了加快做题的速度，我们不可能每次遇到8 x 8都要查看乘法口诀表(最主要的原因是考试的时候，老师不允许)，所以我们会通过死记硬背的方式，将8 x 8 = 64记在大脑当中，这一过程就跟Redis将数据从硬盘存放到内存是一样的。

redis之所以有这么强大的性能，取决于它的数据存放在内存当中，为了在服务器重启后，内存中的数据不会丢失，需要将内存中的数据同步到硬盘中，这一过程就是持久化。

我们每天都会接触或者遇见许多形形色色的人，人的一生也会有很多过客，如果不通过写日记或者拍照留念的方式进行记录，那么几个月或者几年过后，我们对于对方的长相就会模糊甚至遗忘，这种写日记或者拍照的方式，跟Redis将数据持久化到硬盘是一样的。

1 RDB持久化

RDB持久化方式在指定时间间隔对数据进行快照存储，默认存储在当前目录的dump.rdb文件中

1. Redis使用fork函数复制一份当前进程(父进程)的副本(子进程)；
2. 父进程继续接受并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；
3. 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。

高三的时候，班级要利用下午放学的时间拍毕业照，有些同学为了不耽误复习，会利用集队的时间跑去宿舍洗澡或者饭堂吃饭，这个时候轮到我们班拍毕业照了，没办法，就算人不齐，也会上前拍大合照，拍完合照过了几分钟，洗完澡吃完饭的同学终于小跑过来了，班主任为了不让他们的高中留下遗憾，于是说服大家，再拍一次大合照，替换掉旧的合照。

• 优点：对于摄影师来说，不需要来一个同学就拍一次合照
• 缺点：要等待迟到的同学

使用方式

当在指定的时间内被更改的键的个数大于指定的数值时就会触发快照

在redis配置文件中进行配置，但有多个条件时，它们之间以或的形式组合发生作用。

save 900 1 //900秒内有1个键被修改
save 300 10 //300秒内有10个键被修改
save 60 10000 //60秒内有10000个键被修改

2 AOF持久化

AOF持久化方式记录每次对服务器的写操作，默认存储在当前目录的appendonly.aof文件中

appendonly yes 开启AOF持久化，默认是每秒钟同步一次，即appendfsync everysec

还是班级拍大合照，由于洗澡吃饭的同学是陆续过来的，为了不影响学校拍照进度（主要是一直拍照的同班同学也不答应），于是班长提出迟到没来的同学单独一人自己拍照的建议，拍完之后把照片P到合照中，对于大家来说，每个同学都参与了合照，并没有漏下哪一位学生，所以这种方式也被同学们接受了。

• 优点：没有遗漏某一位同学
• 缺点：每个迟到的同学都要拍照，都要消耗一张底片，而且摄影师也会有意见（这里假设费用是一样的）

由于操作系统底层会对数据进行缓存，所以并不是每一次的追加操作都能直接对文件进行修改，如果这个时候发生了宕机或者重启，这部分缓存的数据将会丢失，所以Redis采用了appendfsync强制写入的方式。

使用方式

//自动重写：目的是压缩 aof文件，消除冗余或者重复设值
auto-aof-rewrite-percentage 100 //当前的aof文件大小超过上一次重写时aof文件的100%时会再次进行重写
auto-aof-rewrite-min-size 64mb //允许重写的最小aof文件大小，小于该值不进行重写

3 RDB vs AOF

持久化方式	优点	缺点
RDB	对性能影响最小	同步时丢失数据
	RDB文件进行数据恢复比使用AOF要快很多	如果数据集非常大且CPU不够强,Redis在fork子进程时可能会消耗相对较长的时间，影响Redis对外提供服务的能力
AOF	最安全	文件体积大
	容灾	性能消耗比RDB高
	易读，可修改	数据恢复速度比RDB慢

注意

在实际的生产环境当中，可以单独使用其中一种或者二者结合使用，当开启了AOF持久化机制，服务器重启后会从aof文件中恢复数据，只有当AOF持久化关闭，服务器才会从rdb文件中恢复数据。

参考文章

AOF持久化
Redis入门指南 第2版(异步图书)
网易云课堂《Java高级开发工程师》