Redis的持久化操作与集群

两部分1.Redis的持久化操作

           2.Redis的一主二仆，薪火相传，反客为主和哨兵模式

---

Redis持久化操作

AOF默认不开启（开启修改配置文件appendonly no 改为yes）

AOF和RDB同时开启，系统默认取AOF数据

RDB：在指定的时间间隔内将内存中的数据集快照写入磁盘

redis会单独创建一个子进程来进行持久化，会先将数据写入一个临时文件（紧凑的二进制文件），待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件

缺点：备份周期在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改

           Fork的时候，内存中的数据被克隆了一份 ，大致两倍的膨胀性需要考虑

           虽然redis在fork时使用了写诗拷贝技术，但是如果数据庞大是还是比较消耗性能

优点：适合大规模的数据恢复

           对数据完整性和一致性要求不高适合使用

           节省磁盘空间

           恢复速度快

AOF（Append Only File）：以日志的形式来记录每个写操作（增量保存），将redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件  redis4.0之后增加重写压缩操作 （不管中间繁复的操作 只汇聚成一个指令保存）

AOF数据恢复（appendonly.aof 日志遭到破坏 ）redis-check-aof --fix appendonly.aof

AOF同步频率设置

appendfsync always

始终同步，每次redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec

每秒同步，每秒记录日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

redis不主动进行同步，把同步时机交给操作系统

优点：备份机制更稳健，丢失数据概率更低

           可读的日志文本，通过操作AOF稳健，可以处理错误操作

缺点：比起RDB占用更多的空间（不仅要记录数据还要记录命令）

           恢复备份速度要慢

           每次读写都同步的话，有一定性能压力

           存在个别BUG，造成恢复不能

---

Redis集群

1.一主二仆

即一个主机 两个从机 主机进行写入 从机进行查询

主机宕机后 从机不会主动上位 会等待主机

主机又回来了后，主机新增记录，从机复制记录

一主二仆模式会实行复制原理 主从模式衍生

复制原理：

                  每次从机联通后，都会给主机发送sync指令
                  主机立刻进行存盘操作，发送RDB文件，给从机
                  从机收到RDB文件后，进行全盘加载
                  之后每次主机的写操作，都会立刻发送给从机，从机执行相同的命令

（注：每次成功联通后 首次是从机向主机发送请求 其余都是主机向从机发送）

命令  slaveof ip 端口     slaveof 127.0.0.1（主机ip） 6380（主机端口） 成为6380的从机

（注：slaveof命令再每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件。）

         在redis中 执行  info replication         查看此redis的主机/从机 

2.薪火相传(主从模式衍生):

上一个slave可以是下一个slave的Master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。

中途变更转向会清除之前的数据，重新建立拷贝最新的

风险是一旦某个slave宕机，后面的slave都没法备份  

 如何设置薪火相传模式：Redis主从复制(薪火相传模式 演示示例)——图解版_小志的博客的博客-CSDN博客_redis薪火相传

3.反客为主（手动使slave变成master）

哪怕这个slave变成了另外一个slave的master，但他的身份仍然是slave，也就是也就无法完成写操作。
如果在master没有关闭时这个slave要完成写操作，那可以执行slaveof no one（要手动执行）让其不再成为任何服务器的slave，从而成为其他slave的master，这也就是常说的反客为主。

4.哨兵模式（监控主机宕机后自动将slave变成master）

通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器
当哨兵监测到Redis主机宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他服务器，修改配置文件，让他们换主机（宕机的主机重新连接后会变为从机）

多哨兵模式
当一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此可以使用哨兵进行监控， 各个哨兵之间还会进行监控，这就形成了多哨兵模式。

（假设主服务器宕机，哨兵1先检测到结果，但是系统并不会马上进行failover过程，仅仅是哨兵1主观认为主服务器不可以用，这个现象称为主观下线，当后面的哨兵也检测到主服务器不可用，并且数量达到一定时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover故障转移操作。
操作转移成功后。就会发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这一过程称为  客观下线）

注：命令1.配置哨兵配置文件
sentinel   monitor  myredis  127.0.0.1   6379   1
                解释 ： sentinel  monitor （被监控的名称）  host  port    1
                 最后面的1是监测到主机宕机后，会投出1票