Redis分布式部署方式-主从复制

分布式部署Redis方式

分布式系统，涉及到一个非常关键的问题：单点问题

单点问题：如果某个服务器，只有一个节点（只搞一个物理服务器，来部署这个服务器程序），会遇到一些困难：

可用性问题，如果这个机器挂了，意味着服务就中断了
性能/支撑的并发量也是比较有限的

引入分布式系统，主要也就是为了解决上述的单点问题，在分布式系统中，往往希望有多个服务器来部署redis服务，从而构成一个redis集群，此时就可以让这个集群给整个分布式系统中其他的服务，提供更稳定。高效的数据存储功能

在分布式系统中，希望使用多个服务器来部署reids，往往存在以下几种redis的部署方式

主从模式
主从+哨兵模式
集群模式

主从复制能解决的问题

主从模式：在若干个redis节点中，有的是"主"节点，有的是"从"节点；假设有三个物理服务器（称为是三个节点），分别部署了一个redis-server进程；此时就可以把其中的一个节点，作为"主节点"，另外两个节点作为"从节点"；从节点，得听主节点的（从节点上的数据要跟随主节点变化：从节点的数据要和主节点保持一致）

本来，在主节点上保存一堆数据；引入从节点之后，就是要把主节点上面的数据，复制出来，放到从节点中，后续，主节点这边对于数据有任何修改，都会把这样的修改给同步到从节点上（从节点，就是主节点的副本）

Question：如果我改了从节点的数据，是否是把从节点的数据往主节点上同步呢？

Answer：Redis主从模式中，从节点的数据，不允许修改，只能读取数据！！！

由于从节点的数据都是时刻和主节点保持一致的，因此其他的客户端从从节点这里读取数据，和从主节点这里读取数据都是一样的；后续如果有客户端来读取数据，就可以从上述节点中，随机挑一个节点，给这个客户端提供读取数据的服务

之前只是一个单个redis服务器节点，此时机器挂了，整个redis就挂了；上述这个主从结构，这些redis服务器不太可能"同时挂了"

Question：

但是整个机房是否可能被一锅端了？

如果是挂了某个从节点？

如果是挂了主节点呢？

是否可以引入多个主节点呢？

Answer：

这个时候如果考虑到更多的可用性，就可以把这些机器放到多个不同的机房中（异地多活）

没啥影响，此时继续从主节点或者其他从节点读取数据，得到的效果完全一致

还是有一点影响，从节点只能读数据，如果需要写数据，就没得写了（可用性是提高了，但是还没到非常理想的程度）

一山不容二虎，听谁的是个麻烦事！！

更准确的说，主从模式，主要是针对"读操作"，进行并发量&可用性的提高；而写操作的话，不论是可用性还是并发，都是非常依赖主节点，主节点又不能搞多个；实际业务场景中，读操作往往就是比写操作更频繁

主从结构，是分布式系统中比较经典的一种结构，不仅仅是redis，像MySQL等其他常用组件也常见的

如何启动多个redis-server

配置redis主从结构，首先需要启动多个redis服务器；正常来说，每个redis服务器程序，应该在一个单独的主机上（才是分布式）

可以在一个云服务器主机上，运行多个redis-server进程的，需要保证多个redis-server的端口是要不同的；本来redis-server默认的端口是6379，此时就不能让新启动的redis-server再继续使用6379了

Question：如何求指定redis-server的端口呢？

Answer：

可以在启动程序的时候，通过命令行来指定端口号 --port选项

也可以直接在配置文件中，来设定端口

此处准备搞一个主节点，两个从节点；主节点的配置不用变，只需要修改从节点的配置即可

bash 复制代码

redis-server  ./slave.conf

bash 复制代码

redis-server  ./slave2.conf

当前这几个节点并没有构成主从结构，而是各自为政，要想成为主从结构，还需要进一步的配置

bash 复制代码

redis-cli -p 6380

配置主从复制

有三种方法：

在配置⽂件中加⼊ slaveof {masterHost} {masterPort} 随 Redis 启动⽣效
在 redis-server 启动命令时加⼊ --slaveof {masterHost} {masterPort} ⽣效
直接使⽤ redis 命令：slaveof {masterHost} {masterPort} ⽣效。

使用配置文件来配置主从结构（持久）！！

redis服务器配置文件需要重启才能生效

这种停止redis-server的方式，是和直接运行redis-server命令的方式搭配的

如果使用service redis-server start这种方式启动的，就必须使用service redis-server stop 来进行停止的；此时如果使用kill -9 的方式停止，kill掉之后，这个redis-server进程就能自动启动（服务器就是要稳定性和高可用，但是服务器上的某些程序，可能也难以避免出现挂了的情况，如果服务器进程挂了，要是能自动重启进程（把进程再启动起来），对于整体的服务不会产生严重影响，往往会有另外一个进程来专门监控指定的服务器进程的运行状态）

程序启动起来，并且还多了一些TCP连接（其中一个redis节点，和主节点之间的tcp连接，从节点启动之后就会和主节点建立tcp连接；主节点就相当于服务器，从节点就相当于客户端）

查看主从结构信息

主节点这边数据产生的任何修改，从节点就能立即感知到，就是刚才看到的这些tcp连接起到的效果；从节点不能写入数据

bash 复制代码

info replication
//查看主从信息

okffset：主节点会受到源源不断的"修改数据"的请求，从节点就需要从主节点这里同步这些修改请求，从节点和主节点之间的数据同步，不是瞬间完成的，offset就相当于主节点和从节点之间，同步数据的进度！

lag：延迟

master_replid：当从节点出现网络波动的情况时才会起作用

reol_backlog：积压缓冲区，支持部分同步机制的实现

slave_read_only：可以在配置文件中配置修改

断开主从结构和修改主从结构

断开复制 slaveof 命令不但可以建⽴复制，还可以在从节点执⾏ slaveof no one 来断开与主节点复制关系，直接使用这个命令（redis客户端）断开现有的主从复制连接

例如在 6380 节点上执⾏ slaveof no one 来断开复制。断开复制主要流程

断开与主节点复制关系
从节点晋升为主节点

从节点断开复制后并不会抛弃原有数据，只是⽆法再获取主节点上的数据变化

通过 slaveof 命令还可以实现切主操作，将当前从节点的数据源切换到另⼀个主节点。执⾏ slaveof {newMasterIp} {newMasterPort} 命令即可。切主操作主要流程

断开与旧主节点复制关系
与新主节点建⽴复制关系
删除从节点当前所有数据
从新主节点进⾏复制操作。

此时，6380看起来像是个主节点，实际上不是，仍然是从节点，只是作为6381同步数据的来源，自身仍然是不能修改数据的

通过slaveof是修改了主从结构，此处的修改时临时性的，如果重新启动redis服务器，仍然会按照配置文件中的内容重启服务器

主从复制时的安全,只读,传输延时

安全性

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

只读

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

传输延迟

主从节点⼀般部署在不同机器上，复制时的⽹络延迟就成为需要考虑的问题，Redis 为我们提供了 repl-disable-tcp-nodelay（这个选项可以用于在主从同步通信过程中，关闭tcp的nagle算法，从节点更快速的和主节点进行同步）参数⽤于控制是否关闭 TCP_NODELAY，默认为 no，即开启 tcpnodelay 功能（TCP内部支持了nagle算法），说明如下

当关闭时，主节点产⽣的命令数据⽆论⼤⼩都会及时地发送给从节点，这样主从之间延迟会变⼩，但增加了⽹络带宽的消耗。适⽤于主从之间的⽹络环境良好的场景，如同机房部署（减少了tcp的传输延迟，增加了网络带宽）
当开启时（默认开启），主节点会合并较⼩的 TCP 数据包从⽽节省带宽。默认发送时间间隔取决于 Linux 的内核，⼀般默认为 40 毫秒。这种配置节省了带宽但增⼤主从之间的延迟。适⽤于主从⽹络环境复杂的场景，如跨机房部署（增加tcp的传输延迟，节省了网络带宽）

nagle算法目的和tcp的捎带应答是一样的，针对小的tcp数据报，进行合并，减少了包的个数

主从复制的拓扑结构

拓扑结构：若干个节点之间，按照什么样的方式进行组织连接

⼀主⼀从拓扑

如果写数据请求太多，此时也是会给主节点造成一些压力，可以通过关闭主节点的AOF，只在从节点上开启AOF

但是这种设定方式，有一个缺陷：主节点一旦挂了，不能让他自动重启（如果自动重启，此时没有AOF文件，就会丢失数据，进一步的主从同步，会把从节点的数据也给删了）

改进方法：当主节点挂了之后，就需要让主节点从从节点这里获取到AOF文件，在启动

实际开发中，读请求远远超过写请求

⼀主多从结构

主节点上的数据发生改变，就会把改变的数据同时同步给所有的从节点；随着从节点个数的增加，同步一条数据，就需要传输多次（扁平化结构）

树形主从结构

主节点就不需要那么高的网卡带宽了，一旦数据进行修改了，同步的延时是比刚才更长的

主从复制的基本流程

先保存主节点的IP和端口（变量）
建立TCP连接（三次握手），验证的是通信双方能否正确读写数据（系统层面）路是通的
发送ping，收到pong，验证主节点能否正常工作（站在应用程序的角度）车能跑
redis主节点开启了密码
复制数据最关键操作
5.全量同步+6.增量同步

redis提供了psync命令，完成数据同步的过程，psync不需要咱们手动执行，redis服务器会在建立好主从同步关系之后，自动执行psync，从节点负责执行psync，从节点从主节点这边拉取数据

bash 复制代码

PSYNC replicationid offset

replicationid的作用

replication-复制，是主节点生成的，主节点启动的时候就会生成（从节点晋升成主节点的时候，也会生成），即使是同一个主节点，每次重启，生成的replicationid都是不同的，从节点和主节点建立了复制关系，就会从主节点这边获取到replication id；当前讨论的是一个主节点多个从节点

bash 复制代码

info replication

获取到当前replication id 的值

一般情况下，replid2是用不上的，有一个主节点A（生成replid），还有一个从节点B（获取到A的relid），如果A和B通信过程中出现了一些网络抖动，B可能就会认为A挂了；B就会自己成为主节点（给自己生成replid），此时B也会记得之前旧的replid，就是通过replid2，后续网络稳定，B还可以根据replid2重新回到A的怀抱（需要手动干预，哨兵机制可以自动完成这个过程）

offset的作用

offset-偏移量，主节点和从节点都会维护偏移量（整数）

主节点的偏移量：主节点上会受到很多的修改操作的命令，每个命令都要占据几个字节，主节点会把这些修改命令，每个命令的字节数进行累加；

从节点的偏移量：描述了从节点这里的数据同步到了哪里；如果从节点和主节点的偏移量一致，说明已经赶上了！从节点（slave）每秒钟上报⾃⾝的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量

replid + offset 共同标识了⼀个 "数据集". 如果两个节点, 他们的 replid 和 offset 都相同, 则这两个节点上持有的数据, 就⼀定相同.

psync 运⾏流程

从节点发送 psync 命令给主节点，replid 和 offset 的默认值分别是 ? 和 -1
主节点根据 psync 参数和⾃⾝数据情况决定响应结果：

如果回复 +FULLRESYNC replid offset，则从节点需要进⾏全量复制流程
如果回复 +CONTINEU，从节点进⾏部分复制流程
如果回复 -ERR，说明 Redis 主节点版本过低，不⽀持 psync 命令。从节点可以使⽤ sync 命令进⾏全量复制

psync ⼀般不需要⼿动执⾏. Redis 会在主从复制模式下⾃动调⽤执⾏
sync 会阻塞 redis server 处理其他请求. psync 则不会.

全量复制和部分复制

Question：

什么时候进行全量复制？

什么时候进行部分复制？

Answer：

首次和主节点进行数据同步

主节点不方便进行部分复制的时候

从节点之前已经从主节点上复制过数据了，因为网络抖动或者从节点重启了

从节点需要重新从主节点这边进行同步数据，此时看看能不能只同步一小部分（大部分数据都是一致的）

全量复制的流程

从节点发送 psync 命令给主节点进⾏数据同步，由于是第⼀次进⾏复制，从节点没有主节点的运⾏ ID 和复制偏移量，所以发送 psync ? -1
主节点根据命令，解析出要进⾏全量复制，回复 +FULLRESYNC 响应
从节点接收主节点的运⾏信息进⾏保存
主节点执⾏ bgsave 进⾏ RDB ⽂件的持久化，rdb文件是二进制格式的，比较省空间
主节点发送 RDB ⽂件给从节点，从节点保存 RDB 数据到本地硬盘，不能使用原有的rdb文件，而是必须要重新生成，已有的rdb文件可能会和当前的数据存在较大的差异，在主节点生成rdb文件和传输rdb文件的过程中，还会继续收到很多新的修改操作，新修改的数据，也必须要同步给从节点
主节点将从⽣成 RDB 到接收完成期间执⾏的写命令，写⼊缓冲区中，等从节点保存完 RDB ⽂件后，主节点再将缓冲区内的数据补发给从节点，补发的数据仍然按照 rdb 的⼆进制格式追加写⼊到收到的 rdb ⽂件中. 保持主从⼀致性
从节点清空⾃⾝原有旧数据
从节点加载 RDB ⽂件得到与主节点⼀致的数据
如果从节点加载 RDB 完成之后，并且开启了 AOF 持久化功能，它会进⾏ bgrewrite 操作，得到最近的 AOF ⽂件，产生很多AOF日志，由于当前收到的是大批量的数据，会有冗余数据，所以进行bgrewrite操作

全量复制的无硬盘模式

主节点，进行全量复制的时候，也支持"无硬盘模式"，主节点生成的rdb文件的二进制数据，不是保存到文件中，而是直接网络传输了（省下了一系列读硬盘和写硬盘的操作），从节点之前也是把收到的rdb数据，写入到硬盘中，然后再加载，现在也可以省略这个过程，直接把收到的数据进行加载了

即使引入了无硬盘模式，仍然这个操作是比较重量，比较耗时的，网络传输（大规模数据->全量复制）是没法省的，相比于网络传输来说，读写硬盘是小头

有磁盘复制 vs ⽆磁盘复制(diskless) 默认情况下, 进⾏全量复制需要主节点⽣成 RDB ⽂件到主节点的磁盘中, 再把磁盘上的 RDB ⽂件通过发送给从节点. Redis 从 2.8.18 版本开始⽀持⽆磁盘复制. 主节点在执⾏ RDB ⽣成流程时, 不会⽣成 RDB ⽂件到磁盘中了, ⽽是直接把⽣成的 RDB 数据通过⽹络发送给从节点. 这样就节省了⼀系列的写硬盘和读硬盘的操作开销

关于runid和replid

一个redis服务器上，replication id 和run id是都存在的，两个不同的id，看起来非常像

长度相同，格式也非常相似

run id是每个节点都不相同的，replid则是具有主从关系的节点

官方文档，明确表示，psync使用的是replicationid

runid是标识一次redis的"运行"，和主从复制没有什么关系，和哨兵有关系

replid和主从复制有关系，在主从复制中起作用的

replid+offset共同标识了一个数据集合！！！

部分复制的流程

出现网络抖动，主节点最近修改的数据可能无法及时同步过来，更严重的，从节点已经感知不到主节点了（从节点可能会晋升主节点），网络抖动，一般都是"暂时的"，此时就可以让主节点和从节点重新建立联系；当主节点和从节点重新建立连接之后，就需要进行数据的同步

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

当主从节点之间出现⽹络中断时，如果超过 repl-timeout 时间，主节点会认为从节点故障并终端复制连接
主从连接中断期间主节点依然响应命令，但这些复制命令都因⽹络中断⽆法及时发送给从节点，所以暂时将这些命令滞留在复制积压缓冲区中
当主从节点⽹络恢复后，从节点再次连上主节点
从节点将之前保存的 replicationId （描述数据的来源，如果replicationid不一样，说明这个从节点就是专捅义父，需要全量复制）和复制偏移量（数据的复制的进度，从节点之前同步数据的进度，主节点就看这个进度是否在当前的积压缓冲区之内，如果确实是在积压缓冲区之内，此时就可以直接进行部分复制，就只把最近的数据同步过去即可）作为 psync 的参数发送给主节点，请求进⾏部分复制
主节点接到 psync 请求后，进⾏必要的验证。随后根据 offset 去复制积压缓冲区查找合适的数据，并响应 +CONTINUE 给从节点
主节点将需要从节点同步的数据发送给从节点，最终完成⼀致性。

复制积压缓冲区复制积压缓冲区是保存在主节点上的⼀个固定⻓度的队列，默认⼤⼩为 1MB，当主节点有连接的从节点（slave）时被创建，这时主节点（master）响应写命令时，不但会把命令发送给从节点，还会写⼊复制积压缓冲区，如图所⽰。

由于缓冲区本质上是先进先出的定⻓队列，所以能实现保存最近已复制数据的功能，⽤于部分复制和复制命令丢失的数据补救。复制缓冲区相关统计信息可以通过主节点的 info replication 中：

bash 复制代码

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 // 已保存数据的有效⻓度

根据统计指标，可算出复制积压缓冲区内的可⽤偏移量范围：[repl_backlog_first_byte_offset, repl_backlog_first_byte_offset + repl_backlog_histlen]

这个相当于⼀个基于数组实现的环形队列. 上述区间中的值就是 "数组下标" .

如果当前从节点需要的数据, 已经超出了主节点的积压缓冲区的范围, 则⽆法进⾏部分复制, 只能全量复制了.

实时复制的流程

全量复制：从节点刚连上主节点之后，进行的数据初始化工作
部分复制：全量复制的特殊情况，优化手段，目的和全量复制一样
实时复制：从节点，已经和主节点，同步好数据了（从节点这一时刻已经和主节点数据一致了），但是之后，主节点这边会源源不断的收到新的修改数据的请求，主节点上的数据也会随之改变，也需要能够同步给从节点
从节点和主节点之间会建立TCP的长连接，然后主节点会把自己受到的修改数据的请求，通过上述连接发给从节点，从节点再根据这些修改请求，修改内存中的数据，这个过程也是需要时间的，正常来说是比较短的，但是如果是树形结构（级别很多），延时也就变大了
在进行实时复制的时候，需要保证连接处于可用状态--心跳包机制，主节点默认每10s给从节点发送一个ping命令，从节点收到就返回pong；从节点默认每隔1s就给主节点发起一个特点的请求，就会上报当前从节点复制的进度（offset）
如果没有收到pong，有一个阈值（60s），就会认为从节点有问题，判定从节点下线
这些时间都是可以修改的！