redis的持久化策略

　　redis的持久化方式有俩种，持久化策略有4种：
　　RDB（数据快照模式），定期存储，保存的是数据本身，存储文件是紧凑的
　　AOF（追加模式），每次修改数据时，同步到硬盘(写操作日志)，保存的是数据的变更记录
　　如果只希望数据保存在内存中的话，俩种策略都可以关闭
　　也可以同时开启俩种策略，当Redis重启时，AOF文件会用于重建原始数据RDB
　　RDB定时备份内存中的数据集。服务器启动的时候，可以从 RDB 文件中恢复数据集。
　　优点
　　存储的文件是紧凑的
　　适合用于备份，方便恢复不同版本的数据
　　适合于容灾恢复，备份文件可以在其他服务器恢复
　　最大化了Redis的性能，备份的时候启动的是子线程，父进程不需要执行IO操作
　　数据保存比AOF要快
　　缺点
　　如果Redis因为没有正确关闭而停止工作是，到上个保存点之间的数据将会丢失
　　由于需要经常fork子线程来进行备份操作，如果数据量很大的话，fork比较耗时，如果cpu性能不够，服务器可能是卡顿。属于数据量大的时候，一个服务器不要部署多个Redis服务。
　　创建快照有以下5种形式：
　　客户端发送BGSAVE指令，服务端会fork一条子线程将快照写入磁盘
　　客户端发送SAVE指令，服务端在主线程进行写入动作。一般不常使用，一般在内存不够去执行BGSVAE的时候才用
　　设置了SAVE配置项，如SAVE 300 100，那么当＂300秒内有100次写入＂时，Redus会自动触发BGSAVE命令。如果有多个配置项，任意一个满足，都会触发备份
　　Redis通过SHUTDOWN命令接收到关闭服务器的请求、或者TERM信号时，会执行SAVE命令，这时候会阻塞所有客户端，不在执行客户端发送的任何命令
　　当一个Redis服务器连接另外一个Redis服务器，并像对方发送SYNC命令开始一次复制操作时，如果主服务器目前没有在执行BGSAVE操作，或者主服务器刚刚执行完，那么主服务器就会执行GBSAVEAOF(append only file)
　　AOF记录服务器的所有写操作。在服务器重新启动的时候，会把所有的写操作重新执行
　　一遍，从而实现数据备份。当写操作集过大（比原有的数据集还大），Redis 会重写写操作集。
　　优点
　　- 使用AOF模式更加的灵活，因为可以有不同的fsync策略
　　- AOF是一个日志追加文件，所有不需要定位，就算断电也没有损坏问题，哪怕文件末尾是一个写到一半的命令，redus-check-aof工具也可以很轻易的修复
　　- 当AOF文件很大的，Redis会自动在后台进行重写。重写是决对安全的，因为Redis是继续往旧的文件里面追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦创建完成，Redis就会切换到新文件，开始往新文件进行追加操作
　　- AOF包含一个又一个的操作命令，易于理解和解析
　　缺点
　　对于同样的数据集，AOF文件通常要大于RDB文件
　　AOF可能比RDB要慢，这取决于fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭sfync，即使在很高的负载下也和RDB一样快。不过，即使在很大的写负载情况下，RDB还是能提供很好的最大延迟保证
　　AOF1通过递增的方式更新数据，而RDB快照是从头开始创建，RDB会更健壮和稳定（所以适用于备份），官网建议。
　　RDB持久化凡是能够在指定的时间间隔对数据进行快照存储。
　　AOF持久化方式记录每次对服务器写的操作。当服务器重启时，会重新执行这些命令来恢复数据。AOF命令以redis协议追加保存每次写的操作到文件末尾。
　　Redis还能对AOF文件进行后台重写，使得AOF文件体积不至于过大。只做缓存
　　如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化的方式。同时开启两种持久化的方式。
　　在这种情况下。当redis重启时候会优先AOF文件来恢复数据原始数据。因为AOF保存的数据更加的完整。那要不要只使用AOF呢。我建议还是不要。因为RDB更加适合用于备份数据库（AOF不断变化不好备份），快速重启，而且不会对AOF可能存在潜在的BUG.只能留着作为万一的手段。