Redis持久化方式有两种：
（1）RDB
对内存中数据库状态进行快照，是默认的持久化方式。
（2）AOF
把每条写命令都写入文件，类似mysql的binlog日志。
持久化的数据的作用是用于重启后的数据恢复。Redis在重启进行恢复的时候，都会读取RDB或AOF文件，重新加载到内存中。如果同时启用了RDB和AOF方式，AOF优先，启动时只加载AOF文件恢复数据（甚至aof文件损坏或找不到）。RDB不建议开启，在数据集比较庞大时， fork() 可能会非常耗时，消耗内存造成服务器堵塞主进程。关闭RDB config set save。
RDB：
将Redis在内存中的数据库状态保存到磁盘里面，RDB文件是一个经过压缩的二进制文件dump.rdb，可通过conf文件dbfilename参数设置通过该文件可以还原生成RDB文件时的数据库状态。
RDB的生成方式：
（1）执行命令手动生成
有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE。
SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。
BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求。
创建RDB文件结束之前，客户端发送的BGSAVE和SAVE命令会被服务器拒绝。
（2）通过配置自动生成
可以设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。
可以通过save选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行BGSAVE命令。对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。
save 900 1 #服务器在900秒之内，对数据库进行了至少1次修改
save 300 10 #服务器在300秒之内，对数据库进行了至少10次修改
save 60 10000 #服务器在60秒之内，对数据库进行了至少10000次修改
那么只要满足以下三个条件中的任意一个，BGSAVE命令就会被执行。
当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件。这样在任何时候出现故障，Redis的RDB文件都总是可用的。
但也可以很明显的看到，RDB有它的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的。从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。
AOF：
在使用AOF持久化方式时，Redis会将每一个收到的写命令都通过Write函数追加到文件中，类似于MySQL的binlog。当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
AOF(Append-Only File)比RDB方式有更好的持久化性。
AOF文件刷新的方式，有三种
$ vim /redis_6379.conf
appendonly yes #启用AOF持久化方式
appendfilename appendonly.aof #AOF文件的名称，默认为appendonly.aof
# appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
# appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。
默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾。
注：如果是用config set配置完后。config rewrite写入配置文件中，下次重启时才会读取aof文件恢复数据。
AOF的完全持久化方式同时也带来了另一个问题，持久化文件会变得越来越大。
AOF重写：
比如我们调用INCR test命令100次，文件中就必须保存全部的100条命令，但要恢复数据库的状态其实文件中保存一条SET test 100就够了。
为了压缩AOF的持久化文件，Redis提供了bgrewriteaof命令。
收到bgrewriteaof命令后Redis将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件。
和快照的过程一样，在重写AOF文件时并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。
$ vim /opt/redis/etc/redis_6379.conf
no-appendfsync-on-rewrite no #在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size 64mb #当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
主从复制：
为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成。当master故障后，直接把slave改为master，其他的配置不需要修改，服务又可以正常使用。
- Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。
- Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据。
- ①从数据库向主数据库发送sync命令。
②主数据库接收sync命令后，执行BGSAVE命令（保存快照），创建一个RDB文件，在创建RDB文件期间的命令将保存在缓冲区中。
③当主数据库执行完BGSAVE时，会向从数据库发送RDB文件，而从数据库会接收并载入该文件。
④主数据库将缓冲区的所有写命令发给从服务器执行。
⑤以上处理完之后，之后主数据库每执行一个写命令，都会将被执行的写命令发送给从数据库。 - master的持久化RDB和replication的RDB互相独立，所以即使关闭了主节点的持久化RDB，主从复制并不会受影响。
- 在Redis2.8之前，主从断线或则重启之后再重连接，都需要做一次完整的sync操作（上边的5个步骤）。Redis2.8之后，会用一个psync来替换sync，只需要同步断线期间的记录。
切换过程：
在slave修改配置文件： #slaveof 192.168.77.211 12002
如果master设置了验证密码，还需修改： #masterauth passwd
设置slave为只读模式：#slave-read-only yes，2.6开始slaves默认read only。
重启redis，在查看主从信息：>info replication
Master不可用的情况下，停止Master。将Slave升级为Master，在命令行：>slaveof no one
要点：
持久化方式：
RDB(默认),AOF。如果同时启用了RDB和AOF方式，AOF优先，启动时只加载AOF文件恢复数据。
RDB：手动：save(阻塞), bgsave(backgroung save非阻塞)。自动：在配置文件中设置，可设置多个，满足任意一个即触发BGSAVE。
save 900 1 #服务器在900秒之内，对数据库进行了至少1次修改
save 300 10 #服务器在300秒之内，对数据库进行了至少10次修改
save 60 10000 #服务器在60秒之内，对数据库进行了至少10000次修改
AOF：在配置文件中设置
appendonly yes #启用AOF持久化方式
appendfilename appendonly.aof #AOF文件的名称，默认为appendonly.aof
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
以上如果是启动后通过config set配置，用config rewrite命令使其生效。
AOF重写：
AOF会使得持久化文件会变得越来越大。重写AOF是将整个内存中的数据库内容用命令的方式重写一个新的AOF文件。
$ vim /opt/redis/etc/redis_6379.conf
no-appendfsync-on-rewrite no #在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size 64mb #当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
主从复制：存量数据的复制通过RDB来完成，发出同步数据命令后会执行BGSAVE。持久化的RDB和replication的RDB是互相独立，所以即使关闭了主节点的持久化RDB，主从复制并不会受影响。处理完之后，之后主数据库每执行一个写命令，都会将被执行的写命令发送给从数据库。
