码迷,mamicode.com
首页 > 其他好文 > 详细

slaveof复制原理

时间:2018-08-27 12:42:36      阅读:542      评论:0      收藏:0      [点我收藏+]

标签:ble   级别   gre   表示   实时   aof   aof文件   内存   ack   

1、简介(主从节点)
参与复制的Redis实例划分为主节点(master)和从节点(slave)。默认 情况下,Redis都是主节点。每个从节点只能有一个主节点,而主节点可以 同时具有多个从节点。复制的数据流是单向的,只能由主节点复制到从节 点。配置复制的方式有以下三种:
1)在配置文件中加入slaveof{masterHost}{masterPort}随Redis启动生效
技术分享图片
2)在redis-server启动命令后加入--slaveof{masterHost}{masterPort}生效
3)直接使用命令:slaveof{masterHost}{masterPort}生效。

2、断开复制
slaveof命令不但可以建立复制,还可以在从节点执行slaveof no one来断 开与主节点复制关系。例如在6380节点上执行slaveof no one来断开复制,如 图所示。
技术分享图片
断开复制主要流程:
1)断开与主节点复制关系。
2)从节点晋升为主节点。

切主后从节点会清空之前所有的数据,线上人工操作时小心slaveof在错 误的节点上执行或者指向错误的主节点。
备注:复制方式:主从,主从从原理,如下图
技术分享图片
3、安全性
对于数据比较重要的节点,主节点会通过设置requirepass参数进行密码 验证,这时所有的客户端访问必须使用auth命令实行校验。从节点与主节点 的复制连接是通过一个特殊标识的客户端来完成,因此需要配置从节点的masterauth参数与主节点密码保持一致,这样从节点才可以正确地连接到主 节点并发起复制流程。

3.1、只读
默认情况下,从节点使用slave-read-only=yes配置为只读模式。由于复 制只能从主节点到从节点,对于从节点的任何修改主节点都无法感知,修改从节点会造成主从数据不一致。因此建议线上不要修改从节点的只读模式。

4、传输延迟
主从节点一般部署在不同机器上,复制时的网络延迟就成为需要考虑的 问题,Redis为我们提供了repl-disable-tcp-nodelay参数用于控制是否关闭 TCP_NODELAY,默认关闭,说明如下:
1) ·当关闭时,主节点产生的命令数据无论大小都会及时地发送给从节 点,这样主从之间延迟会变小,但增加了网络带宽的消耗。适用于主从之间的网络环境良好的场景,如同机架或同机房部署。
2)·当开启时,主节点会合并较小的TCP数据包从而节省带宽。默认发送 时间间隔取决于Linux的内核,一般默认为40毫秒。这种配置节省了带宽但 增大主从之间的延迟。适用于主从网络环境复杂或带宽紧张的场景,如跨机
房部署。

备注:部署主从节点时需要考虑网络延迟、带宽使用率、防灾级别等因素,如 要求低延迟时,建议同机架或同机房部署并关闭repl-disable-tcp-nodelay;如 果考虑高容灾性,可以同城跨机房部署并开启repl-disable-tcp-nodelay。

5、原理
5.1、复制过程大致分为6个过程:
1)保存主节点(master)信息。
技术分享图片
2)从节点(slave)内部通过每秒运行的定时任务维护复制相关逻辑, 当定时任务发现存在新的主节点后,会尝试与该节点建立网络连接,如图所示。
技术分享图片
3)发送ping命令。
连接建立成功后从节点发送ping请求进行首次通信,ping请求主要目的 如下:
·检测主从之间网络套接字是否可用。
·检测主节点当前是否可接受处理命令。
4)权限验证。如果主节点设置了requirepass参数,则需要密码验证, 从节点必须配置masterauth参数保证与主节点相同的密码才能通过验证;如 果验证失败复制将终止,从节点重新发起复制流程。
5)同步数据集。主从复制连接正常通信后,对于首次建立复制的场 景,主节点会把持有的数据全部发送给从节点,这部分操作是耗时最长的步
骤。Redis在2.8版本以后采用新复制命令psync进行数据同步,原来的sync命 令依然支持,保证新旧版本的兼容性。新版同步划分两种情况:全量同步和 部分同步。
6)命令持续复制。当主节点把当前的数据同步给从节点后,便完成了 复制的建立流程。接下来主节点会持续地把写命令发送给从节点,保证主从
数据一致性。

5.2、数据同步
Redis在2.8及以上版本使用psync命令完成主从数据同步,同步过程分 为:全量复制和部分复制。
·全量复制:一般用于初次复制场景,Redis早期支持的复制功能只有全 量复制,它会把主节点全部数据一次性发送给从节点,当数据量较大时,会对主从节点和网络造成很大的开销。
·部分复制:用于处理在主从复制中因网络闪断等原因造成的数据丢失 场景,当从节点再次连上主节点后,如果条件允许,主节点会补发丢失数据
给从节点。因为补发的数据远远小于全量数据,可以有效避免全量复制的过 高开销。
psync命令运行需要以下组件支持:
·主从节点各自复制偏移量。
·主节点复制积压缓冲区
·主节点运行id。
1)复制偏移量
参与复制的主从节点都会维护自身复制偏移量。主节点(master)在处理完写入命令后,会把命令的字节长度做累加记录,统计信息在info relication中的master_repl_offset指标中:
技术分享图片
从节点(slave)每秒钟上报自身的复制偏移量给主节点,因此主节点 也会保存从节点的复制偏移量,统计指标如下:
技术分享图片
从节点在接收到主节点发送的命令后,也会累加记录自身的偏移量。统 计信息在info relication中的slave_repl_offset指标中:
技术分享图片
通过对比主从节点的复制偏移量,可以判断主从节点数据是否一致。
备注:可以通过主节点的统计信息,计算出master_repl_offset-slave_offset字节 量,判断主从节点复制相差的数据量,根据这个差值判定当前复制的健康 度。如果主从之间复制偏移量相差较大,则可能是网络延迟或命令阻塞等原因引起。

2)复制积压缓冲区
复制积压缓冲区是保存在主节点上的一个固定长度的队列,默认大小为 1MB,当主节点有连接的从节点(slave)时被创建,这时主节点(master) 响应写命令时,不但会把命令发送给从节点,还会写入复制积压缓冲区,如 图
技术分享图片
复制偏移量维护
技术分享图片
复制积压缓冲区示意图
由于缓冲区本质上是先进先出的定长队列,所以能实现保存最近已复制 数据的功能,用于部分复制和复制命令丢失的数据补救。复制缓冲区相关统计信息保存在主节点的info replication中:
127.0.0.1:6379> info replication

Replication

role:master...
repl_backlog_active:1 // 开启复制缓冲区
repl_backlog_size:1048576 // 缓冲区最大长度
repl_backlog_first_byte_offset:7479 // 起始偏移量,计算当前缓冲区可用范围
repl_backlog_histlen:1048576 // 已保存数据的有效长度。

3).主节点运行ID
每个Redis节点启动后都会动态分配一个40位的十六进制字符串作为运 行ID。运行ID的主要作用是用来唯一识别Redis节点,比如从节点保存主节 点的运行ID识别自己正在复制的是哪个主节点。如果只使用ip+port的方式识别主节点,那么主节点重启变更了整体数据集(如替换RDB/AOF文件), 从节点再基于偏移量复制数据将是不安全的,因此当运行ID变化后从节点将 做全量复制。可以运行info server命令查看当前节点的运行ID:
技术分享图片
当需要调优一些内存相关配置,例如:hash-max-ziplist-value等,这些配 置需要Redis重新加载才能优化已存在的数据,这时可以使用debug reload命 令重新加载RDB并保持运行ID不变,从而有效避免不必要的全量复制。命令 如下:
[root@master ~]# redis-cli -p 6379 -h 192.168.56.129 info server | grep run_id
技术分享图片
[root@master ~]# redis-cli -h 192.168.56.129 debug reload
备注:debug reload命令会阻塞当前Redis节点主线程,阻塞期间会生成本地 RDB快照并清空数据之后再加载RDB文件。因此对于大数据量的主节点和无法容忍阻塞的应用场景,谨慎使用。
4).psync命令
从节点使用psync命令完成部分复制和全量复制功能,命令格式: psync{runId}{offset},参数含义如下:
·runId:从节点所复制主节点的运行id。
·offset:当前从节点已复制的数据偏移量。
psync命令运行流程
技术分享图片
流程说明:
1)从节点(slave)发送psync命令给主节点,参数runId是当前从节点保 存的主节点运行ID,如果没有则默认值为,参数offset是当前从节点保存的 复制偏移量,如果是第一次参与复制则默认值为-1。
2)主节点(master)根据psync参数和自身数据情况决定响应结果:
·如果回复+FULLRESYNC{runId}{offset},那么从节点将触发全量复制流程。
·如果回复+CONTINUE,从节点将触发部分复制流程。
·如果回复+ERR,说明主节点版本低于Redis2.8,无法识别psync命令, 从节点将发送旧版的sync命令触发全量复制流程。

5.3、心跳
主从节点在建立复制后,它们之间维护着长连接并彼此发送心跳命令, 如图
技术分享图片
主从心跳判断机制:
1)主从节点彼此都有心跳检测机制,各自模拟成对方的客户端进行通 信,通过client list命令查看复制相关客户端信息,主节点的连接状态为 flags=M,从节点连接状态为flags=S。
2)主节点默认每隔10秒对从节点发送ping命令,判断从节点的存活性 和连接状态。可通过参数repl-ping-slave-period控制发送频率。
3)从节点在主线程中每隔1秒发送replconf ack{offset}命令,给主节点 上报自身当前的复制偏移量。replconf命令主要作用如下:
·实时监测主从节点网络状态。
·实现保证从节点的数量和延迟×××,通过min-slaves-to-write、min-slaves-max-lag参数配置定义。
主节点根据replconf命令判断从节点超时时间,体现在info replication统 计中的lag信息中,lag表示与从节点最后一次通信延迟的秒数,正常延迟应 该在0和1之间。如果超过repl-timeout配置的值(默认60秒),则判定从节点下线并断开复制客户端连接。即使主节点判定从节点下线后,如果从节点重 新恢复,心跳检测会继续进行。

5.4、异步复制
主节点不但负责数据读写,还负责把写命令同步给从节点。写命令的发 送过程是异步完成,也就是说主节点自身处理完写命令后直接返回给客户 端,并不等待从节点复制完成,如图
技术分享图片
主节点复制流程:
1)主节点6379接收处理命令。
2)命令处理完之后返回响应结果。
3)对于修改命令异步发送给6380从节点,从节点在主线程中执行复制 的命令。

   由于主从复制过程是异步的,就会造成从节点的数据相对主节点存在延 迟。具体延迟多少字节,我们可以在主节点执行info replication命令查看相关指标获得。如下:

技术分享图片
在统计信息中可以看到从节点slave0信息,分别记录了从节点的ip和 port,从节点的状态,offset表示当前从节点的复制偏移量, master_repl_offset表示当前主节点的复制偏移量,两者的差值就是当前从节 点复制延迟量。Redis的复制速度取决于主从之间网络环境,repl-disable-tcp-nodelay,命令处理速度等。正常情况下,延迟在1秒以内。

slaveof复制原理

标签:ble   级别   gre   表示   实时   aof   aof文件   内存   ack   

原文地址:http://blog.51cto.com/13941177/2164815

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!