1 Redis持久化
Redis数据一般放在内存，但是考虑突然断电等情况。会放在硬盘上面。等服务器重启之后会重新放在内存。
1.1Rdb持久化(可接受在一段时间内丢失数据)
1.RDB:每隔一段时间，把内存中的数据写入磁盘的临时文件，作为快照，恢复的时候把快照文件读进内存。如果宕机重启，那么内存里的数据肯定会没有的，那么再次启动redis后，则会恢复。
2.备份与恢复
内存备份->磁盘临时文件
临时文件-->恢复到内存
3. RDB优劣势
●优势
1.每隔一段时间备份，全量备份
2.灾备简单，可以远程传输
3.子进程备份的时候，主进程不会有任何io操作(不会有写入修改或删除)，保证备份数据的的完整性
4.相对AOF来说，当有更大文件的时候可以快速重启恢复
5.适合大规模的数据恢复。
6.如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
●劣势
1.发生故障是，有可能会丢失最后一次的备份数据
2.子进程所占用的内存比会和父进程一-模- -样，如会造成CPU负担
3.由于定时全量备份是重量级操作，所以对于实时备份，就无法处理了。
4.数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
5 .备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。所以要考虑到大概两倍的数据膨胀性。
6. RDB的配置
保存位置，可以在redis.conf自定义: /user/loca/redis/working/dump.rdb
●设置 下图说明：至少改一个key，900秒备份一次。至少改10个key 300秒备份一次。至少改10000key 60秒备份一次。
1.2Aof持久化(更高的缓存一致性)
●优势
1. 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
2. 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
3. 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
4. AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。
●劣势
1.对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
2.根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。
●设置
appendfsync always：总是写入aof文件，并完成磁盘同步
appendfsync everysec：每一秒写入aof文件，并完成磁盘同步
appendfsync no：写入aof文件，不等待磁盘同步。
可见，从持久化角度讲，always是最安全的。从效率上讲，no是最快的。而redis默认设置进行了折中，选择了everysec。
no-appendfsync-on-rewrite：
参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？在linux的操作系统的默认设置下，最多会丢失30s的数据。
