JAVA面试高级技术栈-05-Redis持久化_redis-server fork新的进程-CSDN博客

本文链接：https://blog.csdn.net/qq_46133097/article/details/139168615

JAVA面试高级技术栈-05-Redis持久化

文章目录

JAVA面试高级技术栈-05-Redis持久化

Redis持久化(钝化)

redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。

RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；
AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。

RDB(Redis DataBase)持久化

Redis database backup file，Redis数据库备份文件,也称为Redis数据快照.简单来说就是把内存中的所有数据记录到磁盘中.当Redis实例故障重启后,从磁盘中读取快照文件,恢复数据. 快照文件称为RDB文件(dump.rdp),默认是保存在当前运行目录.

持久化的触发

自动触发

可以在Redis的配置文件中进行配置(打开redis.windows.conf配置文件)


save 900 1     #表示900 秒内如果至少有 1 个 key 的值变化，则进行数据转储
save 300 10    #表示300 秒内如果至少有 10 个 key 的值变化，则进行数据转储
save 60 10000  #表示60 秒内如果至少有 10000 个 key 的值变化，则进行数据转储
 
stop-writes-on-bgsave-error yes  #转储失败后是否允许Redis服务器继续接受数据，设置为no时将阻止Redis继续接收数据；所以为了配合自动转储，需要设置为yes
 
rdbcompression yes  #对于存储到磁盘中的快照，可以设置是否进行压缩存储；设置为yes可以减少转储文件占用磁盘的空间
 
rdbchecksum yes     #在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗。

文件保存路径：dir配置，找到dir, 把./更换成具体的路径即可（./表示根目录）

通过 lastsave 命令可以查看最近一次执行持久化的时间，返回一个时间戳。

在这里插入图片描述

手动触发

**手动save命令: **通过在 redis-cli 客户端中执行 save 命令可立即进行一次持久化保存。save 命令在执行期间会阻塞 redis-server 进程，直至持久化过程完毕。而在 redis-server 进程阻塞期间，Redis不能处理任何读写请求，无法对外提供服务。线上禁止使用
**手动bgsave命令：**通过在 redis-cli 客户端中执行 bgsave 命令可立即进行一次持久化保存。不同于 save 命令的是，正如该命令的名称一样，background save，后台运行 save。bgsave 命令会使服务器进程 redis-server 会fork一个子进程，由该子进程负责完成保存过程。在子进程进行保存过程中，不会阻塞 redis-server 进程对客户端读写请求的处理。

RDB的优劣

**优势: **

①适合大规模的数据恢复

②按照业务定时备份

③对数据完整性和一致性要求不高

④RDB文件在内存中的加载速度比AOF快

劣势:

①在一定间隔时间做一次备份，如果redis意外宕机，就丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失；

②内存数据的全量同步，如果数据量太大会导致I/O严重影响服务性能

③RDB依赖于主进程的fork，在更大数据集上，可能导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致膨胀两倍。需要考虑。

总结

触发RDB快照的条件

①配置文件中默认的快照配置

②手动save、bgsave命令

③执行flushall/flushdb命令也会产生dump.rdb文件

④执行shutdown且没有设置开启AOF持久化、主从复制时，主节点自动触发。

AOF(Append Only File)持久化

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件，但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次已完成数据的恢复工作。

默认情况下，redis没有开启AOF，开启配置：appendonly yes。

AOF保存的时appendonly.aof文件。

AOF缓冲区写回策略

Always：同步写回，每个写命令执行完立刻同步的将日志写回磁盘。可靠性高，数据基本不丢失

everysec：每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘。性能较好

no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。性能好

AOF优劣

优势

更好的保护数据不丢失、性能高、可做紧急回复。

劣势

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb。

aof运行效率要慢于rdb，每秒同步策略较好，不同步效率和rdb相同。

AOF重写机制

启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

① 触发机制之手动触发：客户端向服务器发送bgrewriteaof命令。

② 触发机制之自动触发：满足配置文件中的选项后，Redis会记录上次重写的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时。


appendonly yes                   #开启AOF持久化
 
appendfilename "appendonly.aof"  #配置AOF持久化文件名
 
appendfsync everysec             #配置AOF持久化策略
 
            #always    表示只要缓冲区中数据发生更改，则就将该数据写入到aof文件中
            #everysec  每秒写入把缓冲区中数据写入aof文件中（redis默认）
            #no        不做任何策略配置，将策略的配置交给操作系统，一般操作系统是等待缓冲区被占完之后，将数据写入aof文件中