关于redis持久化的介绍

• redis持久化重要说明

• redis数据存储模式只有两种
  
  • cache-only
    
    • 只做为“缓存”服务，数据均在内存中，不持久化数据，服务停掉则数据全部丢失，且无恢复方法，高速但安全性低；
  • persistence
    
    • 数据不只是在内存中，还会以配置的持久化方式持久化到磁盘中，保证服务停止后数据还可以恢复。
    • 持久化方式选择
      
      • Redis DataBase(简称RDB)：默认开启该种方法持久化数据
        
        • 在某个条件满足后触发持久化操作，也称为一次快照(snapshot)操作，将所有数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复的效果。
        • snapshot触发的时机，是有”间隔时间”和”变更次数”共同决定，同时符合2个条件才会触发snapshot,否则“变更次数”会被继续累加到下一个“间隔时间”上。
        • snapshot过程是启动一个独立的子进程完成，故并不阻塞客户端请求。snapshot首先将数据写入临时文件，当成功结束后，将临时文件重名为dump.rdb。
        • rdb优缺点说明
          
          • 优点
            
            • 文件紧凑
            • 形式简单即单rdb文件
            • 由子进程完全独立搞定对主进程无影响
            • 恢复速度快
          • 缺点
            
            • 每次保存都是保存一个完整数据集的操作，持续时间可长可短，对丢失数据控制力不佳。
            • 若数据量过大，造成CPU和IO压力大，会影响主线程服务性能。
      • Append-only file (简称AOF)
        
        • 将”写操作+数据”以格式化指令的方式追加到操作日志文件的尾部,”日志文件”保存了历史所有的操作过程
        • 当server需要数据恢复时，可以直接replay此日志文件，即可还原所有的操作过程。
        • 由于aof操作是发生在后台异步线程执行，可以采用no文件模式同步(交给操作系统策略同步)、每秒钟fsync同步一次、每个写入发生时fsync同步一次，默认为每秒同步一次。
        • aof也不是绝对无数据丢失的：aof是写入内存cache，由后台线程按照aof策略执行fsync，极端情况下依然会丢失相应的数据。
        • aof优缺点说明
          
          • 优点
            
            • 数据持久化更及时、效果更好
            • 尾部追加方式，且为后台线程执行，效果很好，亦不影响主线程服务性能。
            • 自动进行aof日志重写和替换，达到适时瘦身的效果。
            • 日志文件为文本形式，易读易维护易修复。
          • 缺点
            
            • aof日志文件体积一般比rdb方式要大。
            • 在数据恢复时，aof的恢复速度一般是慢于rdb。