主从复制 原理

本文详细介绍了Redis主从复制的工作原理和技术细节,包括正常连接、断开后重连及全部复制三种机制,以及如何实现数据集的一致性同步。

一、主从复制的三个重要机制

1、正常连接后的复制:

 master 会发送一连串的命令流来保持对 slave 的更新,以便于将自身数据集的改变复制给 slave , :包括客户端的写入、key 的过期或被逐出等等。

2、断开后重连的部分复制

    尝试只获取在断开连接期间内丢失的命令流。

3、部分复制失败后的全部复制

  当无法进行部分重同步时, slave 会请求进行全量重同步。这会涉及到一个更复杂的过程,例如 master 需要创建所有数据的快照,将之发送给 slave ,之后在数据集更改时持续发送命令流到 slave 。

 

Redis 复制功能的几个重要方面:
1. 一个Master可以有多个Slave;
2. Redis使用异步复制。从2.8开始,Slave会周期性(每秒一次)发起一个Ack确认复制流(replication stream)来处理进度;
3. 不仅主服务器可以有从服务器, 从服务器也可以有自己的从服务器, 多个从服务器之间可以构成一个图状结构;
4. 复制在Master端是非阻塞模式的,这意味着即便是多个Slave执行首次同步时,Master依然可以提供查询服务;
5. 复制在Slave端也是非阻塞模式的:如果你在redis.conf做了设置,Slave在执行首次同步的时候仍可以使用旧数据集提供查询;你也可以配置为当Master与Slave失去联系时,让Slave返回客户端一个错误提示;
6. 当Slave要删掉旧的数据集,并重新加载新版数据时,Slave会阻塞连接请求(一般发生在与Master断开重连后的恢复阶段);
7. 复制功能可以单纯地用于数据冗余(data redundancy),也可以通过让多个从服务器处理只读命令请求来提升扩展性(scalability): 比如说, 繁重的 SORT 命令可以交给附属节点去运行。
8. 可以通过修改Master端的redis.config来避免在Master端执行持久化操作(Save),由Slave端来执行持久化。

 

Redis复制工作原理:
1. 如果设置了一个Slave,无论是第一次连接还是重连到Master,它都会发出一个SYNC命令;
2. 当Master收到SYNC命令之后,会做两件事:
a) Master执行BGSAVE,即在后台保存数据到磁盘(rdb快照文件);
b) Master同时将新收到的写入和修改数据集的命令存入缓冲区(非查询类);
3. 当Master在后台把数据保存到快照文件完成之后,Master会把这个快照文件传送给Slave,而Slave则把内存清空后,加载该文件到内存中;
4. 而Master也会把此前收集到缓冲区中的命令,通过Reids命令协议形式转发给Slave,Slave执行这些命令,实现和Master的同步;
5. Master/Slave此后会不断通过异步方式进行命令的同步,达到最终数据的同步一致;
6. 需要注意的是Master和Slave之间一旦发生重连都会引发全量同步操作。但在2.8之后版本,也可能是部分同步操作。

部分复制
2.8开始,当Master和Slave之间的连接断开之后,他们之间可以采用持续复制处理方式代替采用全量同步。
Master端为复制流维护一个内存缓冲区(in-memory backlog),记录最近发送的复制流命令;同时,Master和Slave之间都维护一个复制偏移量(replication offset)和当前Master服务器ID(Master run id)。当网络断开,Slave尝试重连时:
a. 如果MasterID相同(即仍是断网前的Master服务器),并且从断开时到当前时刻的历史命令依然在Master的内存缓冲区中存在,则Master会将缺失的这段时间的所有命令发送给Slave执行,然后复制工作就可以继续执行了;
b. 否则,依然需要全量复制操作;

Redis 2.8 的这个部分重同步特性会用到一个新增的 PSYNC 内部命令, 而 Redis 2.8 以前的旧版本只有 SYNC 命令, 不过, 只要从服务器是 Redis 2.8 或以上的版本, 它就会根据主服务器的版本来决定到底是使用 PSYNC 还是 SYNC :

如果主服务器是 Redis 2.8 或以上版本,那么从服务器使用 PSYNC 命令来进行同步。
如果主服务器是 Redis 2.8 之前的版本,那么从服务器使用 SYNC 命令来进行同步。

 

Redis 复制机制

首先是slave端,对于slave端来说,主从复制主要经历四个阶段:

第一阶段:与master建立连接
第二阶段:向master发起同步请求(SYNC)
第三阶段:接受master发来的RDB数据
第四阶段:载入RDB文件

下面我们就通过一个图来概述在每一个阶段中,slave究竟做了些什么:



关于上图,有一点说明下:redis接收到slaveof master_host master_port命令后并没有马上与master建立连接,而是当执行服务器例行任务serverCron,发现自己正处于REDIS_REPL_CONNECT状态,这时才真正的向maser发起连接,伪代码:

Python代码  收藏代码

  1. def serverCron():  
  2.     # 服务器处于REDIS_REPL_CONNECT状态  
  3.     if redisServer.repl_state == REDIS_REPL_CONNECT:  
  4.         # 向master发起连接  
  5.         connectWithMaster()  
  6.     # 其他例行任务(省略)...  



接着我们来看下主从复制过程中,master这边的流程是如何,在具体看细节之前,我们先综合来看master这边主要做的几件事情:



看完这个图,你也许会有以下几个疑问:

1. 为什么在master发送完RDB文件后,还要定期的向slave发送PING命令?
2. 在发送完RDB文件之后,master发送的“变更”命令又是什么,有什么用?

在回答问题之前1,我们先回答问题2:
master保存RDB文件是通过一个子进程进行的,所以master依然可以处理客户端请求而不被阻塞,但这也导致了在保存RDB文件期间,“键空间”可能发生变化(譬如接收到一个客户端请求,执行"set name diaocow"命令),因此为了保证数据同步的一致性,master会在保存RDB文件期间,把接受到的这些可能变更数据库“键空间”的命令保存下来,然后放到每个slave的回复列表中,当RDB文件发送完master会发送这些回复列表中的内容,并且在这之后,如果数据库发生变更,master依然会把变更的命令追加到回复列表发送给slave,这样就可以保证master和slave数据的一致性!相关伪代码:
 

Python代码  收藏代码

  1. def processCommand(cmd, argc, argv):  
  2.     # 处理命令  
  3.     call(cmd, argc, argv)  
  4.     # 如果该命令造成数据库键空间变化and当前redis是一个master,则同步变更命令  
  5.     if redisServer.update_key_space and len(redisServer.slaves) > 0:  
  6.         replicationFeedSlaves(cmd, argc, argv)  
  7.   
  8. def replicationFeedSlaves(cmd, argc, argv):   
  9.     # 把变更命令发送给每一个处于:REDIS_REPL_WAIT_BGSAVE_END状态的slave节点  
  10.     for slave in redisServer.slaves:  
  11.         if slave.replstate == REDIS_REPL_WAIT_BGSAVE_START:  
  12.             continue  
  13.         slave.updateNotify(cmd, argc, argv)  


由于在发送完RDB文件之后,master会不定时的给slave发送“变更”命令,可能过1s,也可能过1小时,所以为了防止slave无意义等待(譬如master已经挂掉的情况),master需要定时发送“保活”命令PING,以此告诉slave:我还活着,不要中断与我的连接

现在我们就看下,当master接受到slave发送的sync同步命令后究竟发生了哪些事:


上图看似分支复杂,但我们抓住以下几点即可:

1.保存RDB文件是在一个子进程中进行的;
2.如果master已经在保存RDB文件,但是没有客户端正在等待这次BGSAVE,新添加的slave需要等到下次BGSAVE,而不能直接使用这次生成的RDB文件(原因图中已经说明)
3.master会定期检查RDB文件是否保存完毕(时间事件serverCron);

接下来我们看下,master是如何给每一个slave发送RDB文件的:



好了,至此我们已经分析完在主从复制过程中,master和slave两边分别是怎么一个处理流程;最后,我绘制了一个图,综述了主从复制这一过程(我们可以边看图,边回忆其中的具体细节):


 

PS:在主从复制过程中,任何一步发生错误,都会导致整个过程重头开始,所以若RDB文件很大又或是此时正处在业务高峰期,对系统性能将会有非常大的影响!


Redis 复制操作

一、Redis实现复制很简单,主要有下面两个方法
1、从机器的redis.conf添加slaveof 主IP 端口,然后带上配置文件启动server
# src/redis-server redis.conf
2、从机器启动后在命令里打入slaveof 主IP 端口,这里是全局命令
127.0.0.1 6379> salveof 192.168.10.10 6379

二、关闭同步(从机器)
# src/redis-server no one

注意:
1,Redis不支持主主复制,任意两台机器间不能互相slaveof
2,从设置同步时,会清空所有数据

下载前可以先看下教程 https://pan.quark.cn/s/a4b39357ea24 在网页构建过程中,表单(Form)扮演着用户与网站之间沟通的关键角色,其主要功能在于汇集用户的各类输入信息。 JavaScript作为网页开发的核心技术,提供了多样化的API和函数来操作表单组件,诸如input和select等元素。 本专题将详细研究如何借助原生JavaScript对form表单进行视觉优化,并对input输入框与select下拉框进行功能增强。 一、表单基础1. 表单组件:在HTML语言中,<form>标签用于构建一个表单,该标签内部可以容纳多种表单组件,包括<input>(输入框)、<select>(下拉框)、<textarea>(多行文本输入区域)等。 2. 表单参数:诸如action(表单提交的地址)、method(表单提交的协议,为GET或POST)等属性,它们决定了表单的行为特性。 3. 表单行为:诸如onsubmit(表单提交时触发的动作)、onchange(表单元素值变更时触发的动作)等事件,能够通过JavaScript进行响应式处理。 二、input元素视觉优化1. CSS定制:通过设定input元素的CSS属性,例如border(边框)、background-color(背景色)、padding(内边距)、font-size(字体大小)等,能够调整其视觉表现。 2. placeholder特性:提供预填的提示文字,以帮助用户明确输入框的预期用途。 3. 图标集成:借助:before和:after伪元素或者额外的HTML组件结合CSS定位技术,可以在输入框中嵌入图标,从而增强视觉吸引力。 三、select下拉框视觉优化1. 复选功能:通过设置multiple属性...
【EI复现】基于深度强化学习的微能源网能量管理与优化策略研究(Python代码实现)内容概要:本文围绕“基于深度强化学习的微能源网能量管理与优化策略”展开研究,重点探讨了如何利用深度强化学习技术对微能源系统进行高效的能量管理与优化调度。文中结合Python代码实现,复现了EI级别研究成果,涵盖了微电网中分布式能源、储能系统及负荷的协调优化问题,通过构建合理的奖励函数与状态空间模型,实现对复杂能源系统的智能决策支持。研究体现了深度强化学习在应对不确定性可再生能源出力、负荷波动等挑战中的优势,提升了系统运行的经济性与稳定性。; 适合人群:具备一定Python编程基础和机器学习背景,从事能源系统优化、智能电网、强化学习应用等相关领域的研究生、科研人员及工程技术人员。; 使用场景及目标:①应用于微能源网的能量调度与优化控制,提升系统能效与经济效益;②为深度强化学习在能源管理领域的落地提供可复现的技术路径与代码参考;③服务于学术研究与论文复现,特别是EI/SCI级别高水平论文的仿真实验部分。; 阅读建议:建议读者结合提供的Python代码进行实践操作,深入理解深度强化学习算法在能源系统建模中的具体应用,重点关注状态设计、动作空间定义与奖励函数构造等关键环节,并可进一步扩展至多智能体强化学习或与其他优化算法的融合研究。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值