Redis主从复制

主从复制

主从复制,将一台Redis服务器的数据,复制到其他Redis服务器。前者称为主(master)节点,后者称为从(slave)节点 。

在默认的情况下,Redis都是主节点,每个从节点只能有一个主节点,一个主节点可以有多个从节点。复制的数据只能从主节点复制到从节点。

配置方式

  1. 在从节点的配置文件中配置:slaveof {masterip} {masterport}
  2. 在redis-server启动命令后加入:--slaveof {masterip} {masterport}
  3. 在redis客户端使用命令:slaveof {masterip} {masterport}

建立主从关系

启动两个实例

//实例一:默认端口6379./redis-server//实例二:修改端口为6380./redis-server --port 6380

结果如下图

建立主从连接

// 把端口为6380的redis-server挂在6379的redis-server下./redis-cli -p 6380127.0.0.1:6380> slaveof 127.0.0.1 6379OK

主节点添加key

127.0.0.1:6379} set masterKey 'This is master Key'OK

从节点查询key

127.0.0.1:6380> get masterKey"This is master Key"

可以发现主节点的Key已经同步到从节点了

主节点删除key

127.0.0.1:6379} del masterKey(integer) 1

从节点再次查询key

127.0.0.1:6380> get masterKey(nil)

可以发现从节点的key也已经被删除了

断开连接

通过slaveof {masterip} {masterport}命令建立主从复制关系以后,可以通过slaveof no one断开。从节点断开复制后,不会删除已有的数据,只是不再接受主节点新的数据变化。

使用命令slaveof no one

127.0.0.1:6380> slaveof no oneOK

原理

在从节点执行slaveof命令后,主从复制的过程就开始了,可以分为6个步骤:

保存主节点信息

//从节点的redis-server中日志27604:S 21 Aug 22:38:56.934 * SLAVE OF 127.0.0.1:6379 enabled (user request from 'id=3 addr=127.0.0.1:60092 fd=8 name= age=69 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')

从上面的日志中可以看到salveof中的masterhost和masterport都被保存了下来。

建立连接

//从节点的redis-server中日志27604:S 21 Aug 22:38:57.444 * Connecting to MASTER 127.0.0.1:637927604:S 21 Aug 22:38:57.445 * MASTER {-} SLAVE sync started

从节点内部会使用一个每秒运行的定时任务,当发现了新的主节点后根据主节点的host和port建立一个socket连接。

当连接失败的时候定时任务会无限重试连接直到连接成功或者使用slaveof on one命令取消主从连接。

//从节点的redis-server中日志27639:S 21 Aug 22:50:02.825 # Error condition on socket for SYNC: Connection refused

发送ping命令

连接建立成功后从节点(salve)发送ping命令进行首次通信,主要目的是:

  • 检查主从之间网络套接字是否可用
  • 检查主节点当前是否可接受处理命令

从节点发送ping命令后会收到主节点的pong回复或者是超时问题,从节点便会断开连接,下次定时任务时再次发送ping命令

权限验证

如果主节点设置了requierpass参数,则从节点必须配置masterauth参数进行密码验证。

从节点会向主节点发送auth命令进行验证,auth参数为masterauth参数的值。如果验证没通过从节点会断开连接,并重连

从节点发送端口信息

身份验证之后,从节点会向主节点发送其监听的端口号,主节点将该信息保存到该从节点对应的客户端的slave_listening_port字段中

数据同步

主从复制能正常通信后,首次建立连接后主节点会把全部数据发送给从节点,相当于从节点完成数据初始化工作。

同步的方式有全量同步和部分同步。

命令复制

当主节点把所有数据复制给从节点后,主节点会把命令传输给从节点,从节点接收到命令后执行,以保证数据完整性

数据同步方式

Redis数据同步方式有全量同步和部分同步,Redis使用psync命令进行主从同步。

psync命令需要以下组件支持:

  • 主从节点各自复制偏移量
  • 主节点复制积压缓冲区
  • 主节点运行id

复制偏移量

主节点和从节点都会维护自身复制偏移量(offset),主节点在处理完命令后,会将命令的字节长度做累加并记录,统计在info replication中的master_repl_offset中。

127.0.0.1:6379> info replication# Replicationrole:master...master_repl_offset:308

从节点在接收到主节点发送的命令后,同样累计记录自身的偏移量,统计在info replication中的slave_repl_offset中。

127.0.0.1:6380> info replication# Replicationrole:slave...slave_repl_offset:1050

从节点每秒钟把自身的复制偏移量上报给主节点,主节点会保存这个从节点的复制偏移量。记录在从节点对应的ip,port行的offset中

127.0.0.1:6379> info replication# Replicationrole:master...slave0:ip=127.0.0.1,port=6380,state=online,offset=308,lag=1

复制积压缓冲区

复制积压缓冲区是主服务器维护的一个固定长度,先进先出的队列,默认为1M大小。当主节点有连接的从节点时被创建,主节点将命令发送给从节点时,还会写入复制积压缓冲区,作为写命令的备份,并且会为队列里的每个字节记录相应的复制偏移量。

复制积压缓冲区的一些数据保存在info replication中

127.0.0.1:6379> info replication# Replicationrole:master...repl_backlog_active:1 # 开启复制积压缓冲区repl_backlog_size:1048576 # 缓冲区最大长度repl_backlog_first_byte_offset:1 # 起始偏移量,计算当前缓冲区可用范围repl_backlog_histlen:308 # 已保存数据的有效长度

主节点运行ID

每个Redis节点在启动后都会动态分配一个唯一的40位十六进制字符串作为运行ID(run_id)。当Redis重启后,运行ID也会改变。

127.0.0.1:6379> info server# Server...run_id:9cc202d7825028c28e91207452e993de8cdb145ctcp_port:6379...

当主从节点第一次复制的时候,主节点会将run_id发送给从节点,从节点断线重新连接的时候,从节点将run_id发送给主节点,主节点和当前的自身的run_id判断是否需要全量复制。

  1. 当从节点发送run_id和主节点当前的run_id不相同,说明从节点在断线前和断线后的主节点不相同,需要全量复制
  2. 当从节点发送run_id和主节点当前的run_id相同,主节点根据复制偏移量和复制积压缓冲区判断是需要全量复制还是部分复制

psync命令

从节点使用psync {run_id} {offset}命令完成全量复制或者部分复制

  1. run_id:从节点保存的主节点run_id
  2. offset:从节点的复制偏移量

(psync运行流程, 图片来自《Redis设计与实现》)

从节点向主节点发送命令

  • 从节点从未执行过slaveof或者最近一次执行了slaveof no one,从节点向主节点发送psync ? -1请求全量复制。
  • 从节点执行过slaveof,从节点向主节点发送psync {run_id} {offset}命令,主节点判断是否需要全量复制。

主节点判断是否需要全量复制

  • 主节点根据pysnc参数和自身服务器状态,判断是全量复制还是部分复制
  • 如果主节点的Redis版本小于2.8,则返回+ERR,从节点发送重新sync命令触发全量复制
  • 如果主节点的run_id和psync命令中run_id参数相同,且命令中的offset参数之后的数据都存在复制积压缓冲区,则返回+CONTINUE,从节点等待主节点的部分复制
  • 如果主节点的run_id和psync命令中run_id参数不同,或者命令中的offset参数之后的数据有部分不再复制积压缓冲区中,则返回+FULLRESYNC {run_id} {offset},从节点触发全量复制,并且保存主节点的run_id和offset

心跳机制

主从复制建立之后,主从节点之间会维护两个心跳机制

PING

主节点向从节点默认每隔10秒发送PING命令,判断从节点是否存活和连接状态。配置参数repl-ping-slave-period可以控制PING命令的频率。

REPLCONF ACK

从节点向主节点默认每隔1秒发送replconf ack {offset}命令。它的作用是:

实时监测主从节点网络状态

127.0.0.1:6379> info replication# Replicationrole:master...slave0:ip=127.0.0.1,port=6380,state=online,offset=308,lag=1

在主节点的info replication中可以看到lag=1,表示主节点上次收到replconf ack命令的间隔,正常情况下应该为0或者1

上报自身的偏移量

从节点上报自身偏移量判断是否丢失数据,主节点把自身的offset和从节点的offset,如果从节点丢失数据,主节点会推送数据给从节点,如果从节点的offset之后的数据不在复制积压缓冲区中,则需要全量复制否则为部分复制。

实现保证从节点的数量和延迟功能

主节点中使用min-slaves-to-write(默认3个)和min-slaves-max-lag(默认10s)参数,保证从节点小于3个或所有从节点延迟大于10秒,主节点拒绝执行写命令。从节点的延迟数据是通过replconf ack命令的时间判断的,保存在info replication中的lag信息中。如果超过repl-timeout(默认60s)配置的值,则判断从节点下线并断开复制连接。

end:如果你觉得本文对你有帮助的话,记得关注点赞转发,你的支持就是我更新动力。

redis主从复制_技术干货分享:一文了解Redis主从复制相关推荐

  1. C#session共享+redis_技术干货分享:基于SpringBoot+Redis的Session共享与单点登录

    categories: 架构 author: mrzhou tags: SpringBoot redis session 单点登录 基于SpringBoot+Redis的Session共享与单点登录 ...

  2. rabbitmq 限制速度_技术干货分享:RabbitMQ消息积压的几种解决思路

    在日常工作中使用RabbitMQ偶尔会遇不可预料的情况导致的消息积压,一般出现消息积压基本上分为几种情况: 消费者消费消息的速度赶不上生产速度,这种问题主要是业务逻辑没设计好消费者和生产者之间的平衡, ...

  3. 【线下沙龙免费报名】像阿里巴巴一样工作_听干货分享欣赏阿里西溪园区风景

    阅读原文请点击 [杭州] Work Like Alibaba,你也可以,像阿里巴巴一样工作 云栖社区大数据云市场云服务阿里云创业大学 活动时间:2017-08-26 13:30 ~ 18:30 报名时 ...

  4. 数据库迁移_【干货分享】DM数据库迁移方法(物理迁移)

    在数据库的维护过程中,可能涉及换服务器,或者需要现网数据库环境测试的情况,这时,最简单快速的办法就是将源数据库相关的文件拷贝到目标主机,然后注册数据库实例服务.这就是数据库的物理迁移过程,可以是从wi ...

  5. 开关电源环路的零极点可以在反馈端补偿吗_【干货分享】开关电源环路补偿设计步骤讲解...

    微信公众号:硬核电子 ps:本文撰写过程较为漫长,要画各种示意图和编辑公式,如果你觉得文章不错的话,就请点个赞同吧. ​1. 理论讲解 在上一篇文章中电子小白菜:[干货分享]轻松弄懂开关电源TL431 ...

  6. python 自动化运维 读取交换机数据_技术干货|数据中心自动化运维技术探索之交换机零配置上线...

    近几年来,互联网行业处于一个快速发展的快车道,一个又一个风口不断地涌向周边行业.共享单车的出现解决了人们出行***一公里的问题:新零售概念的提出,无人货柜的出现,更是将线上和线下的数据打通,优化了人们 ...

  7. keepalived vip ping不通_【干货分享】OpenStack LVS负载均衡为什么不通?

    背 景 介 绍 OpenStack环境Neutron 的安全组会向虚拟机默认添加 anti-spoof 的规则,将保证虚拟机只能发出/接收以本机Port为原地址或目的地址(IP.MAC)的流量,提高了 ...

  8. 太硬核了!十天十场技术干货分享,其中有一个大佬还是我的死党!

    引言 14 世纪的欧洲,佛罗伦萨瘟疫盛行,10名男女在乡村一所别墅里避难.他们终日游玩欢宴,每人每天讲一个故事,共住了10天讲了百个故事.这就是文艺复兴时期的第一部现实主义巨著--<十日谈> ...

  9. 安装redis提示[test] error 2_技术干货分享:一次flask+redis的微服务实战

    先说一下需求的场景,策划部门想做一个垂直领域的社区产品,类似与知乎那种,但受益人群是金融行业的从业人员.产品中有一个搜索问题的需求,搜索的问题去题库中进行模糊匹配,终端支持H5/APP/小程序,甚至是 ...

最新文章

  1. 牛逼!一个故事讲清楚 NIO 了
  2. 3-spark学习笔记-SparkAPI
  3. java jeditorpane 自动换行_JDIC 中利用WebBrowser内置浏览器到java application中 | 学步园...
  4. NYOJ 269 VF
  5. AS3图像抖动效果源码。
  6. centos7 oracle_Centos7主机名变成bogon的原因及解决方法
  7. psql json操作符合函数
  8. python中连续两个小于号_Python语言描述最大连续子序列和
  9. 蓝桥杯2013c++真题:振兴中华
  10. java中常量和变量的区别_Java中三种变量
  11. python格式化代码快捷键_推荐一个小而美的Python代码格式化工具
  12. 腾讯位置服务开发应用-使用教程,案例分享,知识总结
  13. TopJUI Combobox 联动
  14. java 3dm_3dm游戏运行库合集安装包-游戏运行库合集安装包下载v3.0DM整理-西西软件下载...
  15. iOS开发第三方库汇总
  16. Unity导出转换微信小游戏
  17. 数字信号处理知识点总结(一):卷积
  18. python实现机器学习算法——K均值聚类算法
  19. idea快速切换不同JDK版本
  20. 模型误差、观测误差、截断误差(或称方法误差)、舍入误差

热门文章

  1. 无限极 php算法,无限极分类算法,对你一定有帮助
  2. Python中对列表list进行定义、增删改查、遍历及与元组的对比
  3. MySQL8.0.19下载安装及配置详细步骤
  4. HttpContext HttpRuntime
  5. 【JAVA学习】09.创建BootstrapTale列表页
  6. 牛客网Wannafly挑战赛15 B车辆安排(模拟)AND C 出队(规律)
  7. [bzoj1036][ZJOI2008]树的统计Count
  8. 织梦直接往数据库写入数据
  9. HDU 1476 Sudoku Killer
  10. c语言 结构体_C语言 技能提升 系列文章 (三)结构体