Redis(二)持久化
持久化选项
Redis提供了两种不同的持久化方法来将数据存储到硬盘里面。一种方法叫快照(snapshotting),它可以将存在于某一时刻的所有数据都写入到硬盘里面。另一种方法叫只追加文件(AOF),它会在执行写命令时,将执行的写命令复制到硬盘里面。
快照持久化(RDB)
Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。根据配置,快照将被写入dbfilename选项指定的文件里面,并储存在dir选项指定的路径上面。
配置文件内容:
save配置项:
用户可根据实际情况设置save配置项
创建快照的几种方法
- 客户端可以通过向Redis发送BGSAVE命令来创建一个快照。对于支持BGSAVE命令的平台来说(基本上所有的平台都支持,除了Windows)平台,Redis会调用fork来创建一个子进程,然后子进程负责将快照写入硬盘,而父进程则继续处理命令请求。
- 客户端还可以通过向Redis发送SAVE命令来创建一个快照,接到SAVE命令来创建一个快照,接到SAVE命令的Redis服务器在快照创建完毕之前将不再响应任何其他命令。SAVE命令并不常用,通常只会在没有足够内存去执行BGSAVE命令的情况下,又或者即使等待持久化操作执行完毕也无所谓的情况下,才会使用这个命令。
- 如果用户设置了save配置选项,,比如save 60 10000,那么从Redis最近一次创建快照之后开始算起,当“60秒内有10000次写入”这个调价满足时,Redis就会自动触发BGSAVE命令。如果用户设置了多个save配置选项,那么当任意一个save配置选项所设置的条件被满足时,Redis就会h触发一次BGSAVE命令。(这种使用最多)
- 当Redis通过SHUTDOWN命令接收到关闭服务器的请求时,或者接收到标准TERM信号时,会执行一个SAVE命令,阻塞所哟客户端,步再执行客户端发送的任何命令,并在SAVE 命令执行完毕之后关闭服务器。
- 当一个Redis服务器连接另一个Redis服务器,并向对方发送SYNC命令来开始一次复制操作的时候,如果主服务器目前没有在执行BGSAVE操作,或者主服务器并非刚刚执行完BGSAVE操作,那么主服务器就会执行BGSAVE命令
快照持久化的的优缺点
RDB持久化时全量备份,一次保存整个数据库,恢复数据速度快。但保存时间间隔长,随着Redis占用的内存越来越多,BGSAVE创建子进程时耗费的时间也会越来越多。为防止Redis因为创建子进程而出现的停顿,可以考虑关闭自动保存,转而通过手动发送BGSAVE或者SAVE来进行持久化。手动发送BGSAVE一样会引起停顿,唯一不同的是用户可以通过手动发送BGSAVE命令来控制停顿出现的时间。另一方面,SAVE会一直阻塞Redis直到快照生成完毕,但是因为它不需要创建子进程,所以不像BGSAVE一样因为创建子进程而导致Redis停顿;并因为没有子进程在争抢资源,所以SAVE创建快照的速度会比BGSAVE创建的快照速度要快一些。
AOF持久化
AOF持久化会将被执行的写命令写到AOF文件的末尾,以此来记录数据发生的变化。(存储的时命令,而不是真实的数据)默认不开启。Redis只要从头到尾重新执行一次AOF文件包含的所有写命令,就可以恢复AOF文件中所记录的数据集。
配置选项:
appendfsync always # 每个Redis写命令都要同步写入硬盘,数据丢失最少,但这样做会严重降低Redis的速度,写入放大问题
appendfsync everysec # 每秒执行同步一次,显示地将多个写命令同步到硬盘,最多只丢失1秒
appendfsync no # 让操作系统来决定应该何时进行同步,会丢失不定数量的数据
AOF持久化的优缺点
AOF持久化既可以将丢失数据的时间窗口降低至1秒(甚至不丢失任何数据),又可以在极短的时间内完成定期持久化操作,但随着Redis不断运行,不断的将被执行的写命令记录到AOF文件里面,AOF文件的体积也会不断增大,如果AOF文件的体积非常大,那么还原操作执行的时间就可能会非常长。
重写/压缩AOF文件
- 客户端向Redis服务器发送BGREWRITEAOF命令,这个命令通过移除AOF文件中的冗余命令来重写AOF文件,使AOF文件的体积变得尽可能小。
- 通过设置auto-aof-rewrite-percentage选项和auto-aof-rewrite-min-size选项来自动执行BGREWRITEAOF,例如:当AOF文件的体积大于64MB,并且AOF文件的体积比上一次重写之后的体积大了至少一倍的时候,Redis将执行BGREWRITEAOF命令。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
总结
无论是使用RDB持久化还是AOF持久化,将数据持久化到硬盘上都是非常有必要的,但除了持久化外,用户还必须对持久化所得的文件进行备份(最好备份到多个不同的地方),这样才能尽量避免数据丢失事故发生。如果条件允许的话,最好能将快照文件和最新重写的AOF文件备份到不同的服务器上面。
复制
复制可以让其他服务器用有一个不断地更新的数据副本,从而使得拥有数据副本的服务器可以用于处理客户端发送的读请求。
系统的主要运行机制:
- 当一个 master 实例和一个 slave 实例连接正常时, master 会发送一连串的命令流来保持对 slave 的更新,以便于将自身数据集的改变复制给 slave , :包括客户端的写入、key 的过期或被逐出等等。
- 当一个 master 实例和一个 slave 实例连接正常时, master 会发送一连串的命令流来保持对 slave 的更新,以便于将自身数据集的改变复制给 slave , :包括客户端的写入、key 的过期或被逐出等等。
- 当无法进行部分重同步时, slave 会请求进行全量重同步。这会涉及到一个更复杂的过程,例如 master 需要创建所有数据的快照,将之发送给 slave ,之后在数据集更改时持续发送命令流到 slave 。
配置项
主服务器(Master):
dbfilename dump.rdb
dir /var/lib/redis
从服务器(Slave):
slaveof host port # Redis将根据该选项给定的IP地址和端口号来连接主服务器
一个正在运行的Redis服务器,用户可以通过发送SLAVEOF no one命令来让服务器终止复制操作
Redis复制的启动过程
步骤 | 主服务器操作 | 从服务器操作 |
---|---|---|
1 | (等待命令进入) | 连接(或着重连接)主服务器,发送SYNC命令 |
2 | 开始执行BGSAVE,并使用缓冲区记录BGSAVE之后执行的所有命令 | 根据配置选项来决定是继续使用现有的数据(如果有点话)来处理客户端的命令请求,还是向发送请求的客户端返回错误 |
3 | BGSAVE执行完毕,向从服务器发送快照文件,并在发送期间继续使用缓冲区记录被执行的写命令 | 丢弃所有旧数据(如果有点话),开始载入主服务器发来的快照文件 |
4 | 快照文件发送完毕,开始向从服务器发送存储在缓冲区里面的写命令 | 完成对快照文件的解释操作,像往常一样开始接收命令请求 |
5 | 缓冲区存储的写命令发送完毕;从现在开始,每执行一个写命令,就向从服务器发送相同的写命令 | 执行服务器发来等待所有存储在缓冲区里面的写命令;并从现在开始,接收并执行主服务器传来的每个写命令 |
上一篇: 剖析Python垃圾回收机制
下一篇: 如何用c语言输出100到200之间的素数
推荐阅读
-
Myeclipse 自动生成可持久化类的映射文件的方法
-
iOS用两行代码完美解决数据持久化
-
详解Android开发数据持久化之文件存储(附源码)
-
React通过redux-persist持久化数据存储的方法示例
-
通过Spring Boot + Mybatis + Redis快速搭建现代化Web项目
-
redis与ssm整合方法(mybatis二级缓存)
-
SpringBoot+Mybatis项目使用Redis做Mybatis的二级缓存的方法
-
springboot+mybatis+redis 二级缓存问题实例详解
-
Python实现的序列化和反序列化二叉树算法示例
-
C# Redis学习系列(二)Redis基本设置