Redis部署-主从模式

1.在配置⽂件中加⼊ slave of {masterHos t} {masterPo rt} 随 Redis 启动⽣效。
2. 在 redis-server 启动命令时加⼊ —slaveof {masterHos t} {m a sterPort} ⽣效。
3. 直接使⽤ redis 命令：slaveof {m a sterHos t} {m a sterPort} ⽣效

这里推荐使用修改配置文件的方式,会一直持久生效.

我们配置以6379为主节点,6380和6381为从节点.

在从节点的配置文件中加入 slaveof配置项.

修改完配置文件之后,需要重新启动才能生效.

我们要使用kill -9的方式来停止这两个redis-server,这个停止方式是和我们直接运行redis的时候的命令是搭配的.

而如果是使用service redis-server start的方式启动,则必须使用service redis-server stop来进行停止.此时如果使用kill -9的方式停止,这个redis-server 进程会自动启动.

当重新启动后,从节点和主节点之间就建立了tcp 连接.

主节点这边数据产生的修改,从节点就能立即感知到,就是上述这些tcp 连接起到的效果.

此时在从节点中写入数据就会报错!!!

info repli cat ion命令查看 复制 相关的状态

主节点的复制状态信息

从节点的复制状态信息(6380)

offset就表示从节点和主节点之间同步数据的进度.(从节点和主节点之间的数据同步不是瞬间完成的,靠网络传输,所以有延迟)

replid可以认为是主节点的身份标识.

断开 复制 关系

slaveof命令不仅可以建立复制,还可以在从节点上执行slaveof no one命令来断开与主节点之间的复制关系.

断开复制关系流程包括两步:

1.断开与主节点之间的复制关系.

2.从节点晋升为主节点.

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

通过slaveof命令还可以实现切换主节点的操作,,将当前从节点的数据源切换到另⼀个主节点。执⾏

slaveof {newMasterIp} {newMasterPort} 命令即可。

切主操作的主要流程:

断开与旧主节点的复制关系.
与新主节点建立复制关系
删除从节点上当前的所有数据
与新主节点进行复制操作

安全性

对于数据⽐较重要的节点，主节点会通过设置 require pass 参数进⾏密码验证，这时所有的客⼾
端访问必须使⽤ auth 命令实⾏校验。从节点与主节点的复制连接是通过⼀个特殊标识的客⼾端来完成，因此需要配置从节点的masterauth 参数与主节点密码保持⼀致，这样从节点才可以正确地连接到主节点并发起复制流程。

只读

默认情况下，从节点使⽤ slave-read–only=y es 配置为只读模式。由于复制只能从主节点到从节
点，对于从节点的任何修改主节点都⽆法感知，修改从节点会造成主从数据不⼀致。所以建议线上不要修改从节点的只读模式。

主从节点⼀般部署在不同机器上，复制时的⽹络延迟就成为需要考虑的问题，Redis 为我们提供
了 repl-disable-t cp–nodelay 参数⽤于控制是否关闭 TCP_NODELAY，默认为 no，即开启 t cp _nodelay 功能，说明如下：
• 当关闭时，主节点产⽣的命令数据⽆论⼤⼩都会及时地发送给从节点，这样主从之间延迟会变⼩，但增加了⽹络带宽的消耗。适⽤于主从之间的⽹络环境良好的场景，如同机房部署。
• 当开启时，主节点会合并较⼩的 TCP 数据包从⽽节省带宽。默认发送时间间隔取决于 Linux 的内
核，⼀般默认为 40 毫秒。这种配置节省了带宽但增⼤主从之间的延迟。适⽤于主从⽹络环境复杂
的场景，如跨机房部署.

拓扑结构

主从模式的拓扑结构描述了若干个节点之间,是按照什么样的方式来进行组织连接的.

常见的拓扑结构有:一主一从拓扑,一主多从拓扑和树形拓扑.

一主一从

如果写数据的请求太多,此时也会给主节点造成很大压力,可以通过关闭主节点的AOF来缓解主节点的压力,只在从节点这里开启 aof.

但是这种设定方式,有一个严重缺陷:主节点一旦宕机,不能让它自动重启,如果自动重启,此时没有 aof 文件,就会丢失数据,进一步的主从同步会把从节点的数据也给删除.

所以,当主节点挂了之后,就需要让主节点从从节点这里获取到aof的文件,在启动.

一主多从

扁平化结构,此结构一旦从节点个数增加很多,那么主节点同步一条数据就需要传输多次,可能会消耗大量的网络带宽.

树形结构

主节点同步数据不会消耗那么多的网络带宽了,但是一旦数据进行同步,同步的延迟是比较长的,因为要要进行多次网络传输.

复制过程

注意的是其中同步数据集这步操作,对于首次建立复制的场景,主节点会把当前所持有的所有数据全部发送给从节点,这步的操作耗时最长,所以又划分为两种情况:全量复制和部分复制.

数据同步psync

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

psync不需要我们手动执行,redis服务器会在建立好主从复制关系之后,自动执行psync.

从节点负责执行psync,从节点从主节点这边拉取数据.

psyn c的命令格式:PSYNC repli cat ionid offset.

如果repli cation id设为?,offset设为-1,此时就是在尝试进行全量复制.

如果repli cationid和offset 设置了具体的值,则是尝试进行部分复制.

repli cationid

repli cation是复制的意思,这个就表示是一个复制id.

repli cationid是由主节点生成的,主节点启动的时候就会生成,从节点晋升为主节点的时候,也会生成.

(即使是同一个主节点,每次重启的时候,生成的repli cationid都是不同的).

从节点和主节点建立了复制关系,从节点就会从主节点这里获取到replica tionid.

一般replid2用不上.假设此时有一个主节点A和一个从节点B.A负责生成replid,B负责获取A的replid.

如果A和B在通信过程中出现了网络抖动,B可能会认为A挂了,此时B就会自己成为主节点,(给自己也生成一个replid),但是B也会保存之前旧的replid,这个旧的replid就会保存在replid2中,方便后续网络稳定之后,B重新与A建立复制关系.在主从模式下,上述过程需要手动干预,而哨兵模式下可以自动完成.

off set

表示偏移量.主节点和从节点上都会维护偏移量(整数).

主节点的偏移量会根据收到的修改命令占据的字节数来将off set进行累加.

从节点的偏移量就描述了,当前从节点数据同步的进度.

如果主节点的off set和从节点的off set一样,就说明从节点的数据和主节点的数据一致了.

从节点每秒钟会上报自身的复制偏移量给主节点.

综上,replica tionid和off set就描述出一个数据集,就可以表示从节点从哪里复制的数据,复制到哪里了!!!!

psyn c运行流程

从节点发送psyn c命令给主节点,replid和offset的默认值分别是?和-1.
主节点根据psync的参数和自身的情况决定响应结果.
如果回复+FULLRESYNC replid offset,则从节点需要进行全量复制流程
如果回复+CONTINUE,从节点进行部分复制流程
如果回复-ERR,说明redis主节点版本过低,不支持psync命令.此时从节点可以使用sync命令进行全量复制.

注意:psync一般不需要进行手动执行,redis会在主从模式下自动调用执行.

sy nc命令(1.0.0版本就有),会阻塞redis-server 处理其他的请求,而ps y nc命令则不会.

全量复制流程

何时进行全量复制:首次和主节点进行数据同步或者主节点不方便进行部分复制的时候.

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

2）主节点根据命令，解析出要进⾏全量复制，回复 +FULLRESYNC 响应。

3）从节点接收主节点的运⾏信息进⾏保存。

4）主节点执⾏ b gsave 进⾏ RDB ⽂件的持久化。

5）主节点发送 RDB ⽂件给从节点，从节点保存 RDB 数据到本地硬盘。

6）主节点将从⽣成 RDB 到接收完成期间执⾏的写命令，写⼊缓冲区中，等从节点保存完 RDB ⽂件后，主节点再将缓冲区内的数据补发给从节点，补发的数据仍然按照 rdb 的⼆进制格式追加写⼊到收到的 rdb ⽂件中. 保持主从⼀致性。

7）从节点清空⾃⾝原有旧数据。

8）从节点加载 RDB ⽂件得到与主节点⼀致的数据。

9）如果从节点加载 RDB 完成之后，并且开启了 AOF 持久化功能，它会进⾏ b g rewrite 操作，得到最近的 AOF ⽂件.

注意:在主节点生成 rdb 文件和传输 rdb 文件的过程中,还会继续收到很多新的修改操作.新修改的数据也必须要同步给从节点,所以当从节点接收完从主节点发送来的rdb 文件之后,主节点还要把新修改的操作也要发给从节点.

无硬盘模式

Redis从2.8.18版本开始支持无硬盘模式的全量复制.

主节点生成的rdb 二进制数据不在直接保存在文件中了,而是直接进行网络传输给从节点,这样就省下了一系列的读硬盘和写硬盘的操作.

从节点之前也是先把收到的rdb数据写入到硬盘中,然后再加载到内存,在此模式下,也可以直接把收到的数据进行加载.

需要注意的是虽然引入了无硬盘模式,但是整个全量复制的过程仍然是比较重量比较耗时的.网络传输是大头!!!

部分复制流程

全量复制虽然稳妥,但是比较低效,开销比较大.

有些时候,从节点本身已经持有了主节点的绝大部分数据,就不需要再进行全量复制了.

比如出现网络抖动,主节点最近修改的数据无法同步给从节点,进一步可能从节点已经感知不到主节点了.但是网络抖动一般是暂时的,网络恢复之后,此时就可以让从节点和主节点重新建立连接.重建连接之后,再进行数据的同步,具体是全量复制还是部分部分复制还是要看具体的交互流程.

psync带有具体的参数值,主节点就要根据参数和当前自身情况进行判定,当前这次是按照全量复制合适还是部分复制合适.

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

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

3）当主从节点⽹络恢复后，从节点再次连上主节点。

4）从节点将之前保存的 replica tionId 和复制偏移量作为 psync 的参数发送给主节点，请求进⾏部分复制。

5）主节点接到 psync 请求后，进⾏必要的验证。随后根据 offset 去复制积压缓冲区查找合适的数据，并响应 +CONTINUE 给从节点。如果数据在积压缓冲区内能找到,说明从节点拉下的进度不多,就进行部分复制;如果确实当前从节点拉下的进度已经超出积压缓冲区的范围了,就只能进行全量复制了.

6）主节点将需要从节点同步的数据发送给从节点，最终完成⼀致性.

所以部分复制可以理解为全量复制的特殊情况,是一种全量复制的优化手段!!!!

积压缓冲区

积压缓冲区是保存在主节点上的⼀个固定⻓度的队列，默认⼤⼩为 1MB，当主节点有连接的从节点（slave）时被创建，这时主节点（m aster）响应写命令时，不但会把命令发送给从节点，还会写⼊复制积压缓冲区.由于缓冲区本质上是先进先出的定⻓队列，所以能实现保存最近已复制数据的功能，⽤于部分复制和复制命令丢失的数据补救.