redis：持久化方案

Redis的两种持久化方案

• RDB:

  定期、以快照的形式保存一个 rdb文件（启动时自动加载，去恢复之前保存的数据）
  save 60 100 60s内发生了100次改变，则快照保存 每次生成的新的dump.rdb都会覆盖之前旧快照
  （默认开启RDB快照）–> 或者save、bgsave去手动触发

• 优点： 对性能影响小，redis在进行保存RDB快照时，会fork出子进程，几乎不影响处理客户端请求效率
  每次生成的快照可以保存到其他存储媒介中，来保证容灾恢复 使用RDB要比AOF的速度快
  缺点：快照通过配置定期生成，会造成数据的丢失
  如果数据量非常庞大且CPU不够强，redis在fork子进程会消耗非常大的时间，影响redis对外提供服务能力

• AOF
  redis会把每一个请求记录在一个日志文件。重启redis时，会把AOF文件记录的所有写操作顺序执行一遍。确保数据恢复到最新。AOF默认关闭，配置开启–>appendonly yes
  AOF提供了三种fsync配置，always/everysec/no，通过配置项[appendfsync]指定：
  1.appendfsync no：不进行fsync，将flush文件的时机交给OS（操作系统）决定，速度最快
  2.appendfsync always：每写入一条日志就进行一次fsync操作，数据安全性最高，但速度最慢
  3.appendfsync everysec：折中的做法，交由后台线程每秒fsync一次
  AOF持续记录写操作日志，会产生一些无用的日志，日志文件过大时，数据恢复的时间也就越长，redis提供了AOF 的rewrite功能，可以重写AOF文件，只保留能够把数据恢复到最新状态的最小写操作集。
  而AOF 的rewrite功能可以通过BGREWRITEAOF命令触发，也可以配置Redis定期自动进行：
  auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb（注：redis在每次AOF rewrite时，会记录完成rewrite的日志文件大小，当AOF日志文件大小在该基础上增涨100%后，自动进行AOFrewrite。同时如果增长的大小没有达到64mb，则不会进行rewrite。）

  Redis的数据持久化工作本身就会带来延迟，需要根据数据的安全级别和性能要求制定合理的持久化策略：
   1.AOF + fsync always的设置虽然能够绝对确保数据安全，但每个操作都会触发一次fsync，会对Redis的性能有比较明显的影响
   2.AOF + fsync every second是比较好的折中方案，每秒fsync一次
   3.AOF + fsync never会提供AOF持久化方案下的最优性能使用RDB持久化通常会提供比使用AOF更高的性能，但需要注意RDB的策略配置
   
   每一次RDB快照和AOF Rewrite都需要Redis主进程进行fork操作。fork操作本身可能会产生较高的耗时，与CPU和Redis占用的内存大小有关。根据具体的情况合理配置RDB快照和AOF Rewrite时机，避免过于频繁的fork带来的延迟
   Redis在fork子进程时需要将内存分页表拷贝至子进程，以占用了24GB内存的Redis实例为例，共需要拷贝24GB / 4kB * 8 = 48MB的数据。在使用单Xeon 2.27Ghz的物理机上，这一fork操作耗时216ms。
  

  优点：
  1、最安全，在启用appendfsync always时，任何已写入的数据都不会丢失，使用在启用appendfsync everysec也至多只会丢失1秒的数据
  2、AOF文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。
  3、AOF文件易读，可修改，在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。
  缺点：
  1、AOF文件通常比RDB文件更大
  2、性能消耗比RDB高
  3、数据恢复速度比RDB慢