为你自己学Redis
  • README
  • 安装
    • macos下安装redis
  • 第1章 构建Redis开发环境
    • 1.1 Redis概述
    • 1.2 了解必要的Docker技能
    • 1.3 安装和配置基于Docker的Redis环境
  • 第2章 实践Redis的基本数据类型
    • 2.1 Redis缓存初体验
    • 2.2 针对字符串的命令
    • 2.3 针对哈希类型变量的命令
    • 2.4 针对列表类型变量的命令
    • 2.5 针对集合的命令
    • 2.6 针对有序集合的命令
  • 第3章 实践Redis的常用命令
    • 3.1 键操作命令
    • 3.2 HyperLogLog相关命令
    • 3.3 lua脚本相关命令
    • 3.4 排序相关命令
  • 第4章 实践Redis服务器和客户端的操作
    • 4.1 Redis服务器管理客户端的命令
    • 4.2 查看Redis服务器的详细信息
    • 4.3 查看并修改服务器的常用配置
    • 4.4 多个客户端连接远端服务器
  • 第5章 Redis数据库操作实战
    • 5.1 切换数据库操作
    • 5.2 Redis事务操作
    • 5.3 地理位置相关操作
    • 5.4 位图数据类型的应用
    • 5.5 慢查询实战分析
  • 第6章 Redis数据持久化操作
    • 6.1 Redis持久化机制概述
    • 6.2 AOF持久化机制实战
    • 6.3 RDB持久化机制实战
    • 6.4 如何选用持久化方式
  • 第7章 搭建Redis集群
    • 7.1 搭建基于主从复制模式的集群
    • 7.2 搭建哨兵模式的集群
    • 7.3 搭建cluster集群
  • 第8章 GO整合MySQL与Redis
    • 8.1 GO通过redigo读写Redis
    • 8.2 Go与各种Redis数据类型
    • 8.3 Redis与MySQL的整合
    • 8.4 Redis缓存实战分析
  • 第9章 Redis应用场景与案例实现
    • 9.1 Redis消息队列实战
    • 9.2 Go实战Redis分布式锁
Powered by GitBook
On this page
  • 6.1.1 基于AOF的持久化机制
  • 6.1.2 基于RDB的持久化机制
  1. 第6章 Redis数据持久化操作

6.1 Redis持久化机制概述

Previous第6章 Redis数据持久化操作Next6.2 AOF持久化机制实战

Last updated 1 year ago

对于Redis而言,持久化机制是指把内存中的数据存储为硬盘文件,这样当Redis重启或服务器故障时能根据持久化后的硬盘文件恢复数据.

6.1.1 基于AOF的持久化机制

在AOF持久化的过程中,会以日志的方式记录每个Redis"写"命令,并在Redis服务器重启时重新执行AOF日志文件中的命令,从而达到"恢复数据"的效果.如下图示:

当AOF持久化功能打开时,每当发生写命令,该命令就会被记录到AOF缓冲区里,AOF缓冲区会根据事先配置的策略定期与硬盘文件进行同步操作,而且当AOF文件大道一定程度后,该文件会被重写,即在不影响持久化结果的前提下进行压缩.此外,当Redis服务器重启时,会加载硬盘上的AOF日志文件,以实现数据恢复的效果.

当Redis因发生故障而重启时,Redis服务器会按照如下步骤,根据AOF日志文件恢复数据:

  • step1. 创建一个伪客户端(fake client)

之所以叫伪客户端,是因为该客户端在本地,不带有任何网络连接,但该伪客户端执行命令的效果和真实的带网络的客户端没有任何差别

  • step2. 执行命令

该伪客户端从AOF日志文件里依次读取每条写命令并执行,直到完成所有写命令

6.1.2 基于RDB的持久化机制

基于RDB的持久化方式会把当前内存中所有Redis键值对数据以快照(snapshot)的方式写入硬盘中,如果需要恢复数据,把快照文件读到内存中即可.

RDB快照文件是经压缩的二进制格式的文件.它的存储路径可以在Redis服务器启动前通过配置参数来设置,也可以在Redis运行时通过命令来设置

2种方式可以触发RDB持久化机制:

  • SAVE和BGSAVE等命令手动触发

  • 根据配置文件中设定的方式定期把数据写入快照

基于RDB的持久化方式比较适合数据备份和灾备的场景,但RDB无法实现即时备份.

虽然RDB无法实现实时备份,但相比于AOF,RDB持久化也有其优点:

  1. 备份文件体积较小:RDB生成的是数据集的二进制快照,通常比AOF文件要小得多.因为AOF记录了所有的写操作命令,随着时间的推移,AOF文件可能会变得非常大

  2. 快速数据恢复:由于RDB是数据的快照,当Redis启动时,它可以直接加载RDB文件进行数据恢复,这通常比重新执行AOF文件中的所有命令要快得多

  3. 低I/O开销:RDB的持久化是间隔一段时间进行的(基于配置的时间和数据变化阈值),而不是像AOF那样每次写操作都要进行磁盘I/O.这意味着在高并发写入的场景下,RDB可能会提供更好的性能

  4. 简单的备份策略:RDB文件提供了一个非常简单的方式来备份Redis数据.管理员可以简单地将RDB文件复制到另一个位置或系统,以实现数据备份

  5. 避免潜在的AOF问题:尽管AOF提供了更精确的数据恢复能力,但它也可能带来一些问题,例如文件过大、AOF重写带来的性能问题等.使用RDB可以避免这些问题

反之,与RDB相比,AOF(Append Only File)持久化方式具有以下优点:

  1. 数据持久性更强:AOF持久化记录了所有的写操作命令,因此它可以提供更强的数据持久性.即使在系统故障后,只会丢失最后一次fsync以来的数据.与RDB相比,AOF通常可以提供更短的数据丢失窗口

  2. 更为健壮:由于AOF文件是一个命令日志,即使文件中的部分数据因为某些原因变得损坏或不一致,Redis也可以加载文件中的大部分数据.而RDB文件,如果损坏,可能会导致整个文件都无法加载

  3. 实时或近实时备份:你可以配置Redis以多种模式写入AOF文件:每次写操作后、每秒或者完全由操作系统决定.这意味着,相对于RDB的定期快照,AOF可以提供更为实时的数据备份

  4. 更精确的数据恢复:由于AOF记录了每一个写操作,所以在系统重启后,它可以通过重新执行这些操作来恢复数据,从而实现非常精确的数据恢复

  5. 易于人工干预和理解:AOF文件是一个文本文件,记录了所有的Redis写命令.这意味着,在必要时,你可以手动编辑AOF文件(尽管不推荐这么做),或者更容易地理解其内容

AOF持久化大致流程