Redis(3)-集群:主从复制、哨兵模式、Cluster

一、Redis主从复制


一般从节点提供读操作,主节点提供写操作。(对于读多写少的情况,可给主节点配置多个从节点,从而提高相应效率)

  • 主从复制是指主节点将当前的数据同步给从节点,后续如果有写命令也会持续发送给从节点,达到主从数据同步效果。


主从复制过程:

        (1)从节点执行slaveof[masterIP][masterPort],保存主节点信息。
        (2)从节点中的定时任务发现主节点信息,建立和主节点的Socket连接。
        (3)从节点发送ping信号,主节点返回Pong,两边能相互通信。
        (4)建立连接后,主节点将所有的数据发送给从节点(数据同步)。
        (5)主节点把当前的数据同步给从节点后,便完成了复制的建立过程。
        (6)接下来,主节点就会持续的把写命令发送给从节点,保证主从数据一致性。

详解数据同步的过程:

        Redis 2.8之前:
            使用sync[runId][offset]同步命令。Sync命令仅支持全量复制过程。
        Redis 2.8之后:
            使用psync[runId][offset]命令。Psync命令支持全量复制和部分复制。
            从节点发送psync[runId][offset]命令,主节点有三种响应:
                (1)FULLRESYNC:第一次连接,进行全量复制。
                (2)CONTINUE:进行部分复制。
                (3)ERR:不支持psync命令,进行全量复制。

全量复制和部分复制的过程:

  • (1)全量复制:用于初次复制或其他无法进行部分复制的情况,将主节点中的所有数据都发送给从节点,是一个非常重型的操作,当数据量较大的时,会对主从节点和网络造成很大的开销。

        具体步骤:
            1):从节点会发送一条同步命令。
            (比如Psync命令,Psync ? -1 表示要求master主机同步数据)
            2):主机会向从机发送runid和offset,因为slave并没有对应的offset,所以是全量复制。
            3):从机slave会保存主机master的基本信息。
            4):主节点收到全量复制的命令后,执行bgsave(异步执行),在后台生成RDB文件(快照),并使用一个缓冲区(称为复制缓冲区)记录从现在开始执行的所有命令。
            5):主机发送RDB文件给从机。
            6):发送缓冲区数据
            7):刷新旧数据。从节点在载入主节点的数据之前要先将老数据清除。
            8):加载RDB文件将数据库状态更新至主节点执行bgsave时的数据库状态和缓冲区数据的加载。
        

  • (2)部分复制:用于处理在主从复制中因网络闪断等原因造成的数据丢失场景。当从节点再次连上主节点后,如果条件允许,主节点会补发丢失数据给从节点。

        如果网络中断时间过长,造成主节点没有能够完整地保存中断期间执行的写命令,则无法进行部分复制,仍使用全量复制。

        具体步骤:
            1):如果网络抖动(连接断开 connection lost)
            2):主机master还是会写repl_back_buffer(复制缓冲区)
            3):从机slave会继续尝试连接主机
            4):从机slave会把自己当前run_id和偏移量传输给主机master,并且执行psync命令同步。
            5):如果master发现你的偏移量是在缓冲区的范围内,就会返回continue命令。
            6):同步了offset的部分数据,所以部分复制的基础就是偏移量offset。

备注:

  • 1.runId和offset是什么?

        runId:主服务器ID
        offset:从服务器最后接收命令的偏移量

  • 2.主从复制的时候有数据写入主节点会怎么处理?

            当主节点正在发送数据给从节点过程时,主节点响应写命令时,不但会把命令发送给从节点,还会写入复制积压缓冲区,用于复制命令丢失的数据补救(在增量复制时对于丢失的数据进行补救)。
            当从节点同步主节点数据完成后,主节点将缓冲区的数据继续发送给从节点,用于部分复制。
        


 二、Redis哨兵模式(Sentinel)


哨兵模式是一个分布式系统,用于对主从结构中的每一台服务器进行监控,当主节点出现故障后通过投票机制挑选新的主节点,并且将所有的从节点连接到新的主节点上。

Redis Sentinel最小配置是一主一从,并且可以用来管理多个Redis服务器。


        哨兵模式主要是为了弥补主从切换时需要人工干预。
        主从切换技术的方法:当主服务器宕机后,需要手动把一台服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。

哨兵模式的功能:

        主节点存活检测、主从运行情况检测、自动故障转移、主从切换。


哨兵模式可以执行以下四个任务:

        (1)监控:
            不断检查主服务和从服务器是否正常运行。
        (2)通知:
            当被监控的某个Redis服务器出现问题。Sentinel通过API脚本向管理员或者其他应用程序发出通知。
        (3)自动故障转移:
            当主节点不能正常工作时,Sentinel会开始一次自动的故障转移操作。
            它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点,并将其他的从节点指向新的主节点。这样就可以避免人工干预了。
        (4)配置提供者:
            在Redis Sentinel模式下,客户端应用在初始化时连接的Sentinel节点集合,从中获取主节点的信息。

哨兵的工作原理:

(1)发送PING命令:每个Sentinel以每秒一次的频率,向它所知的主服务器、从服务器以及其他Sentinel实例发送一个PING命令。

(2)标记主观下线:如果一个实例距离最后一次有效PING命令的时间超过down-after-milliseconds所指定的值,那么这个实例会被Sentinel标记为主观下线

(3)确认主服务为主观下线:如果一个主服务被标记为主观下线,那么正在监视这个主服务的所有Sentinel节点都去确认主服务的确进入了主观下线状态。


(4)主观下线升级为客观下线:如果一个主服务器被标记为主观下线,并且有足够数量的Sentinel(至少要达到配置文件指定的数量)在指定的时间范围内同意这一判断,那么这个主服务被标记为客观下线


(5)缩短发送INFO时间,加速更新master和slave节点:当一个主服务器被Sentinel标记为客观下线时,Sentinel向下线主服务器和所有从服务发送INFO命令的频率,会从10秒一次改为每秒一次。

        在一般情况下,每个Sentinel会以每秒一次的频率,向它已知的所有主服务器和从服务器发送INFO命令。
        通过解析info命令中的Replication信息,sentinel就可以获取到所有的最新的master和slave节点。

(6)选出新的主节点,进行数据复制:Sentinel和其它Sentinel协商主节点的状态,如果主节点处于SDOWN状态,则投票自动选出新的主节点。将剩余的从节点指向新的主节点进行数据复制。


(7-1)协商选出新主节点不成:当没有足够数量的Sentinel同意主服务器下线时,主服务器的客观下线状态就会被移除。
(7-2)主服务器突然诈尸:当主服务器重新向Sentinel的PING命令返回有效回复时,主服务器的主观下线状态就会被移除

三、Redis Cluster


概括:

Redis Cluster。一组Redis Cluster是由多个Redis实例组成。

Redis-Cluster采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。

        官方推荐我们使用6实例,其中3个为主节点,3个为从结点。一旦有主节点发生故障的时候,Redis Cluster可以选举出对应的从结点成为新的主节点,继续对外服务,从而保证服务的高可用性。

        那么对于客户端来说,知道知道对应的key是要路由到哪一个节点呢?原来,Redis Cluster 把所有的数据划分为16384个不同的槽位,可以根据机器的性能把不同的槽位分配给不同的Redis实例,对于Redis实例来说,他们只会存储部门的Redis数据,当然,槽的数据是可以迁移的,不同的实例之间,可以通过一定的协议,进行数据迁移。

其结构特点:

1、所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。

2、节点的fail是通过集群中超过半数的节点检测失效时才生效。

3、客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

4、redis-cluster把所有的物理节点映射到[0-16383]slot上(不一定是平均分配),cluster 负责维护node<->slot<->value。

5、Redis集群预分好16384个桶,当需要在 Redis 集群中放置一个 key-value 时,根据 CRC16(key) mod 16384的值,决定将一个key放到哪个桶中。

(1)数据获取

客户端是如何访问Redis Cluster里面的数据呢?

        首先客户端需要保存一份Redis Cluster槽相关的信息,也就是路由表,然后对即将访问的key进行哈希计算,计算出对应的槽位,然后向对应的Redis实例发起查询请求。

        如果访问的Redis实例中,的确保存着对应槽的数据信息,就会进行返回,否则向客户端返回一个Moved指令,让客户端到正确的地址进行获取。

(2)数据迁移

        在分布式系统中,衡量一个系统好坏的一项重要指标,系统的扩展性。

        什么是系统的扩展性呢?就是今天你又10万个用户,需要4台机器进行服务,如果明天的用户数量增加到20万了,是不是只要简单的增加4台机器就行,同时又不需要进行复杂的数据迁移。

        Redis Cluster便是如此,当你新增一些实例的时候,只需要将一部分槽位迁移到新的实例即可。在迁移的过程中,客户端会先去旧的实例上去查询数据,因为迁移正在发生,如果对应的数据还在本机上,那么直接返回,否则返回让客户端重定向到新的实例。客户端先向新的机器发起ask指令,新实例返回成功后,再一次查询最终的结果。

 Redis讲解目录:

Redis(1)-基本概念及使用

Redis(2)-Redis的一些问题及策略

Redis(3)-集群:主从复制、哨兵模式、Cluster

Redis(4)-Redis遇到的问题

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

sun cat

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值