redis持久化的选择

 在实际生产环境中，根据数据量、应用对数据的安全要求、预算限制等不同情况，会有各种各样的持久化策略；如完全不使用任何持久化、使用RDB或 AOF的一种，或同时开启RDB和AOF持久化等。此外，持久化的选择必须与Redis的主从策略一起考虑，因为主从复制与持久化同样具有数据备份的功能， 而且主机master和从机slave可以独立的选择持久化方案。
 
  面对场景来讨论持久化策略的选择，下面的讨论也只是作为参考，实际方案可能更复杂更具多样性。

   1）如果Redis中的数据完全丢弃也没有关系（如Redis完全用作DB层数据的cache），那么无论是单机，还是主从架构，都可以不进行任何持久化。 

 2）在单机环境下（对于个人开发者，这种情况可能比较常见），如果可以接受十几分钟或更多的数据丢失，选择RDB对Redis的性能更加有利；     如果只能接受秒级别的数据丢失，应该选择AOF。  

 3）但在多数情况下，我们都会配置主从环境，slave的存在既可以实现数据的热备，也可以进行读写分离分担Redis读请求，     以及在master宕掉后继续提供服务。
 
     在这种情况下的做法是：        

master：完全关闭持久化（包括RDB和AOF），这样可以让master的性能达到最好；          

slave：关闭RDB，开启AOF（如果对数据安全要求不高，开启RDB关闭AOF也可以），并定时对持久化文件进行备份（如备份到其他文件夹，并 标记好备份的时间）；然后关闭AOF的自动重写，然后添加定时任务，在每天Redis闲时（如凌晨12点）调用bgrewriteaof。            

为什么开启了主从复制，可以实现数据的热备份，还需要设置持久化呢？      

 因为在一些特殊情况下，主从复制仍然不足以保证数据的安全，例如：master和slave进程同时停止：考虑这样一种场景，如果master和slave在同一个机房，则一次停电事故就可能导致master和slave机器同时关 机，Redis进程停止；如果没有持久化，则面临的是数据的完全丢失。        

master误重启：考虑这样一种场景，master服务因为故障宕掉了，如果系统中有自动拉起机制（即检测到服务停止后重启该服务）将master自 动重启，由于没有持久化文件，那么master重启后数据是空的，  slave同步数据也变成了空的；如果master和slave都没有持久化，同样会面临数据的完全丢失。需要注意的是，即便是使用了哨兵进行自动的主从切换，也有可能在哨兵轮询到master之前，便被自动拉起机制重启了。因此，应尽量避免“自动拉起机制”和“不做持久化”同时出现。如果需要最大限度需要数据无损：      

建议master开启aof，slave开启aof，开启aof需要cpu和磁盘性能保障。开启aof建议fsync同步刷盘使用everysec，自定义脚本在应用空闲时定时 做bgrewrite   

  4）异地灾备：上述讨论的几种持久化策略，针对的都是一般的系统故障，如进程异常退出、宕机、断电等，这些故障不会损坏硬盘。但是对于一些可 能导致硬盘损坏的灾难情况，如火灾地震，就需要进行异地灾备。      

例如对于单机的情形，可以定时将RDB文件或重写后的AOF文件，通过scp拷贝到远程机器，如阿里云；对于主从的情形，可以定时在master上执行 bgsave，然后将RDB文件拷贝到远程机器，  或者在slave上执行bgrewriteaof重写AOF文件后，将AOF文件拷贝到远程机器上。
 
     一般来说，由于RDB文件文件小、恢复快，因此灾难恢复常用RDB文件；异地备份的频率根据数据安全性的需要及其它条件来确定，但最好不要低于 一天一次。
 1、RDB虽然可以通过bgsave指令后台保存快照，但fork()子进程是有开销的，在内存数据集较大的情况下会占用很长的cpu时间，fork新进程时  这个复制是需要时间的，在服务器结点上测试，35G的数据bgsave瞬间会阻塞200ms以上，一般建议Redis使用内存不超过20g。    2、I/O消耗的问题     线上是在Slave节点开启rdb持久化，磁盘性能一般，1.2g的rdb文件持久化一分钟一次，  一次大概耗时30s左右，所以rdb的频率也不能太频繁，需要根据情况做好配置。
 
  3.AOF是追加写命令到aof文件的方式，优点是可以基本做到数据无损，缺点是文件增长较快，需要间歇性bgrewrite，bgrewrite也是一个既耗cpu又耗 磁盘IO的操作，  单cpu利用率最高可达100%，一般建议找几个空闲时段设置脚本来做bgrewrite。

持久化配置方案

1、企业级的持久化的配置策略
  save 60 10000：如果你希望尽可能确保说，RDB最多丢1分钟的数据，那么尽量就是每隔1分钟都生成一个快照，低峰期，数据量很少，也没必要  10000->生成RDB，1000->RDB，这个根据你自己的应用和业务的数据量，你自己去决定
 
  AOF一定要打开，fsync，everysec  auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%，上次的两倍  auto-aof-rewrite-min-size 64mb: 根据你的数据量来定，16mb，32mb
2、数据备份方案

  RDB非常适合做冷备，每次生成之后，就不会再有修改了 数据备份方案  

（1）写crontab定时调度脚本去做数据备份  

（2）每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份  

（3）每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份  

（4）每次copy备份的时候，都把太旧的备份给删了  

（5）每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去【crontab】

AOF常用配置总结
appendonly no：是否开启AOF
appendfilename "appendonly.aof"：AOF文件名
dir ./：RDB文件和AOF文件所在目录
appendfsync everysec：fsync持久化策略
no-appendfsync-on-rewrite no：AOF重写期间是否禁止fsync；如果开启该选项，可以减轻文件重写时CPU和硬盘的负载（尤其是硬盘），但是可能会丢 失AOF重写期间的数据；需要在负载和安全性之间进行平衡
auto-aof-rewrite-percentage 100：文件重写触发条件之一
auto-aof-rewrite-min-size 64mb：文件重写触发提交之一
aof-load-truncated yes：如果AOF文件结尾损坏，Redis启动时是否仍载入AOF文件