LiSheng's blog LiSheng's blog
首页
笔记
个人简历
随笔集
GitHub (opens new window)
首页
笔记
个人简历
随笔集
GitHub (opens new window)
  • golang

  • cplus

  • leetcode

  • 存储技术

  • 分布式系统

  • 计算机网络

  • Linux操作系统

  • Redis

    • 大纲
    • redis持久化策略
      • redis事务
      • redis分布式锁
      • redis高可用
      • redis主从同步
      • Redis是什么
      • Redis基本数据结构
      • Redis为什么这么快
      • 缓存击穿、缓存穿透、缓存雪崩
      • 热Key问题,如何解决热key问题
      • Redis 过期策略和内存淘汰策略
      • Redis 的持久化机制
      • Redis的高可用
      • 使用过Redis分布式锁
      • Redis的跳跃表
      • MySQL与Redis 如何保证双写一致性
      • Redis的Hash 冲突怎么办
      • 布隆过滤器
      • Redis 事务机制
    • 其他

    • 笔记
    • Redis
    lisheng
    2024-09-10
    目录

    redis持久化策略

    Redis 具有两种主要的持久化机制:RDB(Redis Database)快照和AOF(Append-Only File)日志。每种方式各有适用场景和优缺点。以下是详细的介绍:

    # 1. RDB持久化机制

    # 工作原理:

    Redis 通过生成快照的方式将内存中的数据写入磁盘,生成一个 .rdb 文件。这是一个二进制文件,包含了某一时刻的完整数据集。Redis 可以根据配置的时间间隔或者手动执行命令来触发快照生成。

    # 配置选项:

    • save <seconds> <changes>:在指定时间内,数据发生了指定次数的变化时,Redis 会自动触发 RDB 快照。
    • bgsave:手动触发后台生成 RDB 快照。
    • save "":禁用 RDB 持久化。

    # 优点:

    • 性能高效:由于 RDB 是在某个时刻生成的完整快照,不需要持续对磁盘进行操作,因此对性能的影响较小。适合在不需要频繁保存数据的情况下使用。
    • 恢复速度快:在 Redis 重新启动时,RDB 文件可以快速加载到内存中,恢复数据。
    • 文件紧凑:RDB 文件是紧凑的二进制格式,文件较小,适合进行备份和传输。

    # 缺点:

    • 数据丢失风险:RDB 只能在快照时保存数据,因此在下次快照之前发生的写操作可能丢失。例如,如果 Redis 崩溃了,你会丢失最近一次快照之后的所有数据。
    • 生成快照时开销较大:生成 RDB 文件时,Redis 会 fork 一个子进程来执行这个操作,如果数据集较大,可能会影响性能。

    # 适用场景:

    • 备份和冷启动:RDB 文件很小且完整,适合做定时备份或在数据一致性要求不高的情况下冷启动。
    • 数据写入频率较低的场景:比如定期更新的数据集,不需要频繁持久化。

    # 2. AOF持久化机制

    # 工作原理:

    AOF 持久化会将 Redis 的每一个写操作(如 SET、DEL 等)追加记录到日志文件中。这些命令会按照 Redis 服务器处理它们的顺序被写入到 AOF 文件。当 Redis 重新启动时,它会根据 AOF 文件中的记录依次重放命令,恢复数据。

    # 配置选项:

    • appendonly yes:启用 AOF 持久化。
    • appendfsync always:每次写入都同步到磁盘,最安全,但性能开销最大。
    • appendfsync everysec:每秒同步一次,推荐的配置,性能和安全性折中。
    • appendfsync no:不主动同步,完全依赖操作系统将数据刷新到磁盘,性能最好,但风险最大。

    # 优点:

    • 数据安全性高:AOF 可以非常频繁地将数据同步到磁盘,保证即使在意外宕机时也能恢复最近的数据。尤其是在 appendfsync everysec 模式下,最多只会丢失一秒的数据。
    • 文件可读:AOF 是一个基于 Redis 命令的日志文件,人可以直接阅读和编辑。
    • 灵活的重写机制:为了防止 AOF 文件过大,Redis 会定期进行 AOF 重写,将文件压缩成只包含必要命令的更小版本。

    # 缺点:

    • 文件体积大:相比 RDB,AOF 文件会更大,特别是在高写操作的场景下,AOF 文件增长速度很快。
    • 恢复速度较慢:由于 AOF 需要逐条重放所有写入操作,恢复数据时相比 RDB 要慢一些。
    • 性能开销:频繁的磁盘写入操作会影响 Redis 的性能,尤其是当设置为 appendfsync always 模式时。

    # 适用场景:

    • 数据一致性要求高的场景:AOF 提供更强的数据一致性保障,适用于数据丢失不可接受的系统,如金融系统、交易系统等。
    • 写操作频繁的场景:AOF 可以频繁记录操作,确保系统崩溃后只丢失极少量的数据。

    # 3. RDB和AOF的混合使用

    Redis 从 4.0 版本开始支持RDB和AOF混合持久化。在此模式下,Redis 通过 RDB 保存一个时间点的数据快照,并通过 AOF 记录快照后的增量操作。这种方式结合了 RDB 的快速恢复和 AOF 的数据完整性优点。

    # 优点:

    • 启动速度快:加载 RDB 文件后,仅需回放少量的 AOF 命令,恢复速度更快。
    • 减少AOF体积:相较于完整的 AOF 文件,AOF 重放命令更少,减少文件体积。

    # 缺点:

    • 复杂性增加:混合持久化机制比单一的持久化方式更复杂,增加了系统的管理和维护成本。

    # 适用场景:

    • 需要快速恢复和高数据一致性的应用场景,例如大型的分布式缓存系统。

    # 4. 总结

    • RDB:适合对性能要求高但允许一定程度的数据丢失的场景,例如缓存系统、非关键业务的数据存储。
    • AOF:适合对数据一致性要求高的场景,通常用在数据持久化要求较高例如金融的生产环境中。
    • 混合模式:适合需要快速恢复,同时又对数据一致性要求较高的场景,是较为平衡的持久化选择。

    根据实际业务场景,你可以选择最适合的持久化方式,也可以根据需要开启多种持久化机制。

    编辑 (opens new window)
    上次更新: 2024/09/13, 11:59:12
    大纲
    redis事务

    ← 大纲 redis事务→

    最近更新
    01
    ceph分布式存储-对象存储(RGW)搭建
    10-27
    02
    ceph分布式存储-集群客户端连接
    10-27
    03
    ceph分布式存储-管理crushmap
    10-27
    更多文章>
    Theme by Vdoing
    • 跟随系统
    • 浅色模式
    • 深色模式
    • 阅读模式