Redi 持久化,主从同步,哨兵

Redis持久化

redis持久化,整体来说是分为两种: RDB和AOF,即时间快照和文件追加指令的方式.在redis4.0版本及以后推出了混合持久化的方式,即结合了RDB和AOF两种持久化方式的优点推出的一种新的持久化的方式.
RDB: 按照配置的某种规则(例如 save 3 60 即60秒内有三次更新操作,就持久化到硬盘),以一定的时间频率,把当前内存中数据保存到硬盘中的文件,默认的文件名dump.rdb,此操作是通过fork一个子进程来进行的,可以通过配置文件中的dbfileName指定,rbd文件是一个二进制文件,里面的内容以二进制的形式保存,其优点是结构紧凑,加载快,节省空间,其缺点就是会丢失一部分数据,容灾的效果不好
AOF: 文件追加的方式,即把redis接收到的指令,按照resp(redis simple protocol redis简单协议)写到aof文件中,即aof文件就是redis接收到的一系列的指令集,开启aof 需要在配置文件中把appendonly设置为yes,在redis恢复时,把aof文件中的指令重放一下,恢复数据.aof 持久化可以配置刷盘的规则即appendfsync 有三种选项可选no,always,everysec分别为不刷盘,由操作系统自行调度;每一次操作都刷盘,虽然能够保证不丢失数据,但是会影响redis的吞吐性能;每一秒种,刷盘,redis默认的配置,兼顾了数据的安全和性能的选项,随着系统的运行,每一秒种都往aof文件中追加指令,此时aof文件将会越来越大,所以这就需要对aof文件进行重写,即删除文件中一些已经没有用的指令.对文件进行瘦身.aof 方式其优点是数据的安全性高,仅会丢失一秒钟的数据,aof文件可读性高,可以根据需要修改,但其缺点是体积大,加载慢,不节省空间
混合持久化: 开启混合持久化,需要在配置文件中把aof-use-rdb-preamble选项设置为yes,4.0版本以后默认是开启的,所谓混合持久化,就是在aof文件进行的重写的时候,把原有的全量数据指令以rbd二进制的格式进行存储,增量数据指令还是以aof resp协议的格式存储,及最终的aof文件有两部分组成,rbd+aof组成的一个大的aof文件 aof持久化重写的过程如下 : 重写过程

整个重写的过程利用了写时复制的特性,避免过程当中出现系统宕机,出现数据丢失的情况,混合持久化就是把其中的第一和第二步最后持久化成rdb文件.

主从同步

redis主从同步分为全量同步和增量同步.其中全量同步又可以分为无盘复制和磁盘参与的复制,默认是磁盘参与的,可以通过repl-diskless-sync选项开启,增量同步是通过主通过网络把指令发送到从里面执行,保持数据的统一.开启主从非常简单只需要在从的配置文件上加一行slaveof ip port的配置即可,在从开始向主请求数据同步时,会发送psync replicationId offset请求部分从同步,主会判断从发送过来的replicationId与自身的id 是否相同,相同则判断offset是否在自己backlog之内,如果不在则进行增量同步,否则则进行全量同步 过程如图:

全量同步过程:

增量同步:

哨兵(sentinel)

redis哨兵机制是建立在主从之上,其主要作用是负责主节点的发现,监测,故障转移.维护主节点的高可用,开启redis哨兵机制只需要在启动redis服务时,指定哨兵的配置文件,再跟上–sentinel即可 redis哨兵也可以集群部署.哨兵的主要配置如下:
sentinel monitor 主名称 ip port 认可主挂掉的数量
当某一个sentinel发现主挂掉时,此时主的状态为主观下线,当认可主挂掉的数量达到指定的配置时候,此时主将进入客观下线的状态,此时将会按照Raft算法在sentinel中选出一个leader,来执行故障转移
sentinel down-after-milliseconds 主名称 主响应的时间
sentinel 通过一定的频率向主发送ping进行心跳检测,主如果未在指定的时间返回pong,则sentinel认为主已经挂掉
故障转移过程如下:

总结

无论redis持久化,主从同步都是异步执行的,所以都存在丢失数据的窗口,并不能保证数据的完整性,redis哨兵在第一次客户端通过哨兵发现了主节点,并与主节点建立起了正常通信之后,然后当哨兵出现故障挂掉此时不会影响redis服务节点.