。

因为Redis是基于内存存储数据的#xff0c;一旦redis实例当即数据将会全部丢失#xff0c;所以需要有某些机制将内存中的数据持久化到磁盘以备发生宕机时能够进行恢复#xff0c;这一过程就称…持久化即把数据保存到可以永久保存的存储设备当中磁盘。

因为Redis是基于内存存储数据的一旦redis实例当即数据将会全部丢失所以需要有某些机制将内存中的数据持久化到磁盘以备发生宕机时能够进行恢复这一过程就称之为持久化。

AOF持久化RDB持久化

AOF持久化是通过保存redis所执行的命令来记录数据状态的。

以日志的形式来记录每个写操作将redis执行过的所有写指令记录下来只允许追加文件不允许改写文件。

在redis重启后会读取该文件用于数据的重新构建。

2、AOF持久化流程

客户端写入命令执行成功后会被append追加到AOF缓冲区内AOF缓冲区根据AOF持久化策略【always|everysec|no】将操作异步追加至磁盘的AOF文件中AOF文件超过重写策略或手动重写时会对AOF文件进行rewrite重写压缩AOF文件容量当redis服务重启时会加载AOF文件中的写操作达到恢复数据的目的

3、AOF持久化策略

Redis提供了三种写磁盘的策略Always、EverySecend、No分别对应每条指令保存一次、每秒保存一次、不保存

Always每次执行一个命令保存一次

在此策略下成功执行任务之后会同步写入磁盘写入成功后才会将结果返回给客户端此时redis主线程是阻塞状态的。

如果在写入过程中redis服务宕机且此时内存数据写入成功那么在redis重启后该数据会丢失

EverySecend每秒保存一次

在此策略下成功执行任务之后会写入AOF缓冲区然后立即返回结果不需要等待AOF文件写入成功。

且由于AOF缓冲区是在内存中开辟的空间所以写入速度很快。

如果写入过程中redis服务宕机且内存中的数据写入成功那么在redis重启后宕机前一秒钟时间取决于同步之后到宕机的时间差可能不足一秒钟的数据会丢失。

一般情况下推荐使用此策略取性能和安全性的平衡点

No不保存

在此策略下成功执行任务之后会写入AOF缓冲区然后立即返回结果但是AOF缓冲区的数据何时写入磁盘完全由操作系统决定。

如果发生宕机的情况数据的丢失将取决于操作系统。

三种策略对比

因为在服务运行过程中会不停的有数据追加写入AOF文件那么AOF文件就会不停的变大。

如果不进行重写不仅占用多余的内存且在redis服务重启后恢复数据的时间也会加长。

AOF文件重写不是针对于原有的AOF文件进行任何的写入和读取而是针对当前redis数据库中键的当前值。

比如之前有一个键list对其执行了5条命令那么在重写时会直接取当前数据库中该list对应的值进行设置只需要写入一条命令即可。

主线程在执行写命令时如果当前的AOF文件大小触发了重写基准值AOF当前大小base_size

base_size*100%

(默认)且当前大小64mb(默认)的情况下或者手动执行了bgrewriteaof命令主进程fork出子进程执行重写操作主进程继续处理新的写入命令子进程copy当前redis内存中的数据到临时文件客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间新的数据修改不会丢失子进程写完新的AOF文件后向主进程发信号主进程更新统计信息主进程把aof_rewrite_buf中的数据写入新的AOF文件使用新的AOF文件覆盖旧的AOF文件完成AOF重写

子进程重写期间主进程可以继续处理其他的写请求避免阻塞主进程带有数据进程的数据副本使用子进程而不是线程可以避免使用锁的情况下保证数据的安全性。

RDB快照及其实现

DataBase是Redis的一种数据持久化策略是一种以内存快照形式保存Redis数据的方式。

所谓快照就是指把某一刻的状态以文件的形式进行全量备份到磁盘这个快照文件就称为RDB文件。

2、快照怎么用

Redis提供了两个命令来生成RDB文件分别是save、bgsave。

save执行此命令会在主线程生成RDB文件因此会阻塞主线程处理其他新的请求bgsave会创建一个子进程来生成RDB文件可以避免主线程阻塞

此外还可以通过redis配置文件来调整RDB文件的生成策略。

比如可以设置save

900

需要注意因为RDB文件生成是全量备份所以设置的生成时间不能过于频繁否则会对Redis性能产生影响。

但是也不能将频率设置的太低否则在redis宕机时丢失的数据会更多。

通常来说设置至少五分钟保存一次快照。

在执行bgsave过程中redis依然可以继续处理操作命令依靠的就是COWcopy

执行bgsave命令时会通过fork()创建子进程此时的子进程和父进程是共享同一片内存数据的子进程的页表是复制的父进程的页表但是二者的页表指向的物理地址还是同一个。

这样可以加快父进程创建子进程的速度因为在创建子进程时父进程会阻塞。

COWcopy

write写时复制技术是一种内存管理技术它允许多个进程共享同一块内存只有在某个进程尝试修改内存时才会将内存复制一份以确保数据一致性。

在redis生成RDB快照时由于父子进程共享同一块内存数据当父进程接收到新的写操作命令时就会另外复制一份然后父进程在这个数据副本上进行数据的修改操作。

与此同时子进程则继续把原来的数据写入RDB快照文件。

需要注意由于在生成RDB文件时发生的写操作由父进程在生成的数据副本中进行处理所以子进程在生成RDB文件时无法记录操作过程中的修改信息只能保存原有的数据文件。

而在操作过程中的修改信息则需要在下一次的RDB文件生成时才会得以备份。

AOF和RDB总结

AOF把所有对Redis的服务器进行修改的命令都追加写入一个文件中该文件是一个命令的集合

RDB快照形式直接把内存中的数据以二进制的形式保存到一个dump.rdb文件中定时保存。

RDB

的持久化方式将内存中的数据以快照的方式写入二进制文件中默认的文件名是

dump.rdb

RDB适用于大规模的数据备份并且在设置好快照生成规则后可以精准的将数据恢复到某一个时间点。

且由于生成的是全量数据的快照文件恢复速度也会比AOF更快。

AOF备份机制更加文件数据丢失少备份日志文件可读。

RDB不适用于用于实时数据备份的解决方案一旦发生意外宕机丢失数据会比较多。

AOF备份频率高占用内存大恢复速度相对慢性能压力大。

4、在实际生产中应该如何选择

对数据完整性要求高不需要考虑redis性能瓶颈AOF对数据完整性要求不高RDB

数据库备份和灾难恢复定时生成RDB快照更加便于数据库备份并且RDB恢复数据的速度也要比AOF恢复的速度更快。

在redis4.0之后支持同时开启RDB和AOF系统重启后redis会优先使用AOF来恢复数据降低数据的丢失程度。