Rdb：
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的snappshot快照，他恢复时是将快照文件直接读到内存中；redis会单独创建(fork)一个子进程，redis会单独创建一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化的文件，整个过程中，主进程是不进行IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高校，RDB的缺点是最后一次持久化的内容可能丢失。
Fork:Fork的作用是赋值一个与当前进程一样的进程，新进程的所有数据数值和原进程一样，但是是一个全新的进程，并作为原进程的子进；
Rdb保存的是dump.rdb文件。
如何触发快照：
I. 配置文件中默认的快照配置：冷拷贝后重新使用
II. 命令sava或者是bgsave
I. save：save只管保存，其他不管，全部阻塞
II. Bgsave：redis会在后台异步进行快照操作，快照同时还可以响应客户端请求，可以通过lastsave命令获取最后一次成功执行快照的时间
III. 执行flushall命令，也会产生dump.rdb文件，但其内部为空的，毫无意义
如何恢复：
将备份文件移动到redis安装目录并启动服务即可，config get dir获取目录
优势：
适合大规模的数据恢复，对数据完整性和一致性要求不高
劣势：
在一定间隔的时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改；
Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑；
如何停止rdb：
Redis -cli config set save””;
Aof：
以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来(读操作不记录)，只需追加文件但不可以改写文件，redis启动之初会读取文件重新构建数据，换言之，redis重启的话就是根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作；
Appendfsync：
No: 从不同步，表示等操作系统进行数据缓存同步到磁盘
Always：表示每次更新操作后手动调用fsnc()将数据写到磁盘，性能较差；
Everysenc：表示每秒同步一次；
No-appendfsync-on-rewrite：重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性；
异常恢复Redis-check-aof -fix appendonly.aof ;
Rewrite：Aof采用追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当Aof文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
重写原理：
Aof文件持续增长而过大时，会fork出一条新进程将文件重写，遍历新进程的内存数据，每条记录有一条Set语句，重写aof的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件
触发机制：
Redis会记录上次重写时的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且大于64M时同时触发；
Auto-aof-rewrite-min-size
优势：
No: 从不同步，表示等操作系统进行数据缓存同步到磁盘
Always：表示每次更新操作后手动调用fsnc()将数据写到磁盘，性能较差；
Everysenc：表示每秒同步一次；
劣势：
相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb；
Aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
AOF文件是一个只进行追加的日志文件，redis可以在aof文件体积变得过大时，自动的对其重写，aof文件有序地保存了对数据库的所有写入操作，这些写入操作以redis协议的格式保存。
对于相同的数据集来说，Aof文件的体积通常要大于rdb；
根据所使用的fsync策略，Aof的速度可能会慢于rdb；
同时开启两种持久化方式，将默认加载aof来恢复原始的数据(aof会有大量的I/O)，因为aof更完整，但是aof可能会有潜在的bug，rdb更适合用于备份数据库；
REDIS事务：
四种情形：
四种情景：
正常执行：
放弃事务：
全体连坐：
冤头债主
DISCARd：取消事务，放弃事务块内的所有命令
EXEC：取消事务；
MULTI：标记一个事物的开始
WATHCH：监控一个或多个key，如果事务执行之前这个key被其他命令改动，那么事务将被打断
UNWATCH：取消watch命令对所有key的监视；
redis的主从复制：
Master 主要为写slave主要为读
1. 配从库不配主库；
2. 从库配置：slaveof主库Ip主库端口
3. 修改配置文件细节操作
I. 拷贝多个redis.conf文件
II. 开启多个daemonize yes
III. Pid 文件名字
IV. 指定端口
V. Log文件名字
VI. Dump.rdb名字
4. 常用三招
I. 一主二仆 一台主机两台备机 info repalication
II. 薪火相传 上一个Slave可以是下一个Slava的Master，Slave同样可以接受其他Slaves的连接和同步请求，那么该Slave作为了链条中的下一个Master，可以有效减轻Master的写压力，中途变更转向会清楚之前的数据，以保证数据的一致性；SlaveOf
III. 反客为主 主机死了，可以让从机变为新主机，Slave noone
IV. 复制原理 Slaveof
V. 哨兵模式
监控 ，反客为主的自动版
能够从后台监控主机是否故障，如果故障了根据投票数自动将从库转化为主库
创建sentinel.cof文件， sentinel monitor 被监控数据库名字 1，
启动哨兵模式，原有的master重启回来，会成为Slave；
优点：一组sentinel可以监控多个Master；
缺点：由于写的操作都是先在Master上操作，然后同步更新到Slave上，可以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器的数量增加，也会更严重；