Redis 持久化

• 持久化原因：
  客套话，redis基于内存的数据库，持久化数据到磁盘上，防止数丢失。
  
  
• 持久化方式：
  aof 文件追加方式 
   
  默认文件名是appendonly.aof。保存路径同 RDB持久化方式一致，通过dir配置指定。AOF的工作流程操作：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）
  1 所有的写入命令会追加到aof_buf（缓冲区）。
  2 aof缓冲区根据对应的策略向硬盘做同步操作。
  3 AOF文件逐渐增大，定期重写，达到压缩目的。{重写可手动触发或者自动触发}
  4 重启时，可加载AOF文件进行数据恢复
  优点：
     a 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。
     b 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。
     c 如果日志过大，Redis可以自动启用rewrite机制。
     d AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。
  缺点：
     a 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
     b 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。

• rdb数据快照方式
  将redis 存在内存中的数据以快照的形式保存在本地磁盘中。存了一份dump.rdb文件。
  此方式分为手动备份和自动备份两大类。
  手动备份：
     save 命令，用主线程进行同步存储，会阻塞redis服务器。
  　 bgsave 命令，由于是异步的，它不会阻塞主进程继续收集请求，它会在通过fork()系统调用创建一个子进程将数据转储保存在一个名为temp-<bgsave-pid>. rdb的临时文件中。当转储过程结
            束后，这个临时文件会被重命名为由参数dbfilename定义的名字覆盖并保存在dire指定的本地目录中。
  自动备份：
     a.修改配置项 save m n即表示在 m 秒内执行了 n 次命令则进行备份.
     b.当Redis 从服务器项主服务器发送复制请求时，主服务器则会使用 bgsave命令生成 rbd 文件，然后传输给从服务器.
     c.当执行 debug reload 命令时也会使用 save 命令生成rdb文件.
     d.当使用 shutdown 命令关掉服务时，如果没有启用 aof方式实现持久化则会采用bgsave的方式做持久化.同时shutdown后面可以加备份参数[nosave|save].
  
  优点：
     1.文件实现的数据快照，全量备份，便于数据的传输.比如我们需要把A服务器上的备份文件传输到B服务器上面，直接将rdb文件拷贝即可.
     2.文件采用压缩的二进制文件，当重启服务时加载数据文件，比aof方式更快.
  缺点:
     1.rbd采用加密的二进制格式存储文件，由于Redis各个版本之间的兼容性问题也导致rdb由版本兼容问题导致无法再其他的Redis版本中使用.
     2.时效性差，容易造成数据的不完整性.因为rdb并不是实时备份，当某个时间段Redis服务出现异常，内存数据丢失，这段时间的数据是无法恢复的，因此易导致数据的丢失.