本文共 2714 字，大约阅读时间需要 9 分钟。

_._           _.-``__ ''-._      _.-``    `.  `_.  ''-._            .-`` .-```.  ```\/    _.,_ ''-._ (    '      ,       .-`  | `,    )      |`-._`-...-` __...-.``-._|'` _.-'|     |    `-._   `._    /     _.-'    |      `-._    `-._  `-./  _.-'    _.-' |`-._`-._    `-.__.-'    _.-'_.-'| |    `-._`-._        _.-'_.-'    |          `-._    `-._`-.__.-'_.-'    _.-' |`-._`-._    `-.__.-'    _.-'_.-'| |    `-._`-._        _.-'_.-'    |  `-._    `-._`-.__.-'_.-'    _.-'      `-._    `-.__.-'    _.-'          `-._        _.-'              `-.__.-'

redis持久化

redis有两种持久化方式，rdb和aof，

• 启动服务会默认优先加载aof备份文件进行恢复，
• 如果加载失败会出错，不会再加载rdb文件；
• 如果没有aof文件则直接加载rdb文件

RDB(redis database)

实现方式

• 在指定的时间间隔将内存中的数据集快照（Snapshot）写入磁盘(dump.rdb)
• 恢复时是将快照读入内存
• redis会单独创建一个子进程（Fork）进行持久化操作，主进程不进行任何IO操作

优点：

• 如果需要大规模数据恢复，并且对数据完整性不是非常敏感，则RDB方式比AOF方式更加适合

缺点：

• RDB最后一次执行持久化操作之后的数据可能会丢失
• Fork进程时会将内存中的数据克隆一份，造成2倍的内存压力

fork进程

复制一个与当前进程一样的进程，新进程的所有数据与原进程相同。

配置

• 相关配置在文件中的snapshotting块

• 持久化触发规则

save <seconds> <changes>

#   save 
    
    
     #   after 900 sec (15 min) if at least 1 key changed 15分钟1次save 900 1#   after 300 sec (5 min) if at least 10 keys changed 5分钟10次save 300 10#   after 60 sec if at least 10000 keys changed 1分钟1万次save 60 10000# 禁用持久化 空字符串或者不写save参数save ""
    
   

• 持久化文件名

# The filename where to dump the DBdbfilename dump.rdb# The working directorydir ./

• 其他

# 备份失败时停止写入操作stop-writes-on-bgsave-error yes# 压缩备份文件rdbcompression yes# 使用校验和rdbchecksum yes

手动备份

使用save、bgsave命令即可

127.0.0.1:6379> saveOK127.0.0.1:6379> BGSAVEBackground saving started

区别：

• save: 全部阻塞

• bgsave: 后台异步进行快照操作

注：使用其他一些命令也会触发备份，例如 flushAll等

数据恢复

将备份文件（dump.rdb）移动到redis安装目录并重启服务即可

AOF(Append Only File)

实现方式

• 以日志形式记录每个写操作
• 文件为appendonly.aof
  • 这个文件只允许追加，不允许修改
• redis启动服务后，会将日志文件里面的操作执行一遍完成恢复工作
• 在rdb和aof文件共存的状态下，redis会优先加载aof文件
  • 如果aof文件损坏，会导致加载失败
  • 可以使用redis-check-aof程序来检查aof文件
    • redis-check-aof --fix <filename>修复aof文件
• 优缺点：
  • 优点：
    • 数据完整性高
  • 缺点：
    • 速度慢

配置

• 位置:APPEND ONLY MODE

# aof开启，默认关闭appendonly no# aof文件名(default: "appendonly.aof")appendfilename "appendonly.aof"# 重写aof文件触发比例auto-aof-rewrite-percentage 100# 重写aof文件触发最小文件大小auto-aof-rewrite-min-size 64mb

• 同步策略 appendSync
  • 三种， always, everysec, no
    • always: 同步持久化，性能较差，数据完整性好
    • everysec: 每秒执行一次，异步
    • no: 不同步

#Appendsync 同步策略(默认:everysec)# 三种， always, everysec no# appendfsync alwaysappendfsync everysec# appendfsync no

数据恢复

• 开启aof
• 放置aof文件
• 重启服务

rewirte

• aof采用文件追加方式，会导致文件越来越大，为了防止文件过大带来的负面影响，引入了重写机制
• 文件达到一定大小就会对文件进行压缩，对内部文件进行精简
  • 默认配置是当aof文件大小是上次rewrite后大小的100%，且文件大于64M时触发

总结

• 因为rdb只用做后备用途，建议只在Slave主机上持久化RDB文件，而且只要15min备份一次就足够了
• 开启aof，在最坏的情况下也只会丢失不到2秒的数据，代价是带来了持续的io
• AOF的重写产生的数据写到新文件造成的阻塞是不可避免的，只要硬盘允许，应该尽量减少rewrite的频率。
  • 默认64M太小，可以设置到5以上。
• 如果不启用aof，使用Master-Slave Replication实现高可用性也可以。
  • 如果Master和Slave同时宕机，会丢失十几分钟的数据，启动脚本需要比较Master和Slave上的RDB文件，载入比较新的那个文件。

转载地址：https://console.blog.csdn.net/article/details/115189706 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！