8.Redis的持久化
2023年3月15日23:26:02
一、RDB模式
工作原理
- 在指定的时间间隔内将内存中的数据集写入磁盘，也就是快照(Snapshot)
- 数据恢复是将快照文件直接读到内存中
- redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入一个到一个临时文件(dump.rdb)中,待持久化过程结束后，再用本次的临时文件替换上次持久化后的文件
- fork函数的作用是复制一个与当前进程一样的进程，新进程的所有数据数值都和原进程一致，但是一个全新的进程，并作为原进程的子进程
触发方式
- 手动触发：通过命令手动生成快照
- 执行save和bgsave命令，手动触发快照，生成RDB文件
- save: 该命令会阻塞当前redis服务器，执行save命令期间，redis不能处理其他命令，直到RDB过程结束为止(会造成长时间阻塞，不建议使用)
- bgsave:该命令执行后，redis会在后台异步进行快照操作，快照同时还可以响应客户端的请求，阻塞只发生在fork阶段，基本上redis内部的所有RDB操作都是采用bgsave命令
- 自动触发：通过配置参数的设置触发自动生成快照
- 根据配置文件的配置自动触发bgsave
- 主从复制时，从节点要从主节点进行全量复制时也会触发bgsave,生成快照发送到从节点
- 关闭redis服务（shutdown）的时候会触发bgsave
- 执行flushall(生成一个空的临时文件dump.rdb)
开启方式
redis默认开启rdb持久化
数据恢复
将备份文件(dump.rdb)移动到redis路径下(可以配置文件的存放路径)启动服务即可，redis启动会将文件数据加载到内存，在此期间redis会处于阻塞状态，直到全部数据存入内存。
RDB的优缺点
- 优点：
- 数据恢复快
- 数据体积小
- 数据备份使用子进程，对redis服务性能影响小
- 缺点：
- 在一定时间间隔进行备份，当redis意外宕机，将会丢失最后一次修改的数据，无法做到秒级持久
- fork进程时，会占用一定的内存空间
- RDB文件是二进制的没有可读性
因为RDB文件的重要性,在生产环境我们需要保证定时备份
二、AOF模式
工作原理
- 将客户端的每一个写操作命令以日志的形式记录下来，追加到appendonly.aof的文件末尾，在redis服务器重启时，会加载aof文件中的所有命令，来达到数据恢复的目的
- 当有写命令请求时，会追加到AOF缓冲区内，AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作同步到磁盘的AOF文件中
- 当AOF文件大小超过重写策略或手动重写时，会对AOF文件进行重写来压缩AOF文件容量，redis服务重启时，会重新加载AOF文件中的写操作来进行数据恢复
触发方式
- 手动触发：通过bgrewriteaof命令：重新AOF持久化生成aof文件(触发重写)
- 自动触发：默认情况，redis是没有开启AOF(默认使用RDB持久化)，需要通过配置文件开启
开启方式
- 修改配置文件 appendonly yes
- AOF持久化策略
- always: 把每个写命令立即同步到AOF文件，很慢但安全
- everysec: 每秒同步一次，默认配置
- no: redis不执行写入磁盘，交给OS系统处理，很快但不安全
AOF重写机制
- AOF持久化，会把每次写命令都追加到appendonly.aof文件中，当文件过大，redis的数据恢复时间就会变长，因此加入重写策略对aof文件进行重写，生成一个恢复当前数据的最少命令集
AOF重写流程
- 主进程fork出一个子进程进行AOF文件的重写，子进程重写完毕后，主进程把子进程重写期间，其他客户端产生的写请求，追加到AOF文件中，替换旧文件
- AOF的rewirte重写和RDB的bgsave都是由父进程fork出一个子进程来执行的
- 重写是直接把当前内存的数据生成对应的命令，而不是读取旧AOF文件进行命令合并
- AOF重写的主要目的就是通过分析生成最少的命令来实现还原数据的目的,减少了文件的大小,也方便数据恢复
AOF的优缺点
- 优点：
- 数据安全性高，不易丢数据
- AOF文件有序保存了所有写操作，可读性强
- 缺点：
- AOF方式生成文件体积大
- 数据恢复速度比RDB慢
- AOF需要持续I/O操作,影响性能
三、总结
1.RDB持久化能够根据配置文件的策略在指定的时间间隔内对数据进行快照存储
2.AOF持久化是记录每次数据库的【写操作】的命令,当服务器重启的时候,重新执行记录的命令来恢复原始的数据
3.如果Redis只用作缓存,可以不是有任何持久化操作,将RDB和AOF都关闭
4.同时开启RDB和AOF的情况
- 重启数据库,会优先载入AOF文件来恢复数据,因为AOF保存的数据更完整
- 既然同时开启默认读的是AOF,有必要在开AOF的时候开启RDB吗?作者认为有必要,因为RDB更加是和用于备份数据库,方便快速重启,如果AOF文件损坏,RDB可以留着以防万一
6.性能建议
- RDB文件只用作后备用途,所以一般有主从数据库的时候,一般只在从服务器上持久化RDB,且一般15分钟备份一次就够了,所以可以只保留策略1
- 如果开启AOF,虽然保证最多只丢失1秒的数据,但是需要持续的IO,对性能影响较大,
- AOF重写操作的时候,在子进程将内存的命令重写完新的AOF文件之后,主进程需要将在子进程重写文件这个时间段内数据库进行的写操作也添加到新的AOF文件,这个造成主进程的阻塞不可避免,所以要尽量减少重写频率
- AOF重写默认文件大小64M太小,可以根据服务器硬盘情况,设置到5G以上
- 如果不是AOF,只考虑主从复用也可以实现高可用性,并且节省大量IO,减少AOF重写带来的性能波动。缺点是,如果主从都挂掉,会丢失十几分钟的数据,重写启动后也需要比较主从的RDB文件,载入比较新的文件。