KittyDaddy's blog KittyDaddy's blog
首页
  • 学习笔记

    • 《Java基础》
    • 《常用设计模式》
    • 《MYSQL》
    • 《GO语言》
    • 《Spring源码解读》
  • 微服务解决方案

    • 锁的演化
    • 简单限流方案
    • 海量数据切分
  • 中间件

    • Nginx
    • MQ
    • Redis
    • Keepalived
  • 面试记
  • 杂文
  • 开源
  • 友情链接
关于
收藏
  • 分类
  • 标签
  • 归档
GitHub (opens new window)

老猫

万物皆系统
首页
  • 学习笔记

    • 《Java基础》
    • 《常用设计模式》
    • 《MYSQL》
    • 《GO语言》
    • 《Spring源码解读》
  • 微服务解决方案

    • 锁的演化
    • 简单限流方案
    • 海量数据切分
  • 中间件

    • Nginx
    • MQ
    • Redis
    • Keepalived
  • 面试记
  • 杂文
  • 开源
  • 友情链接
关于
收藏
  • 分类
  • 标签
  • 归档
GitHub (opens new window)
  • Redis安装教程
  • Redis操作集合
  • Redis持久方式
    • Redis进阶
    • 《Redis》
    老猫
    2020-09-07
    目录

    Redis持久方式

    聊到redis,给我们的第一印象就是快,因为是纯内存数据库。那么redis到底能否进行持久化呢?答案是肯定的,下面我们就来看一下redis的两种持久化的机制,并且比对一下两者的优缺点。

    # RDB模式

    RDB模式为redis database,其工作原理是每隔一段时间,把内存数据库的文件同步写入到磁盘中作为快照。恢复的时候再把快照文件读入到内存中。如果宕机,那么内存中的数据会消失,此时重启redis,数据有会恢复。

    简而言之:内存备份--->磁盘临时文件,磁盘临时文件--->恢复到内存。

    • # 优势:

      (1)每隔一段时间全量备份。

      (2)灾备简单,可以远程传输。

      (3)子进程备份的时候,主进程不会有任何的IO操作(不会有修改或者删除),保证备份数据的完整性。

      (4)相当于AOF来说,当有大文件的时候可以快速实现重启恢复

    • # 劣势:

      (1)发生故障的时候,有可能丢失最后一次备份的数据。

      (2)子进程所占用的内存和父进程所占的内存一样,会造成CPU的 负担。

      (3)由于定时全量备份是重量级操作,所以针对于实时备份,其实是做不到的。

    # 配置方式

    1. redis配置保存位置,例如:/user/local/redis/working/dump.rdb

    2. 保存机制:

      save 900 1  **如果一个缓存更新,则15分钟之后进行备份
      save 300 10 **如果十个缓存更新,则10分钟之后进行备份
      save 60 10000 **如果10000个缓存更新,则1分钟之后进行备份
      
      1
      2
      3
    3. stop-writes-on-bgsave-error

      • Yes:如果save过程出错,则停止写操作
      • No:可能造成数据不一致
    4. rdbcompression

      • Yes:开启RDB压缩模式
      • no: 关闭,会节约CPU的损耗,但是文件比较大,类比nginx
    5. Rdbchecksum

      • Yes:使用CRC64算法对RDB数据进行校对,有10%的性能损耗。
      • no:不校验

    # AOF模式

    RDB可能会丢失最后一部分缓存数据,但是缓存也无所谓,丢了就丢了。但是如果想要追求redis数据的完整性,那么还是会考虑去使用AOF。

    # 特点:

    • 以日志的形式来记录用户的写操作,读操作不会进行记录。
    • 日志文件以追加的形式,而非修改的形式
    • Redis的aof恢复其实就是把追加的文件从头到尾进行读取,然后执行写操作。

    # 优点:

    1. AOF更加耐用,可以以秒级别为单位进行备份,如果发生问题,也只是会丢失最后一秒的数据,大大增加了可靠性和数据的完整性。所以AOF可以每秒备份一次,使fsync操作。
    2. 以log形式追加,如果磁盘满了,会执行redis-check-aof工具。
    3. 当数据量太大的时候,redis会在后台自动重写aof。当redis继续把日志追加到老的文件中去的时候,重写也是非常安全的,不会影响客户端的读写操作。
    4. AOF日志包含的所有的写操作,会更新利于redis进行解析恢复。

    # 缺点:

    1. 相同的数据,同一份数据,AOF的数据会比RDB的数据来得大。
    2. 针对不同的同步机制,AOF会比RDB慢,因为AOF每秒都会备份做写操作,这样相对于rdb来说就略低。每秒备份fsync没有问题,但是如果客户端每一次写入就做一次fsync的话,那么redis的性能就会下降。
    3. AOF发生过bug,就是数据恢复的时候数据不完整,这样显得AOF就比较脆弱,容易出bug,因为AOF没有RDB这么简单,但是为了防止bug的产生,AOF就不会根据旧的指令去重构,而是根据当时缓存中存在的指令进行重构,这样就更加健壮和可靠了。

    # 配置:

    1. AOF默认关闭,yes可以开启

      appendonly no

    2. AOF的文件名

      appendfilename "append only.aof"

    3. #no:不同步 #everysec:每秒备份,推荐使用 #always:每次操作都会备份,安全并且数据完整,但是慢,性能差

      appendfsync everysec

    4. 重写的时候是否要同步,no可以保证数据安全

      no-appendfsync-on-rewrite no

    5. 重写机制:避免文件越来越大,自动优化压缩指令,会fork一个新的进程去完成重写动作,新进程里的内存数据会被重写,此时旧的aof文件不会被读取使用,类似于RDB。当AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m,满足两者则触发重写。

      auto-aof-rewrite-percentage 100

      auto-aof-rewrite-min-size 64m

    # 到底采用RDB还是AOF呢?

    1. 如果能接受一段时间缓存丢失,那么可以使用rdb
    2. 如果你对实时性的数据比较在意,那么就用aof
    3. 使用RDB和AOF结合一起做持久化,RDB做冷备,可以在不同时期对不同版本做恢复,AOF做热备,保证数据仅仅只有1秒的损失。当AOF破损不可用了,那么在用RDB进行恢复,这样就做到了两者的相互结合,就是说Redis恢复会先加载aof,如果有问题会再加载RDB,这样就达到了冷热备份的目的
    上次更新: 2022/11/30, 00:06:25
    Redis操作集合
    Redis进阶

    ← Redis操作集合 Redis进阶→

    最近更新
    01
    让大龄程序员欲罢不能的事儿
    09-23
    02
    运营明明设置了活动开始时间,为什么到点没生效?聊聊动态定时任务
    07-30
    03
    不是,大哥,咱这小门小户的,别搞我CDN流量啊
    07-25
    更多文章>
    Theme by Vdoing | Copyright © 2020-2024 Kitty Daddy | License
    • 跟随系统
    • 浅色模式
    • 深色模式
    • 阅读模式