Redis - 主从复制

2024-09-07 10:36
文章标签 redis 主从复制

本文主要是介绍Redis - 主从复制,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

目录

文章目录

前言 

1. 配置

建立复制

断开复制

传输延时

2. 主从拓扑结构

一主一从

一主多从

树状

三. 原理

数据同步 psync

replicationid/replid(复制id)

master_replid 和 master_replid2

offset (偏移量)

psync 运行流程

全量复制

部分复制

实时复制

总结


前言 

在分布式系统中为了解决单点问题,通常会把数据复制多个副本部署到其他服务器,满足故障恢 复和负载均衡等需求。Redis 也是如此,它为我们提供了复制的功能,实现了相同数据的多个 Redis 副本。复制功能是高可用 Redis 的基础,哨兵和集群都是在复制的基础上构建的。

1. 配置

建立复制

参与复制的 Redis 实例划分为主节点(master)和从节点(slave)。每个从结点只能有⼀个主节点, 而一个主节点可以同时具有多个从结点。复制的数据流是单向的,只能由主节点到从节点。配置复制 的方式有以下三种:

  • 1. 在配置文件中加入 slaveof {masterHost} {masterPort} 随 Redis 启动生效。
  • 2. 在 redis-server 启动命令时加入 --slaveof {masterHost} {masterPort} 生效。
  • 3. 直接使用 redis 命令:slaveof {masterHost} {masterPort}生效

修改配置主要是修改从机的配置. 主机配置不变 

第一步: 拷贝一份主节点配置文件给从节点, 并命名为 redis-slave.conf

第二步: 编辑配置文件,修改其 daemonize 为 yes。 

第三步: 通过redis-server指定配置文件 启动redis主节点和从节点  通过参数slaveof 配置该从节点归属的主节点

第四步: 启动redis客户端,观察主从关系

从运行结果中看到复制已经工作了,针对主节点 6379 的任何修改都可以同步到从节点 6380 中,复制 过程如图所示。

 

可以通过 info replication 命令查看复制相关状态。

主节点

role:master  #当前节点
connected_slaves:1 #从节点个数
slave0:ip=127.0.0.1,port=6380,state=online,offset=856,lag=0 #具体的一个从节点信息
master_replid:bdbc3e2ea45bb93bae7a5062892e3018b3e1d7dc #标识当前节点的id
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:856
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:856

从节点

role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:898
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:bdbc3e2ea45bb93bae7a5062892e3018b3e1d7dc
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:898
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:898

断开复制

slaveof 命令不但可以建立复制,还可以在从节点执行 slaveof no one 来断开与主节点复制关系。 例如在 6380 节点上执行 slaveof no one 来断开复制。

断开复制主要流程:

1)断开与主节点复制关系。

2)从节点晋升为主节点。

从节点断开复制后并不会抛弃原有数据,只是无法再获取主节点上的数据变化。

传输延时

主从节点一般部署在不同机器上,复制时的网络延迟就成为需要考虑的问题,Redis 为我们提供 了 repl-disable-tcp-nodelay 参数用于控制是否关闭 TCP_NODELAY,默认为 no,即开启 tcpnodelay 功能,说明如下: 

  • 当关闭时,主节点产生的命令数据无论大小都会及时地发送给从节点,这样主从之间延迟会变小, 但增加了网络带宽的消耗。适用于主从之间的网络环境良好的场景,如同机房部署。
  • 当开启时,主节点会合并较小的 TCP 数据包从而节省带宽。默认发送时间间隔取决于 Linux 的内 核,一般默认为 40 毫秒。这种配置节省了带宽但增大主从之间的延迟。适用于主从网络环境复杂 的场景,如跨机房部署

2. 主从拓扑结构

Redis 的复制拓扑结构可以支持单层或多层复制关系,根据拓扑复杂性可以分为以下三种:一主一 从、一主多从、树状主从结构。

一主一从

一主一从结构是最简单的复制拓扑结构,用于主节点出现宕机时从节点提供故障转移支持。当应用写命令并发量较高且需要持久化时,可以只在从节点上开启 AOF,这样既可以保证数据 安全性同时也避免了持久化对主节点的性能⼲扰。但需要注意的是,当主节点关闭持久化功能时,如果主节点宕机要避免自动重启操作。

一主多从

一主多从结构(星形结构)使得应用端可以利用多个从节点实现读写分离。对于 读比重较大的场景,可以把读命令负载均衡到不同的从节点上来分担压力。同时一些耗时的读命令可以指定一台专门的从节点执行,避免破坏整体的稳定性。对于写并发量较高的场景,多个从节点会导致主节点写命令的多次发送从而加重主节点的负载

树状

树形主从结构(分层结构)使得从节点不但可以复制主节点数据,同时可以作为其他从节点的主 节点继续向下层复制。通过引入复制中间层,可以有效降低住系统按负载和需要传送给从节点的数据量。数据写入节点 A 之后会同步给 B 和 C 节点,B 节点进一步把数据同步给 D 和 E 节 点。当主节点需要挂载等多个从节点时为了避免对主节点的性能干扰,可以采用这种拓扑结构。

三. 原理

 复制过程流程图

数据同步 psync

Redis 使用 psync 命令完成主从数据同步,同步过程分为:全量复制和部分复制。

  • 全量复制:一般用于初次复制场景,Redis 早期支持的复制功能只有全量复制,它会把主节点全部 数据一次性发送给从节点,当数据量较大时,会对主从节点和网络造成很大的开销。
  • 部分复制:用于处理在主从复制中因网络闪断等原因造成的数据丢失场景,当从节点再次连上主节点后,如果条件允许,主节点会补发数据给从节点。因为补发的数据远小于全量数据,可以有效避 免全量复制的过高开销。

PSYNC 的语法格式

PSYNC replicationid offset
# 如果 replicationid 设为 ? 并且 offset 设为 -1 此时就是在尝试进⾏全量复制.
# 如果 replicationid offset 设为了具体的数值, 则是尝试进⾏部分复制.

replicationid/replid(复制id)

主节点的复制 id. 主节点重新启动, 或者从节点晋级成主节点, 都会生成一个 replicationid. (同一个节点, 每次重启生成的 replicationid 也会变化). 从节点在和主节点建立连接之后, 就会获取到主节点的 replicationid.

master_replid 和 master_replid2

master_replid2保留上一个主节点的id(如果有的话),可以根据这个id找回上一个主节点

offset (偏移量)

参与复制的主从节点都会维护自身复制偏移量。主节点(master)在处理完写入命令后,会把命令的字节长度做累加记录,统计信息在 info replication 中的 master_repl_offset 指标中。

psync 运行流程

1)从节点发送 psync 命令给主节点,replid 和 offset 的默认值分别是 ? 和 -1.

2)主节点根据 psync 参数和自身数据情况决定响应结果:

  • 如果回复 +FULLRESYNC replid offset,则从节点需要进行全量复制流程。
  • 如果回复 +CONTINEU,从节点进行部分复制流程。
  • 如果回复 -ERR,说明 Redis 主节点版本过低,不支持 psync 命令。从节点可以使 sync 命令进行全量复制。

全量复制

流程图

1)从节点发送 psync 命令给主节点进行数据同步,由于是第⼀次进行复制,从节点没有主节点的运行 ID 和复制偏移量,所以发送 psync ? -1。

2)主节点根据命令,解析出要进行全量复制,回复 +FULLRESYNC 响应。

3)从节点接收主节点的运行信息进行保存。

4)主节点执行 bgsave 进行 RDB 文件的持久化。

5)主节点发送 RDB 文件给从节点,从节点保存 RDB 数据到本地硬盘。

6)主节点将从生成 RDB 到接收完成期间执行的写命令,写入缓冲区中,等从节点保存完 RDB 文件后,主节点再将缓冲区内的数据补发给从节点,补发的数据仍然按照 rdb 的二进制格式追加写入到收到的 rdb 文件中. 保持主从一致性。

7)从节点清空自身原有旧数据。

8)从节点加载 RDB 文件得到与主节点一致的数据。

9)如果从节点加载 RDB 完成之后,并且开启了 AOF 持久化功能,它会进行 bgrewrite 操作,得到最 近的 AOF 文件。

我们会发现全量复制是一件高成本的操作:主节点 bgsave 的时间, RDB 在网络传输的时间,从节点清空旧数据的时间,从节点加载 RDB 的时间等。所以一般应该尽可能 避免对已经有大量数据集的 Redis 进行全量复制。

部分复制

部分复制主要是 Redis 针对全量复制的过高开销做出的⼀种优化措施,使用psync replicationId offset 命令实现。当从节点正在复制主节点时,如果出现网络闪断或者命令丢失等异常情况时,从节点 会向主节点要求补发丢失的命令数据,如果主节点的复制积压缓冲区存在数据则直接发送给从节点, 这样就可以保持主从节点复制的一致性。补发的这部分数据⼀般远远小于全量数据,所以开销很小。 整体流程如图所示。

1)当主从节点之间出现网络中断时,如果超过 repl-timeout 时间,主节点会认为从节点故障并终断 复制连接。

2)主从连接中断期间主节点依然响应命令,但这些复制命令都因网络中断无法及时发送给从节点,所以暂时将这些命令滞留在复制积压缓冲区中。

3)当主从节点网络恢复后,从节点再次连上主节点。

4)从节点将之前保存的 replicationId 和 复制偏移量作为 psync 的参数发送给主节点,请求进行部分复制。

5)主节点接到 psync 请求后,进行必要的验证。随后根据 offset 去复制积压缓冲区查找合适的数据, 并响应 +CONTINUE 给从节点。

6)主节点将需要从节点同步的数据发送给从节点,最终完成一致性。

复制积压缓冲区

复制积压缓冲区是保存在主节点上的一个固定长度的队列,默认大小为 1MB,当主节点有连接的从节点(slave)时被创建,这时主节点(master)响应写命令时,不但会把命令发送给从节点,还会写入复制积压缓冲区中。

实时复制

主从节点在建立复制连接后,主节点会把自己收到的修改操作 , 通过 tcp 长连接的方式, 源源不断的传输给从节点. 从节点就会根据这些请求来同时修改自身的数据. 从而保持和主节点数据的一致性。

另外, 这样的长连接, 需要通过心跳包的方式来维护连接状态. (这里的心跳是指应用层自己实现的心跳, 而不是 TCP 自带的心跳)

1)主从节点彼此都有心跳检测机制,各自模拟成对方的客户端进行通信。

2)主节点默认每隔 10 秒对从节点发送 ping 命令,判断从节点的存活性和连接状态。

3)从节点默认每隔 1 秒向主节点发送 replconf ack {offset} 命令,给主节点上报自身当前的复制偏移量。

如果主节点发现从节点通信延迟超过 repl-timeout 配置的值(默认 60 秒),则判定从节点下线,断 开复制客户端连接。从节点恢复连接后,心跳机制继续进行。


总结

以上就是这篇博客的主要内容了,大家多多理解,下一篇博客见!

这篇关于Redis - 主从复制的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1144819

相关文章

零基础学习Redis(10) -- zset类型命令使用

zset是有序集合,内部除了存储元素外,还会存储一个score,存储在zset中的元素会按照score的大小升序排列,不同元素的score可以重复,score相同的元素会按照元素的字典序排列。 1. zset常用命令 1.1 zadd  zadd key [NX | XX] [GT | LT]   [CH] [INCR] score member [score member ...]

Redis中使用布隆过滤器解决缓存穿透问题

一、缓存穿透(失效)问题 缓存穿透是指查询一个一定不存在的数据,由于缓存中没有命中,会去数据库中查询,而数据库中也没有该数据,并且每次查询都不会命中缓存,从而每次请求都直接打到了数据库上,这会给数据库带来巨大压力。 二、布隆过滤器原理 布隆过滤器(Bloom Filter)是一种空间效率很高的随机数据结构,它利用多个不同的哈希函数将一个元素映射到一个位数组中的多个位置,并将这些位置的值置

Lua 脚本在 Redis 中执行时的原子性以及与redis的事务的区别

在 Redis 中,Lua 脚本具有原子性是因为 Redis 保证在执行脚本时,脚本中的所有操作都会被当作一个不可分割的整体。具体来说,Redis 使用单线程的执行模型来处理命令,因此当 Lua 脚本在 Redis 中执行时,不会有其他命令打断脚本的执行过程。脚本中的所有操作都将连续执行,直到脚本执行完成后,Redis 才会继续处理其他客户端的请求。 Lua 脚本在 Redis 中原子性的原因

laravel框架实现redis分布式集群原理

在app/config/database.php中配置如下: 'redis' => array('cluster' => true,'default' => array('host' => '172.21.107.247','port' => 6379,),'redis1' => array('host' => '172.21.107.248','port' => 6379,),) 其中cl

Redis的rehash机制

在Redis中,键值对(Key-Value Pair)存储方式是由字典(Dict)保存的,而字典底层是通过哈希表来实现的。通过哈希表中的节点保存字典中的键值对。我们知道当HashMap中由于Hash冲突(负载因子)超过某个阈值时,出于链表性能的考虑,会进行Resize的操作。Redis也一样。 在redis的具体实现中,使用了一种叫做渐进式哈希(rehashing)的机制来提高字典的缩放效率,避

【吊打面试官系列-Redis面试题】说说 Redis 哈希槽的概念?

大家好,我是锋哥。今天分享关于 【说说 Redis 哈希槽的概念?】面试题,希望对大家有帮助; 说说 Redis 哈希槽的概念? Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念,Redis 集群有 16384 个哈希槽,每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽, 集群的每个节点负责一部分 hash 槽。

Redis地理数据类型GEO

通常要计算两个地理位置的距离不是很方便,这里可以直接通过Redis提供的GEO操作来完成地理位置相关的计算 1)添加地理位置 语法:geoadd key longitude latitude member [longitude latitude member] ...字段说明:key:存放地理位置的集合名称longitude:地理坐标的经度latitude:地理坐标的纬度member:表示这

Redis-主从集群

主从架构 单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就需要搭建主从集群,实现读写分离。 主从数据同步原理 全量同步 主从第一次建立连接时,会执行全量同步,将master节点的所有数据都拷贝给slave节点,流程: 判断是否是第一次同步,如果是,返回版本信息(replication id 和offset),将salve节点的版本信息变为master的

Redis安装使用总结

一、下载安装 从 github 下载:https://github.com/MSOpenTech/redis/releases 或者 https://github.com/ServiceStack/redis-windows 解压缩,如图: 二、配置 打开redis.windows-sevice.conf文件, 2.1 绑定ip:搜索127.0.0.1 ,发现bind 127.0.0.

面对Redis数据量庞大时的应对策略

面对Redis数据量庞大时的应对策略,我们可以从多个维度出发,包括数据分片、内存优化、持久化策略、使用集群、硬件升级、数据淘汰策略、以及数据结构选择等。以下是对这些策略的详细探讨: 一、数据分片(Sharding) 当Redis数据量持续增长,单个实例的处理能力可能达到瓶颈。此时,可以通过数据分片将数据分散存储到多个Redis实例中,以实现水平扩展。分片的主要策略包括: 一致性哈希:使用一