Redis集群方案-主从复制-哨兵模式-分片集群

Redis集群方案

  • 主从复制
    • 全量同步
    • 增量同步(slave重启或者后期数据变化)
  • 哨兵模式
    • 服务状态监控
    • 哨兵选主规则
  • 分片集群
    • 哈希槽

Redis集群方案-主从复制-哨兵模式-分片集群_第1张图片

主从复制

单节点的Redis的并发能力是有上线的,要进一步提高redis的并发能力,就需要搭建主从集群,实现读写分离,下面我们来看一张图
Redis集群方案-主从复制-哨兵模式-分片集群_第2张图片
下面我们再来聊聊主从数据的同步的流程

全量同步

Redis集群方案-主从复制-哨兵模式-分片集群_第3张图片

全量同步:首先slave节点发起数据同步的请求,然后master先去检测这个slave是不是第一次进行数据同步,如果是则进行全量同步,master执行bgsave生成RDB快照文件,然后将快照文件发给slave,slave加载快照文件,如果master在发送快照文件的同时又有命令在执行的话就会生成一个 baklog文件,同时会将这个log文件发送给slave,这样就是进行全量同步的全部流程了,还有一个地方要特别记录一下,就是master是如何判断slave是否是第一次同步呢? 这里还需要再介绍个东西replid,在同步之前,只需要去判断一下这个replid是否和master一致就行,如果不一致的话说明就是第一次同步,此时将进行全量同步,当然在同步之后也会将slave的replid与master同步
在这里插入图片描述

增量同步(slave重启或者后期数据变化)

增量同步:这个同步流程的前面步骤和全量同步是类似的,首先slave发起同步的请求,判断replid是否和master节点的replid一致,如果一致则进行增量同步,然后主节点还会去获取一下从节点的offset值,举一个例子:如果从节点的offset为30,而主节点的offset值为60,那么此时主节点就只需要将30-60之间的数据发送给从节点进行同步即可

哨兵模式

哨兵的作用和结构如下:
监控:sentinel会不断检查master和slave是否按照预期工作
自动故障恢复:如果master故障,sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
通知:sentinel充当redis客户端的服务发现来源,当集群发送故障转移时,会将最新信息推送给redis客户端

服务状态监控

Sentinel基于心跳检测服务状态,每隔一秒向集群的每个实例发送ping命令:
如果某一个Sentinel节点发现某实例未在规定时间响应,则认为该实例是主观下线
若超过指定数量的Sentinel都认为该实例主观下线,则该实例客观下线
Redis集群方案-主从复制-哨兵模式-分片集群_第4张图片

哨兵选主规则

首先判断主与从节点断开时间长短,如超过指定值就排除该从节点(比如某一个slave与master断开了特别长的时间,那么我们就可以排除掉这个slave)
然后判断从节点的slave-priority值,越小优先级越高
如果果slave-prority一样,则判断slave节点的offset值,越大优先级越高
最后是判断slave节点的运行id大小,越小优先级越高。

分片集群

先介绍一下分片集群的结构:
Redis集群方案-主从复制-哨兵模式-分片集群_第5张图片
分片集群的特点:
集群中有多个master每个master保存不同的数据
每个master都可以有多个slave节点
master之间通过ping监测彼此健康状态
客户端请求可以访问集群任意节点,最终都会被转发到正确的节点

哈希槽

前面我们说到,分片集群有一个特点,客户端的请求可以访问集群任意节点,并且最终都会被转发到正确的节点,这个特点其实就是通过哈希槽来实现的,下面我们来介绍一下有关哈希槽的一些东西

Redis集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置到哪个槽,集群中的每个节点负责一部分哈希槽
Redis集群方案-主从复制-哨兵模式-分片集群_第6张图片

你可能感兴趣的:(Redis,redis,java,数据库)