持久化
RDB和AOF是可以共存的，备份时，先备份的为AOF文件
在备份恢复时，假设AOF文件有问题（有些错误的命令，或者因为上次备份时未完全写全），出现文件破损，Redis是有自动修复文件的，会将错误的命令删除
RDB（Redis Data Base）<br>
存储方式<br>
就是每隔时间段会将内存中的数据快照写入到磁盘，然后恢复的时候直接将快照恢复到Redis<br>
整个过程，主进程不进行IO操作，会覆盖之前的文件，RDB会存在数据丢失最后一次的情况，对数据要求性不高的话可以使用<br>
保存的是Rdb.dump文件<br>
存储触发条件<br>
save <秒数> <变更次数>
优势
适合大规模数据恢复
对数据的完整性和一致性要求不高<br>
劣势
因为是一段时间内备份一次数据，所以可能会存在丢失最后一次数据的可能性
由于备份时是需要Fork一个新的进程去处理，所以在资源方面是也需要双份的<br>
总结
Rdb在保存文件时，父进程唯一要做的就是fork出一个子进程，事情全部使用子进程来处理，可以最大化Redis的性能，
与AOF相比，由于不是一条一条语句备份，所以会比RDB快一些
AOF（Appen Only File）<br>
存储方式
以日志的形式记录每一次写的操作命令，恢复时也通过命令恢复
Rewrite<br>
概念<br>
就是当文件过大时，会对内容进行压缩，只保留可恢复数据的最精简指令集<br>
重写原理<br>
其实是新Fork了一个子进程，并没有去读旧的aof文件，而是重新整理出一份命令指令<br>
auto-aof-rewrite-percentage 100 100% 一倍<br>auto-aof-rewrite-min-size 64mb 重写文件日志大小（一般3G起步）<br>
配置策略
appendonly 是否开启aof
appendfilename 名字
appendfsync 追加方式<br>
always<br>
同步追加、数据完整性较好，但性能消耗过大
EverySec默认<br>
异步追加、间隔一秒、那么就存在一秒的数据丢失<br>
NO<br>
如何选择
如果对数据完整性不高，而且数据又很多，而且又追求效率，那么可以使用RDB<br>
如果只做缓存的话，可以都不选择使用
建议两种都选用 也不要仅仅只使用AOF来作为唯一方式，因为RDB更适合于数据库备份<br>
用RDB时，只在从机器上持久化RDB文件，时间间隔也不要太短，15分钟差不多了，而且值保留Save 900 1规则即可
用AOF时，对重写基础值大小可以更改为5G左右，64太小了
如果不用AOF 仅靠主从复制也可以实现高可用，代价是如果主从同时停掉，则会丢失10多分钟的数据，恢复时也会比较两个RDB文件，恢复较新的文件
总结
Rdb是全量持久化、AOF是增量持久化，因为RDB比较耗时，不够实时，停机时会导致大量数据丢失，所以一般配合AOF使用，先恢复RDB的内存数据，在恢复最近的AOF命令<br>
发布和订阅机制
一种进程间的通信模式
类似于消息机制，pub推送 sub接收命令<br>
主从复制
一主二仆
机制
丛机会从头到尾复制主机的数据
只有主机才能写，丛机无法写入
假设主机挂了之后，丛机还是从机，不会由从变主，主机恢复后还是主机身份
如果从机挂了之后，需要重新连接进主机，不然不会变成原来的主机<br>
反客为主 salveof no one
就是与其他数据库脱离关系，变身为主机
哨兵模式
概念
哨兵模式就是监控模式
假设主机挂了，会选取出新的主机，可理解为自动 salveof no one
主机从新启动后，会被哨兵监控住变更成从机<br>
配置文件<br>
sentinel.conf<br>
