侧边栏壁纸
  • 累计撰写 98 篇文章
  • 累计创建 20 个标签
  • 累计收到 3 条评论

redis三种集群策略

林贤钦
2020-05-31 / 0 评论 / 12 点赞 / 625 阅读 / 0 字
温馨提示:
本文最后更新于 2020-06-01,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

redis三种集群策略

为了避免单点Redis服务器故障,准备多台服务器,互相连通。将数据复制多个副本保存在不同的服务器上,连接在一起,并保证数据是同步的。即使有其中一台服务器宕机,其他服务器依然可以继续提供服务,实现Redis的高可用,同时实现数据冗余备份。

redis包含三种集群策略

  • 主从复制
  • 哨兵
  • 集群

1、主从复制

主数据库可以进行读写操作,当读写操作导致数据变化时会自动将数据同步给从数据库
从数据库一般都是只读的,并且接收主数据库同步过来的数据

特征:一个master可以拥有多个slave,一个slave只对应一个master

职责:

  • master:

  • 写数据

  • 执行写操作时,将出现变化的数据自动同步到slave

  • 读数据(可忽略)

  • slave:

    • 读数据
    • 写数据(禁止)

主从复制的作用

  • 读写分离:master写、slave读,提高服务器的读写负载能力

  • 负载均衡:基于主从结构,配合读写分离,由slave分担master负载,并根据需求的变化,改变slave的数量,通过多个从节点分担数据读取负载,大大提高Redis服务器并发量与数据吞吐量

  • 故障恢复:当master出现问题时,由slave提供服务,实现快速的故障恢复

  • 数据冗余:实现数据热备份,是持久化之外的一种数据冗余方式

  • 高可用基石:基于主从复制,构建哨兵模式与集群,实现Redis的高可用方案

主从复制原理

  • 从服务器连接主服务器,发送SYNC命令;
  • 主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令;
  • 主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令;
  • 从服务器收到快照文件后丢弃所有旧数据,载入收到的快照;
  • 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令;
  • 从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;(从服务器初始化完成
  • 主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令(从服务器初始化完成后的操作

主从复制工作机制

主从复制过程大体可以分为3个阶段

  1. 建立连接阶段(即准备阶段)

建立slave到master的连接,使master能够识别slave,并保存slave端口号

  1. 数据同步阶段

    在slave初次连接master后,复制master中的所有数据到slave

    将slave的数据库状态更新成master当前的数据库状态

  2. 命令传播阶段

    当master数据库状态被修改后,导致主从服务器数据库状态不一致,此时需要让主从数据同步到一致的状态,同步的动作称为命令传播,master将接收到的数据变更命令发送给slave,slave接收命令后执行命令

建立连接阶段

数据同步阶段

命令传播阶段

命令传播阶段的部分复制

  • 命令传播阶段出现了断网现象

  • 网络闪断闪连------------------------忽略

  • 短时间网络中断---------------------部分复制

  • 长时间网络中断----------------------全量复制

部分复制的三个核心要素

  1. 服务器运行ID(runid)

    概念:服务器运行ID是每一台服务器每次运行的身份识别码,一台服务器多次运行可以生成多个运行id

    组成:运行id由40位字符组成,是一个随机的十六进制字符

    例如:fdc9ff13b9bbaab28db42b3d50f852bb5e3fcdce

    作用:运行id被用于在服务器间进行传输,识别身份

    如果想两次操作均对同一台服务器进行,必须每次操作携带对应的运行id,用于对方识别

    实现方式:运行id在每台服务器启动时自动生成的,master在首次连接slave时,会将自己的运行ID发送给slave,slave保存此ID,通过info Server命令,可以查看节点的runid

  2. 复制缓冲区

    概念:复制缓冲区,又名复制积压缓冲区,是一个先进先出(FIFO)的队列,用于存储服务器执行过的命令,每次传播命令,master都会将传播的命令记录下来,并存储在复制缓冲区

    复制缓冲区默认数据存储空间大小是1M,由于存储空间大小是固定的,当入队元素的数量大于队列长度时,最先入队的元素会被弹出,而新元素会被放入队列

    由来:每台服务器启动时,如果开启有AOF或被连接成为master节点,即创建复制缓冲区

    作用:用于保存master收到的所有指令(仅影响数据变更的指令,例如set,select)

    数据来源:当master接收到主客户端的指令时,除了将指令执行,会将该指令存储到缓冲区中

  3. 主从服务器复制偏移量(offset)

    概念:一个数字,描述复制缓冲区中的指令字节位置

    分类

    • master复制偏移量:记录发送给所有slave的指令字节对应的位置(多个)

    • slave复制偏移量:记录slave接收master发送过来的指令字节对应的位置(一个)

    数据来源

    • master端:发送一次记录一次

    • slave端:接收一次记录一次

    作用:同步信息,比对master与slave的差异,当slave断线后,恢复数据使用

心跳机制

进入命令传播阶段候,master与slave间需要进行信息交换,使用心跳机制进行维护,实现双方连接保持在线

master心跳

  • 指令:PING

  • 周期:由repl-ping-slave-period决定,默认10秒

  • 作用:判断slave是否在线

  • 查询:INFO replication

    获取slave最后一次连接时间间隔,lag项维持在0或1视为正常

slave心跳任务

  • 指令:REPLCONF ACK

  • 周期:1秒

  • 作用1:汇报slave自己的复制偏移量,获取最新的数据变更指令

  • 作用2:判断master是否在线

主从复制常见问题

频繁的全量复制(1)

伴随着系统的运行,master的数据量会越来越大,一旦master重启,runid将发生变化,会导致全部slave的全量复制操作

内部优化调整方案

作用:本机保存上次runid,重启后恢复该值,使所有slave认为还是之前的master

  1. master内部创建master_replid变量,使用runid相同的策略生成,长度41位,并发送给所有slave

  2. 在master关闭时执行命令 shutdown save,进行RDB持久化,将runid与offset保存到RDB文件中

    • repl-id repl-offset
    • 通过redis-check-rdb命令可以查看该信息
  3. master重启后加载RDB文件,恢复数据

    重启后,将RDB文件中保存的repl-id与repl-offset加载到内存中

    • master_repl_id = repl master_repl_offset = repl-offset

    • 通过info命令可以查看该信息

频繁的全量复制(2)

  • 问题现象

    网络环境不佳,出现网络中断,slave不提供服务

  • 问题原因

复制缓冲区过小,断网后slave的offset越界,触发全量复制

  • 最终结果

    slave反复进行全量复制

  • 解决方案

    修改复制缓冲区大小

    repl-backlog-size

  • 建议设置如下

    测算从master到slave的重连平均时长second

    获取master平均每秒产生写命令数据总量write_size_per_second

    最优复制缓冲区空间 = 2 * second * write_size_per_second

频繁的网络中断(1)

  • 问题现象

    master的CPU占用过高 或 slave频繁断开连接

  • 问题原因

    1、slave每1秒发送REPLCONF ACK命令到master

    2、当slave接到了慢查询时(keys * ,hgetall等),会大量占用CPU性能

    3、master每1秒调用复制定时函数replicationCron(),比对slave发现长时间没有进行响应

  • 最终结果

    master各种资源(输出缓冲区、带宽、连接等)被严重占用

  • 解决方案

通过设置合理的超时时间,确认是否释放slave

repl-timeout 该参数定义了超时时间的阈值(默认60秒),超过该值,释放slave

频繁的网络中断(2)

  • 问题现象

    slave与master连接断开

  • 问题原因

master发送ping指令频度较低、master设定超时时间较短、ping指令在网络中存在丢包

  • 解决方案

    提高ping指令发送的频度

    repl-ping-slave-period超时时间repl-time的时间至少是ping指令频度的5到10倍,否则slave很容易判定超时

数据不一致

  • 问题现象

    多个slave获取相同数据不同步

  • 问题原因

    网络信息不同步,数据发送有延迟

  • 解决方案

    优化主从间的网络环境,通常放置在同一个机房部署,如使用阿里云等云服务器时要注意此现象

    监控主从节点延迟(通过offset)判断,如果slave延迟过大,暂时屏蔽程序对该slave的数据访问

    slave-serve-stale-data yes|no开启后仅响应info、slaveof等少数命令(慎用,除非对数据一致性要求很高)

2、哨兵模式

当主服务器中断服务后,可以将一个从服务器升级为主服务器,以便继续提供服务,但是这个过程需要人工手动来操作。 为此,Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个

(1)监控主服务器和从服务器是否正常运行。
(2)主服务器出现故障时自动将从服务器转换为主服务器。

注意

  • 哨兵也是一台redis服务器,只是不提供数据服务

  • 通常哨兵配置数量为单数

哨兵的工作方式

  • 每个Sentinel(哨兵)进程以每秒钟一次的频率向整个集群中的Master主服务器,Slave从服务器以及其他Sentinel(哨兵)进程发送一个 PING 命令。
  • 如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel(哨兵)进程标记为主观下线(SDOWN)
  • 如果一个Master主服务器被标记为主观下线(SDOWN),则正在监视这个Master主服务器的所有 Sentinel(哨兵)进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
  • 当有足够数量的 Sentinel(哨兵)进程(大于等于配置文件指定的值)在指定的时间范围内确认Master主服务器进入了主观下线状态(SDOWN), 则Master主服务器会被标记为客观下线(ODOWN)
  • 在一般情况下, 每个 Sentinel(哨兵)进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
  • 当Master主服务器被 Sentinel(哨兵)进程标记为客观下线(ODOWN)时,Sentinel(哨兵)进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
  • 若没有足够数量的 Sentinel(哨兵)进程同意 Master主服务器下线, Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel(哨兵)进程发送 PING 命令返回有效回复,Master主服务器的主观下线状态就会被移除。

哨兵模式的优缺点

优点:

  • 哨兵模式是基于主从模式的,所有主从的优点,哨兵模式都具有。
  • 主从可以自动切换,系统更健壮,可用性更高。

缺点:

  • Redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。

3、Redis-Cluster集群

edis的哨兵模式基本已经可以实现高可用,读写分离 ,但是在这种模式下每台redis服务器都存储相同的数据,很浪费内存,所以在redis3.0上加入了cluster模式,实现的redis的分布式存储,也就是说每台redis节点上存储不同的内容。

Redis-Cluster采用无中心结构,它的特点如下

  • 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
  • 节点的fail是通过集群中超过半数的节点检测失效时才生效。
  • 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

工作方式:

在redis的每一个节点上,都有这么两个东西,一个是插槽(slot),它的的取值范围是:0-16383。还有一个就是cluster,可以理解为是一个集群管理的插件。当我们的存取的key到达的时候,redis会根据crc16的算法得出一个结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,通过这个值,去找到对应的插槽所对应的节点,然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用

redis-cluster集群引入了主从模式,一个主节点对应一个或者多个从节点,当主节点宕机的时候,就会启用从节点。当其它主节点ping一个主节点A时,如果半数以上的主节点与A通信超时,那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了,那么该集群就无法再提供服务了。

12

评论区