本文会将此知识点分为四方面来具体详细讲解
何谓“持久化” ,就是把数据保存到可永久保存的存储设备中(如磁盘)。持久化的主要应用是将内存中的数据存储在关系型的数据库中,当然也可以存储在磁盘文件中。
例如:你做的新用户注册功能,在前端拿到用户的个人信息=>通过代码=>存入关系型数据库,那这个过程我就可以看作是一个数据持久化的过程。同样的对于数据库来讲,我将sql文件存储在我电脑的D盘上,这也是数据持久化的操作,持久化都是相对来说的。
一提到redis,大家会想到Redis是一种key-value键值形式的数据库,它可以存储多种类型的数据,有字符串,链表,集合和有序集合等等多种格式的数据
第二个就会想到一个字,快,它为啥快呢,因为redis是一个内存数据库,它的数据都存放在内存当中,当关闭redis服务的时候,随着内存消失数据会丢失,这个时候我们就需要将内存中需要持久化的数据保存到本地硬盘的文件中,当redis重启服务时,首先会根据配置的指定持久化文件恢复内存数据。
首先,redis持久化分两种,RDB模式和AOF模式;
它是redis默认的持久化方式,不定期(自己配置)的将数据保存在磁盘文件上,在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是fork一个子进程,复制一份内存中的数据集,先将数据集写入一个临时文件,写入成功后,再替换之前的文件,然后用二进制压缩存储。所以说他是一种覆盖的形式,称为半持久化模式
1.对于文件备份来说是非常合适的,很灵活,举个例子,你可能打算每一个小时备份一次最近24个小时的数据,与此同时还要每24小时还要备份一次最近72小时的数据
2.性能最大化,redis重要特点就是快。对于RDB来说,在开始备份时,它唯一需要做的只是调用一个子进程,之后再由子进程完成这些持久化的工作,那在到达指定备份时间点之前,它是不会做其余操作,所以说它做到了最大程度上的不影响redis的运行效率。
3.相比于AOF模式来说,如果数据集很大,RDB启动会更快(后面会讲到)
1.如果你想最大限度的避免数据丢失的情况,那RDB就不太行了,因为系统一旦在备份时间点之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失,也就是说新的数据,还没来得及备份的数据,都会随着宕机一起丢失掉。
需要手动开启,把每一次数据变化以日志的形式写入aof文件中,它是以追加的方式记录数据,它会记录服务器所处理的每一个增删改操作,甚至每秒同步一次数据然后每秒追加一次数据,打开文件可以看到详细的追加数据,称为全持久化模式
1.可以带来比RDB更高的数据安全性。跟RDB定时备份不一样,AOF提供了3种策略,即每秒同步、每修改同步和不同步
2.由于aof写入操作采用的是追加方式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果操作只是写入了一半数据就出现了系统崩溃问题,不用担心,因为它最多只会损失掉一秒钟的数据,或者损失掉一次的增删改数据
1.对于相同的数据集来说,AOF文件大小通常大于RDB文件,另外在恢复大数据集时,它的效率没有RDB快
2.AOF在运行效率上慢于RDB,因为aof的每秒同步和每修改同步会影响到redis的效率,但是因为操作是异步的,所以也不会慢太多(相对于RDB来讲)
说完了RDB和AOF的优劣势,那怎么用就很清楚啦,首先,AOF的优势就是RDB的劣势,而AOF的劣势恰恰就是RDB的优势。
由此可见,在追求性能的前提下就要牺牲数据安全性,而追求数据高安全就要牺牲性能,所谓“鱼和熊掌不可兼得”嘛
配置持久化文件路径: redis/redis.conf文件,建议大家在黑窗口中配置
conf文件中配置:
#save "" //关闭RDB
save 900 1 //900秒且有1个变量改变时保存到硬盘
save 300 10 //300秒且有10个变量发生改变时保存到硬盘
save 60 10000 //60秒且有10000个变量发生改变时保存到硬盘
aof模式需要手动开启
conf文件配置:
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次,该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。
cli黑窗口配置:
CONFIG get appendonly //查看是否开启AOF
CONFIG set appendonly yes //开启AOF
CONFIG get appendonly //查看是否开启成功
CONFIG REWRITE //写进配置文件
运行中要开启aof
如果直接在conf文件中修改, appendonly yes 这样会造成数据丢失
用命令 redis-cli:config set appendonly yes 这样不会丢失数据