1.Redis持久化方式
RDB(Redis DB):真正的将数据以文件形式持久化到磁盘
AOF(AppendOnlyFile):存储命令(对库操作时的所有命令)默认不开启
2.RDB持久化
RDB持久化功能可以将服务器包含的所有数据以二进制文件的形式保存硬盘中。而通过在服务器启动时载入RDB文件,服务器可以读取整个RDB文件的内容、还原服务器原有的数据库数据。
2.1redis服务器创建RDB文件,常用的三种方式:
a.服务器执行客户端发送的SAVE命令;(阻塞)
b.服务器执行客户端发送的BGSAVE命令;(后台执行)
c.使用SAVE配置选项设置自动保存满足的条件,服务器自动执行BGSAVE;
前两种需用户手动执行,第三种由redis服务器自动执行。
2.1.1、SAVE
执行save命令的过程中,redis服务将被阻塞,无法处理客户端发送的命令请求,只有在save命令执行完毕之后才能接受新的请求。
如果RDB文件已经存在,服务器将自动使用新的RDB文件替代旧的RDB文件。
2.1.2、BGSAVE
执行BGSAVE命令同样可以创建一个新的RDB文件,BGSAVE和SAVE的区别在于,它不用造成redis服务器的阻塞,执行BGSAVE命令后,服务器仍然可以正常接受客户端的请求命令。
BGSAVE不会造成服务器阻塞的原因是:
a.它通过fork()来生成一个子进程,然后由子进程负责创建RDB文件,自己继续处理客户端的请求;
b.当子进程创建好RDB文件后,它向redis服务器发送信息通知它RDB文件创建完毕;
c.最后redis服务器接手子进程创建的RDB文件,返回结果执行完毕。
因为子进程会消耗额外的内存,所有要比SAVE速度慢
2.1.3、自动创建RDB文件
设置
save 300 10
#距上次创建RDB文件已经过去300秒,且数据库总共发生不少于10次的修改,执行GBSAVE命令
save 60 10000
#距上次创建RDB文件已经过去60秒,且数据库总共发生不少于10000次的修改,执行GBSAVE命令
此设置表示,只要任一条件被满足服务器就执行BGSAVE命令,在每次创建RDB文件后,服务子统计的时间和次数计时器将被清零,重新开始计算。
RDB的缺点,创建RDB需要将数据库所有数据保存起来,非常耗时,每隔一段时间执行一次备份回影响服务器性能,而且当在备份前出现宕机状况,会丢失部分数据
3.AOF持久化
为了解决RDB持久化的缺点,AOF中用户可自己根据持久化方案进行调整,让意外宕机时不丢失数据,或只丢失一秒的数据。
3.1AOF持久化方法:
当有修改数据库的命令执行时,服务器就会将执行的命令写入到AOF文件的末尾。因为AOF文件存储了服务器执行所有数据库的修改命令,所有只要执行一次AOF文件,所有数据就回被还原。
但此方式也会出现丢失数据,因为常见的操作系统,在执行写操作调用write函数时,系统通常不会讲内容直接写入硬盘,而是先写入到内存缓冲区,等到缓存区写满后,或者用户执行fsyns调用和fdatasync调用时才真正写入到磁盘。
为了解决此问题,redis提供了appendfsync选项,选项有三个值:always、everysec、no
always:服务器每写一个命令就调用一次fdatasync;(速度慢)
everysec:服务器每一秒调用一次fdatasync;(默认)
no:服务器不调用fdatasync,由操作系统决定;
3.2AOF文件中的冗余命令
随着服务器的不断运行,AOF文件里的内容会越来越大,为了让AOF文件大小控制在合理的范围内,redis提供了AOF重写功能,服务器可以通过这个功能产生一个新的AOF文件,也就是将冗余的命令进行合并。
两种方法可以触发AOF重写:
a、客户端向服务器发送BGREWRITEAOF命令
b、通过配置自动执行BGREWRITEAOF命令,
auto-aof-rewrite-min-size<size>,触发aof重写的最小体积,只要aof文件体积大于等于size时。
auto-aof-rewrite-percentage<percent>指定触发重写时AOF文件体积的百分比