Redis详解（五）

持久化

• 将数据的更新异步保存在磁盘上，防止内存断电丢失数据
• 方式无非两种：打快照（直接存数据），写日志（保存写入和更新的命令）
  

RDB

• 将内存中的数据保存为二进制文件
  
• 三种触发保存的机制
  • 直接执行save命令
    
    • 这是一种同步命令，可能会引起阻塞
      
  • 使用bgsave异步保存，使用Linux的fork生成子进程
    
    • 文件策略和复杂度与save相同
      
  • 自动生成RDB，使用自定义的配置文件：
    
• 准备一组数据测试一下
  • 使用dbsize可以查看到有足够的key，info memory查看占用了900兆内存
    
  • 先测试save，在配置中注释掉自动生成RDB的内容
    
    
    • 查看data目录可以发现生成了400M作用的RDB文件（压缩）
  • 验证bgsave的异步
    • 在无需改动配置
      
      
    • 在客户端2执行任何操作不会阻塞，grep也可以找到生成的子进程，-v表示不看
    • 在data目录执行ll可以看到生成的临时文件temp.log
  • 验证自动生成，配置中打开save 60 5，60秒钟有5次改动就持久化
    • 需要重启：redis-cli shutdown，redis-server redis-6379.conf
    • 连接客户端，修改5次数据
    • 可以在日志查看：tail -f 6379.log，也生成了新的dump-6379.rdb，可以查看
• 小结
  

AOF

• RDB有什么问题
  • 耗时耗性能
    
  • 不可控，丢失数据；意外宕机，写命令的数据未保存
    
• AOF原理
  • 数据写入和更新的命令都会保存在AOF文件中
    
  • 需要恢复时，将AOF的命令加载一遍即可
    

三种策略

• always策略
  • 写命令先放入缓冲区，异步写入磁盘（高效）
    
  • always的意思是每条命令都异步写入（落盘）
• everysec策略
  • 每秒钟向硬盘写入一次
    
  • 有可能丢失一秒的数据
• no策略
  • 操作系统决定何时落盘
    
• 比较
  • 主要从数据丢失情况和开销方面权衡
    

AOF重写

• 很多命令可以化简再存储到AOF文件
  
• 可以减少硬盘占用量，加速恢复速度
• 两种重写方法
  • 1.使用bgrewriteaof命令
    
    • 并不是针对已经保存的AOF文件，而是直接对内存回溯
  • 2.使用配置自动触发
    
  • 需要满足两个配置的条件：
    
    • 应该除以一个固定值吧？不然启动重写的阈值越来越大？
• 完整重写流程：（以手动命令为例）
  
  • 3-1就是正常的子进程刷写命令到缓冲区，最后落盘
  • 3-2过程会将重写AOF期间的落到盘里的写命令append到新的AOF中，防止新旧数据不一致！
  • 基本配置如下：（包含自动重写机制）
    
  • appendonly 设置为yes表示开启AOF功能（因为是追加方式操作AOF）；会生成appendonly.aof文件
    • 文件格式
      
• 设置完毕后，我们可以执行“AOF重写”部分第一张图片中演示的语句，看看生成的新aof文件是否进行了简化！

对比

• RDB和AOF策略的对比
  
  • AOF的优先级较高！
  • RDB文件会压缩，不要觉得存数据体积就大！

最佳策略

• RDB最佳策略
  
• AOF最佳策略
  
• 最佳策略
  
• 实际部署的时候要根据场景选择！