Redis持久化

1. 持久化的作用
   
   • redis所有数据保存在内存中,对数据的更新将异步地保存到磁盘上
2. 持久化方式
   
   1. 快照
   2. 写日志

3. redis-RDB(snapshotting)

   1. 
      

   2. 触发机制

      1. save(同步)

         1. redis>save
             ok
         
         2. 由于是同步命令,如果save执行很慢会造成redis的阻塞。
         
         3. 文件策略
             如果存在老的RDB文件,就替换
         
         4. 复杂度 O(n)

      2. bgsave(异步)

         1. redis>bgsave
            Background saving started
          2. 会执行redis的fork(函数)，产生一个子进程来进行持久化操作

         命令	save	bgsave
         IO类型	同步	异步
         阻塞	是	是(阻塞发生在fork)
         复杂度	O(n)	O(n)
         优点	不会消耗额外内存	不阻塞客户端命令
         缺点	阻塞客户端命令	需要fork,消耗内存

      3. 自动

         配置 seconds changes
         save    900    1
         save    300    10
         save    60     10000
         默认以上情况都会自动进行RDB持久化
         

   3. 配置

      save    900    1
      save    300    10
      save    60     10000
      dbfilename dump.rdb   (rdb文件名字)
      dir ./   (rdb文件位置)
      stop-writes-on-bgsave-error yes  (如果bgsave发生错误是否停止写入)
      rdbccompression  yes (rdb文件是否采用压缩模式)
      rdbchecksum yes   (是否采用校验模式)

   4. 最佳配置

      不采用默认自动RDB
      dbfilename dump-${port}.rdb   (文件名添加端口号方便区分)
      dir /bigdiskpath              (持久化文件存储在足够大的位置)
      stop-writes-on-bgsave-error yes
      rdbccompression  yes
      rdbchecksum yes

   5. 触发机制-不容忽略方式
      
      1. 全量复制 (之后的blog会添加)
      2. debug reload
      3. shutdown
4. RDB总结
   
   1. RDB是Redis内存到硬盘的快照,用于持久化
   2. save通常会阻塞Redis
   3. bgsave不会阻塞Redis,但是会fork新进程
   4. save自动配置满足任一项就会被执行
   5. 有些触发机制不容忽视

5. Redis-AOF(append-only-file)

   1. RDB存在的问题
      
      1. 耗时,耗性能
      2. 不可控,容易丢失数据
   2. AOF运行原理-创建
      
      • 保存命令
   3. AOF的三种策略
      
      1. always
      2. everysec
      3. no

   4. 三种策略比较

      命令	always	everysec	no
      优点	不丢失数据	每秒一次fsync,丢一秒数据	不用管
      缺点	IO开销较大,一般的sata盘只有几百TPS	丢一秒数据	不可控

   5. AOF重写

      1. 
         
         1. 作用
         2. 减少磁盘占用量
         3. 加快恢复速度

      2. AOF重写实现的两种方式

         1. bgrewriteaof

            类似RDB的bgsave
            
            redis>bgrewriteaof
            ok
            
            redis会fork一个子进程进行AOF的重写
            

         2. AOF重写配置

            配置:
            配置名                         含义
            auto-aof-rewrite-min-size      AOF文件重写需要的尺寸
            auto-aof-rewrite-percentage    AOF文件增长率
            
            统计:
            统计名                     含义
            aof_current_size         AOF当前尺寸(单位:字节)
            auto_base_size              AOF上次启动和重写的尺寸(单位:字节)

         3. 重写条件

            自动触发时机:(需要同时满足)
            1. aof_current_size > auto-aof-rewrite-min-size
            
            2. (aof_current_size - auto_base_size)/auto_base_size > auto-aof-rewrite-percentage 

      3. 配置

         appendonly yes   (AOF开关)
         appendfilename "appendonly-${port}.aof"   (AOF文件名称)
         appendfsync everysec   (每秒执行一次持久化操作)
         dir /bigdiskpath
         no-appendfsync-on-rewrite yes   (当执行重写时是否阻止调用fsync)
         auto-aof-rewrite-percentage 100   
         auto-aof-rewrite-min-size 64mb  (AOF重写的最小文件大小)

RDB与AOF

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定
轻重	重	轻

RDB最佳策略

1. “关”
2. 集中管理
3. 主从,从开

AOF最佳策略

1. “开”:缓存和存储
2. AOF重写集中管理
3. everysec

最佳策略

1. 小分片
2. 缓存或存储
3. 监控(硬盘,内存,负载,网络)
4. 足够的内存