架构师成长记_第六周_07_Redis 持久化机制 之 RDB (Redis DataBase, 冷备)

Redis 持久化机制之RDB(冷备)

Redis官方文档对持久化的解析
PS: Redis 持久化有两种方式: RDB (Redis DataBase) 和 AOF (append only file)

RDB: 冷备份, 是每隔一段时间后选择一个时间点, 然后以一种快照的模式进行备份

AOF: 热备份, 使用日志追加的方式, 默认是每秒进行日志热备.

AOF详细介绍

我们知道, Redis的缓存数据是放在了内存之中, 但是一旦服务器发生故障, 断点后, 内存中的数据就会消失, 所以引入了Redis的持久化机制.
如果不开启持久化服务, 数据的生命周期和服务的生命周期一致, 服务关闭即数据丢失.
也可以同时使用RDB+AOF结合的方式做持久化处理.

redis 持久化机制 (Persistence)

redis 会把内存中的数据备份到磁盘中, 当我们再次打开我们的服务器, 启动redis后, redis是可以把我们磁盘中的数据进行恢复.

RDB 的优势

1. 以单独的文件进行备份, 可以在24小时的每个时间点进行备份, 也可以一个月30天的每天进行备份.可以在配置文件中进行配置.也允许我们简单的去恢复不同版本的数据.
2. RDB可以很方便的作为一些灾备的方案, 因为它只有一个稳固的文件, 这个文件可以传输到远程的备份数据中心.
3. RDB方式在备份的时候有一个父子进程, 当子进程进行备份的时候, 它的父进程实例是不会去操作磁盘IO的, 从而保证备份文件的完整性.
4. RDB恢复的时候, 相比于AOF可以更快速的进行大数据服务重启恢复.

RDB 劣势

1. 对于以RDB方式备份的文件, 它是以隔一段时间的方式进行备份的, 但是如果在备份的期间出了问题, 比如是最后一次出了问题, 那么最后一次的文件会丢失, 之前的版本是可以进行恢复的, 而最后一次的信息就拿不到了.
   如果你能够接受并且忽略这种数据的不一致, 这种数据的不完整性, 也就是在备份的时候出现的这种问题, 你可以使用这种RDB方式.
2. 当我们fork备份数据的时候, 由于他是以父子进程的方式同时进行, 所以会对CPU的损害比较大, 但是这种损耗对于云服务器来讲是可以忽略不计的.
3. 由于RDB是一种隔一段时间,以这个时间段为间隔而进行备份的操作, 所以是无法做到实时的备份.

Redis之RDB的配置详细介绍

1. 进入redis的核心配置文件目录, 进行编辑.
   cd /usr/local/redis
vim redis.conf
   
2. 进行RDB配置
   
   
   
   
   解释:

save 900 1  表示key操作1次低于10次的话, 会在900秒后(15分钟)进行备份更新一次
save 300 10 表示key操作了10次低于10000次的话, 会在300秒后(5分钟)进行备份更新一次
save 60 10000 表示key操作了10000次及以上的话, 会在60秒后(1分钟)进行备份更新一次

ll --full-time 查看显示出目录文件最近的更新时间

总结:

RDB适用于大文件大数据的备份恢复, 但是如果最后一次若出现了问题, 就有可能导致数据的不完整性和不一致性问题的出现.