百度360必应搜狗淘宝本站头条
当前位置:网站首页 > IT技术 > 正文

一文读懂Redis主从同步协议原理

wptr33 2025-01-05 20:32 21 浏览

Redis是一个内存型的KV键值数据库,使用主从架构的最核心的目的便是提供数据冗余备份,以防止一个Redis节点Down掉之后其中的数据也被丢失,而作为冗余备份,主从节点最重要的工作便是数据同步,下图显示了客户端读写Redis集群的I/O路径。

那么本篇着重介绍的便是Redis的数据同步策略,包括主从节点首次建立连接后的全量复制以及从节点短暂断连后的数据部分复制。主要内容分为

  1. Redis主从复制概述
  2. Redis主从数据同步
  3. Redis读写分离实现以及过期数据处理
  4. 结语

Redis主从复制概述

主从复制,是指将一台Redis Master节点服务器的数据复制到其他的Redis Slave服务器,主节点(master/leader),从节点(slave/follower)。一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点,同时每个从节点也可以是别的从节点的父节点,即主从节点连接形成树结构。

主从结构中数据的复制是单向的,只能由主节点到从节点,所有的内存变更,即数据的增删改都只能在主节点上进行,从节点通过同步的方式完成修改。默认情况下,从节点对非Master节点客户端是只读的。Redis使用主从复制的作用有:

  1. 数据冗余:实现数据冗余备份,这样一台节点挂了之后,其上的数据不至于丢失。
  2. 故障恢复:当主节点出现问题时,其从节点可以被提升为主节点继续提供服务,实现快速的故障恢复;
  3. 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。

Redis主从数据同步

redis的主从同步始于命令SLAVEOF host port,通过这个命令能够建立主从关系,SLAVEOF 命令用于在 Redis 运行时动态地修改复制功能的行为。

通过执行 SLAVEOF host port 命令,可以将当前服务器转变为指定服务器的从属服务器(slave server)。如果当前服务器已经是某个主服务器(master server)的从属服务器,那么执行 SLAVEOF host port 将使当前服务器停止对旧主服务器的同步,丢弃旧数据集,转而开始对新主服务器进行同步。

另外,对一个从属服务器执行命令 SLAVEOF NO ONE 将使得这个从属服务器关闭复制功能,并从从属服务器转变回主服务器,原来同步所得的数据集不会被丢弃。利用 SLAVEOF NO ONE 不会丢弃同步所得数据集这个特性,在没有搭建哨兵和集群的情况下,可以在主服务器失败的时候,将从属服务器用作新的主服务器,从而实现无间断运行。

全量同步

Redis主从结构的核心目的在于数据备份。当节点A对节点B发起复制时,最直接的做法就是把节点B的内存数据生成快照文件(RDB)然后发送给节点A,节点A接收到RDB文件后将文件中的数据恢复到内存中,这就是全量同步

全量同步过程有一个问题:主节点如何判断一个从节点是第一次同步数据?

实际上每一个 redis 节点都会有一个 replication id ,称为数据集ID。从节点第一次请求主节点,会带上 replication id,主节点收到从节点 replication id,和自己的 replication id 对比,如果不相同说明是第一次请求同步数据,主节点将自己的 replication id 发送给从节点,从节点存储主节点的 replication id,从节点后续请求再带上该 replication id。

此外,主节点如何知道每次从 repl_baklog 中获取哪部分数据同步从节点?

实际上主节点向从节点同步数据时,会带上两个个参数:replication id 和 offset, offset 标记每次复制数据的偏移量。往后同步从节点带上 replication id 和 offset 即可。

增量同步

增量同步一般发生在重启阶段:

  • 从节点带上 replication id 和 offset 向主节点请求同步;
  • 主节点根据 replication id 判断是否和自己的一致;如果一直则回复继续;
  • 主节点从 repl_baklog 中取出数据,同步到从节点;
  • 从节点接收之后存储指令;

PSYNC具备了数据全量重同步和增量同步模式。

全量重同步:跟旧版复制基本是一致的,可以理解为“全量”复制。

部分重同步:salve断开又重新连时,在命令传播阶段,只需要发送与master断开这段时间执行的写命给slave即可,可以理解为“增量”复制。

PSYNC执行过程中比较重要的概念有3个:runid、offset(复制偏移量)以及复制积压缓冲区。

1.runid

每个Redis服务器都会有一个表明自己身份的ID。在PSYNC中发送的这个ID是指之前连接的Master的ID,如果没保存这个ID,PSYNC的命令会使用”PSYNC ? -1” 这种形式发送给Master,表示需要全量复制。

2.offset(复制偏移量)

在主从复制的Master和Slave双方都会各自维持一个offset。Master成功发送N个字节的命令后会将Master里的offset加上N,Slave在接收到N个字节命令后同样会将Slave里的offset增加N。

Master和Slave如果状态是一致的那么它的的offset也应该是一致的。

3.复制积压缓冲区

复制积压缓冲区是由Master维护的一个固定长度环形积压队列(FIFO队列),它的作用是缓存已经传播出去的命令。当Master进行命令传播时,不仅将命令发送给所有Slave,还会将命令写入到复制积压缓冲区里面。

PSYNC执行过程和SYNC的区别在于:salve连接时,判断是否需要全量同步,全量同步的逻辑过程和SYNC一样。PSYNC执行步骤如下:

客户端向服务器发送SLAVEOF命令,即salve向master发起连接请求时,slave根据自己是否保存Master runid来判断是否是第一次连接。

如果是第一次同步则向Master发送 PSYNC ? -1 命令来进行完整同步;如果是重连接,会向Master发送PSYNC runid offset命令(runid是master的身份ID,offset是从节点同步命令的全局迁移量)。

Master接收到PSYNC 命令后,首先判断runid是否和本机的id一致,如果一致则会再次判断offset偏移量和本机的偏移量相差有没有超过复制积压缓冲区大小,如果没有那么就给Slave发送CONTINUE,此时Slave只需要等待Master传回失去连接期间丢失的命令。如果runid和本机id不一致或者offset差距超过了复制积压缓冲区大小,那么就会返回FULLRESYNC runid offset,Slave将runid保存起来,并进行全量同步。

主节点在命令传播时,主数据库会将每一个写命令传递给从数据库的同时,都会将写命令存放到积压队列,并记录当前积压队列中存放命令的全局偏移量offset。当salve重连接时,master会根据从节点传的offset在环形积压队列中找到断开这段时间执行的命令,并同步给salve节点,达到增量同步结果。

主从同步优化

可以从这几个方面来优化主从集群:

  • 在 master 中配置 repl-diskless-sync yes 启动无磁盘复制,避免全量同步时的磁盘IO;
  • Redis 单节点的内存占用不要太大,减少 RDB 导致的过多磁盘IO;
  • 适当提高repl_baklog的大小,发现slave宕机时尽快实现故障恢复,尽可能避免全量同步;
  • 限制一个 master 的 slave 节点,如果需要较多的 slave,可以采用主-从-从链接模式;

读写分离和过期数据

主从复制的一大用处就是可以拓展单节点的读写性能,但是由于Redis中主从节点的数据复制时单向的,所以从节点对外是只读状态,而主节点是可读可写的状态。在读请求占比比较大的时候,让从节点参与响应读请求可以有效的分摊Master节点的压力。但是需要注意的是,由于主从节点之间可能存在数据的延迟,导致从子节点读到的数据可能是过期数据。其中一个典型的场景就是过期数据未能及时清理。由于数据的单向复制,子节点在Master节点不告知的情况下不会主动进行任何内存变更的操作,涉及到数据过期时,Redis采用的做法是当Master节点判断某个key过期了之后会向子节点发送DEL命令删除掉数据。但是如果期间由于网络环境或其他问题导致DEL命令未及时到达子节点,那么用户此时从子节点读到的数据就是本应已过期被删除的数据。

为了解决这个问题,Redis从3.2版本之后,子节点也可以主动判断用户请求的键是否已经过期。如果过期,则就不向用户返回结果,但是并不会直接删除数据。删除数据的操作仍然是只会由Master节点的同步引起。这实际上是对主从的时钟同步是有要求的,绝大部分情况下这个先决条件还是能够被满足的。

相关推荐

redis的八种使用场景

前言:redis是我们工作开发中,经常要打交道的,下面对redis的使用场景做总结介绍也是对redis举报的功能做梳理。缓存Redis最常见的用途是作为缓存,用于加速应用程序的响应速度。...

基于Redis的3种分布式ID生成策略

在分布式系统设计中,全局唯一ID是一个基础而关键的组件。随着业务规模扩大和系统架构向微服务演进,传统的单机自增ID已无法满足需求。高并发、高可用的分布式ID生成方案成为构建可靠分布式系统的必要条件。R...

基于OpenWrt系统路由器的模式切换与网页设计

摘要:目前商用WiFi路由器已应用到多个领域,商家通过给用户提供一个稳定免费WiFi热点达到吸引客户、提升服务的目标。传统路由器自带的Luci界面提供了工厂模式的Web界面,用户可通过该界面配置路...

这篇文章教你看明白 nginx-ingress 控制器

主机nginx一般nginx做主机反向代理(网关)有以下配置...

如何用redis实现注册中心

一句话总结使用Redis实现注册中心:服务注册...

爱可可老师24小时热门分享(2020.5.10)

No1.看自己以前写的代码是种什么体验?No2.DooM-chip!国外网友SylvainLefebvre自制的无CPU、无操作码、无指令计数器...No3.我认为CS学位可以更好,如...

Apportable:拯救程序员,IOS一秒变安卓

摘要:还在为了跨平台使用cocos2d-x吗,拯救objc程序员的奇葩来了,ApportableSDK:FreeAndroidsupportforcocos2d-iPhone。App...

JAVA实现超买超卖方案汇总,那个最适合你,一篇文章彻底讲透

以下是几种Java实现超买超卖问题的核心解决方案及代码示例,针对高并发场景下的库存扣减问题:方案一:Redis原子操作+Lua脚本(推荐)//使用Redis+Lua保证原子性publicbo...

3月26日更新 快速施法自动施法可独立设置

2016年3月26日DOTA2有一个79.6MB的更新主要是针对自动施法和快速施法的调整本来内容不多不少朋友都有自动施法和快速施法的困扰英文更新日志一些视觉BUG修复就不翻译了主要翻译自动施...

Redis 是如何提供服务的

在刚刚接触Redis的时候,最想要知道的是一个’setnameJhon’命令到达Redis服务器的时候,它是如何返回’OK’的?里面命令处理的流程如何,具体细节怎么样?你一定有问过自己...

lua _G、_VERSION使用

到这里我们已经把lua基础库中的函数介绍完了,除了函数外基础库中还有两个常量,一个是_G,另一个是_VERSION。_G是基础库本身,指向自己,这个变量很有意思,可以无限引用自己,最后得到的还是自己,...

China's top diplomat to chair third China-Pacific Island countries foreign ministers' meeting

BEIJING,May21(Xinhua)--ChineseForeignMinisterWangYi,alsoamemberofthePoliticalBureau...

移动工作交流工具Lua推出Insights数据分析产品

Lua是一个适用于各种职业人士的移动交流平台,它在今天推出了一项叫做Insights的全新功能。Insights是一个数据平台,客户可以在上面实时看到员工之间的交流情况,并分析这些情况对公司发展的影响...

Redis 7新武器:用Redis Stack实现向量搜索的极限压测

当传统关系型数据库还在为向量相似度搜索的性能挣扎时,Redis7的RedisStack...

Nginx/OpenResty详解,Nginx Lua编程,重定向与内部子请求

重定向与内部子请求Nginx的rewrite指令不仅可以在Nginx内部的server、location之间进行跳转,还可以进行外部链接的重定向。通过ngx_lua模块的Lua函数除了能实现Nginx...