引言

Redis的应用还得是在分布式系统当中。在分布式系统中，涉及到一个非常关键的问题，就是单点问题。例如，如果某个服务器程序，只有一个节点（只搞了一个物理服务器，来部署这个服务器程序），这样会带来几个缺点，第一个就是可用性问题，如果这个机器挂了，就会意味着服务就中断了；第二个就是性能问题，一个服务器程序支持的并发量是有限的。所以为了解决上述问题。就引入了分布式系统。
在分布式系统当中，往往希望有多个服务器来部署redis服务，从而构成一个redis集群，此时的就可以让这个集群给整个分布式系统中其他的服务，提供更稳定/高效的数据存储功能。
在分布式系统中，希望使用多个服务器来部署redis，存在以下几种redis的部署方式：

1. 主从复制模式。
2. 主从+哨兵模式
3. 集群模式

这篇博客就来讲解主从模式。

主从复制模式

在若干个redis节点中，有的是“主”节点，有的是“从”节点。如下图所示，有三个物理服务器（称为是三个节点）分别部署了一个redis-server进程，此时就可以把其中的一个节点，作为“主”节点，另外两个作为“从”节点。

从节点得听从主节点的（从节点上的数据要跟随主节点变化；从节点的数据要和主节点保持一致）
本来，在主节点上保存一堆数据，引入从节点之后，就是要把主节点上面的数据，复制出来，放到从节点中。后续，主节点这边对于数据有任何修改，都会把这样的修改同步到从节点上。简单来说，从节点就是主节点的副本。另外需要注意的是，主从模式中，从节点上的数据，不允许修改，只能读取数据。
由于从节点的数据时刻和主节点保持一致，因此其他的客户端从从节点这里读取数据，和从主节点这里读取数据，是没有区别的。后续如果有客户端来读取数据了，就可以从上述节点中，随机挑一个节点，给客户端提供读取数据的服务。
如果挂掉了某个从节点，对整体来说是没有影响到，此时继续从主节点或者其它从节点读取数据，得到的效果完全相同。但是主节点挂掉的话，还是有一定影响的，从节点只能读数据，如果需要写数据，就没法写了。

配置主从模式

大部分人的手中只有一台主机或者云服务器，要想打造一个分布式系统需要一点技巧。我们只需要保证每个进程的端口号不同，那么就可以存在多个redis-server。
我们先创建一个目录，来存放从节点的配置文件。

然后分别对拷贝过来的配置文件作修改

找到port选项，然后就行修改，由于主节点端口号是6379，因此为了不和主节点发生冲突，可以改成其他的值，我这个slave1.conf修改成了6380，另一个改成了6381。还需要把daemonize修改成yes，这样redis才能在后台启动。
修改完成后，通过以下命令进行启动：

redis-server 配置文件地址

启动后通过ps查看，可以看到同时有三个Redis在运行：

如果想要启动不同的客户端，只需要通过redis-cli -p 端口号进行启动。

---

修改完之后，这三个节点并没有构成主从结构，想要成为主从结构，还需要进一步的配置。配置从主从结构的方式有三种，需要使用slaveof。

1. 在配置文件中加入slaveof{masterHost}{masterPort}随Redis启动生效。
2. 在redis-server启动命令时加入--slaveof{masterHost}{masterPort}生效。
3. 直接使用redis命令：slaveof{masterHost}{masterPort}生效。

修改配置文件是永久生效的，其它两种方式需要手动生效。我们通过修改配置文件来实现主从结构。两个文件都要修改。

# 配置主从复制
slaveof 127.0.0.1 6379

修改完成之后，需要重新启动才能生效。
先使用kill -9 pid杀掉两个从节点。

接着重新启动两个从节点。

redis-server ./slave1.conf
redis-server ./slave1.conf

最后使用netstat查看网络情况。

可以发现，除了三个redis-server，还有很多其它的redis网络连接，这是因为主从之间，要进行数据传输，所以要创建额外的网络连接。其中一个redis从节点和主节点之间的tcp连接。从节点启动之后就会和主节点建立tcp连接。主节点相当于服务器，从节点相当于客户端。
现在来进行测试。

左边是主节点，右边是从节点。在主节点写入数据之后，从节点可以收到。但是在从节点上不能写入数据，只能读取数据。

info replication

我们可以通过info replication来查看主从节点相关的信息。

左边是主节点，右边是从节点。

• role：表示当前节点是主节点还是从节点。master为主节点，slave为从节点。
• connected_salves：表示有几个从节点连接。
• slave0：第一个从节点的相关信息。
  • offset：同步数据的进度，多个节点的该值不同，因为同步需要时间。
  • lag：当前主从节点之间数据传输的延迟
• master_replid：主节点的传输ID。
• offset：主节点的数据进度，与从节点的offset匹配，如果从节点的offset小于主节点，说明从节点没有同步完成，数据版本是落后的。
• repl_backlog_xxx：积压缓冲区。
• slave_priority：一个优先级，如果主节点崩溃了，会重新选主节点，与该优先级有关。

断开主从复制

slaveof命令不但可以建立复制，还可以在从节点执行slaveof no one来断开与主节点的复制关系，例如在6390节点上执行slaveof no one来断开复制。断开复制的主要流程是：

1. 断开与主节点复制关系。
2. 从节点上升为主节点。

从节点断开复制后并不会抛弃原有数据，只是无法再获取主节点上的数据变化。
通过 slaveof 命令还可以实现切主操作，将当前从节点的数据源切换到另⼀个主节点。执行
slaveof {newMasterIp} {newMasterPort} 命令即可。
切主操作主要流程：
1）断开与旧主节点复制关系。
2）与新主节点建立复制关系。
3）删除从节点当前所有数据。
4）从新主节点进行复制操作。
不管是salveof还是slaveof no one，都是临时进行修改，一旦服务器进行重启，那么依然会按照配置文件的主从关系执行。

---

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

---

传输延迟
主从节点⼀般部署在不同机器上，复制时的网络延迟就成为需要考虑的问题，Redis 为我们提供
了 repl-disable-tcp-nodelay参数用于控制是否关闭 TCP_NODELAY，默认为 no，即开启 tcp-nodelay 功能，说明如下：

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

拓扑

一主一从结构

一主一从结构式最简单的复制拓扑结构，用于主节点出现故障时从节点提供故障转移支持。当应用写命令并发量较高且需要持久化时，可以通过关闭主节点的AOF，只在从节点上开启AOF，这样既可以保证数据安全性的同时也避免了持久化对主节点的性能干扰。但是这种设定方法有一个严重的缺陷，主节点一旦挂了，不能让他自动重启，如果自动重启，此时没有AOF文件，就会丢失数据，进一步的主从同步，会把从节点的数据也给删了。
改进办法就是当主节点挂了之后，就需要让主节点从从节点这里获取到AOF文件，再启动。

一主多从结构

一主多从结构使得应用端可以利用多个从节点实现读写分离。对于读场景比较多的场景，可以把读命令负载均衡到不同的从节点上分担压力。同时一些耗时的读命令可以指定一台专门的从节点执行，避免破环整体的稳定性。对于写并发量较高的场景，多个从节点会导致主节点写命令的多次发送从而加重主节点的负载，

树形主从结构

树形主从结构（分层结构）使得从节点不但可以复制主节点数据，同时可以作为其他从节点的主节点继续向下层复制。通过引⼊复制中间层，可以有效降低住系欸按负载和需要传送给从节点的数据量。数据写⼊主节点之后会同步给 A 和 C 节点，A 节点进⼀步把数据同步给 B 和 D 节点。当主节点需要挂载等多个从节点时为了避免对主节点的性能干扰，可以采用这种拓扑结构。

主从复制原理

复制过程⼤致分为 6 个过程：

1. 保存主节点的信息
   开始配置主从同步关系之后，从节点只保存主节点的地址信息，即主节点的IP和端口信息。
2. 主从建立连接
   TCP的三次握手。从节点内部通过每秒运行的定时任务和维护复制相关逻辑，当定时任务发现存在新的主节点，会尝试与主节点建立基于TCP的网络连接。如果从节点无法建立连接，定时任务会无限重试直到连接成功或者用户停止主从复制。
3. 发送ping命令
   连接建立成功之后，从节点通过 ping 命令确认主节点在应⽤层上是工作良好的。如果 ping 命令的结果 pong 回复超时，从节点会断开 TCP 连接，等待定时任务下次重新建⽴连接。
4. 权限验证
   如果主节点设置了 requirepass 参数，则需要密码验证，从节点通过配置 masterauth参数来设置密码。如果验证失败，则从节点的复制将会停止。
5. 同步数据集
   对于首次建立复制的场景，主节点会把当前持有的所有数据全部发送给从节点，这步操作基本是耗时最长的，所以又划分称两种情况：全量同步和部分同步。
6. 命令持续复制
   当从节点复制了主节点的所有数据之后，针对之后的修改命令，主节点会持续的把命令发送给从节点，从节点执行修改命令，保证主从数据的⼀致性。

数据同步

redis提供了psync命令，完成数据同步的过程。psync不需要我们手动去执行，redis服务器会在建立好主从同步关系之后，自动执行psync。语法格式如下：

PSYNC replicationid offset

如果 replicationid 设为 ? 并且 offset 设为 -1 此时就是在尝试进行全量复制。
如果 replicationid offset 设为了具体的数值, 则是尝试进⾏部分复制。

• replication/replid（复制ID）

主节点的复制id。主节点重新启动，或者从节点晋升为主节点，都会生成一个replicationid。（同一个节点，每次重启，生成的replicationid也会变化）。从节点在和主节点建立连接之后，就会获取到主节点的replicationid。
通过 info replication 即可看到 replicationid。

master_replid:d5221004c144d5521a5ec2cf9efa60e6e5a2b0f5
master_replid2:0000000000000000000000000000000000000000

一般情况下replid2是用不上的。比如说有一个主节点A，还有一个从节点B。如果A和B通信过程中出现了一些网络抖动，B可能认为A挂了，B就会自己成为主节点(给自己生成了一个replid)，此时，B也会记得之前旧的replid，就是通过replid2，后续网络稳定了，B还可以根据replid2重新回到A。

---

• offset（偏移量）

参与复制的主从节点都会维护自身复制偏移量。主节点（master）在处理完写⼊命令后，会把命令的字节长度做累加记录，统计信息在 info replication 中的 master_repl_offset 指标中。

127.0.0.1:6379> info replication
# Replication
role:master
...
master_repl_offset:1055130

从节点（slave）每秒钟上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量，统计指标如下：

127.0.0.1:6379> info replication
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=1055214,lag=1
...

从节点在接受到主节点发送的命令后，也会累加记录自身的偏移量。统计信息在 info replication 中的slave_repl_offset 指标中：

127.0.0.1:6380> info replication
# Replication
role:slave
...
slave_repl_offset:1055214

psync运行流程

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

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

全量复制

全量复制是 Redis 最早支持的复制方式，也是主从第⼀次建立复制时必须经历的阶段。全量复制的运行流程如图所示。

1. 从节点发送psync命令给主节点进行数据同步，由于是第一次进行复制，从节点没有主节点的运行ID和复制偏移量，所以发送psync ? -1。
2. 主节点根据命令，解析出要进行全量复制，回复+FULLPESYNC响应。
3. 从节点接收主节点的运行信息进行保存。
4. 主节点执行bgsave进行RDB文件的持久化。
5. 从节点发送RDB文件给从节点，从节点保存RDB数据到本地硬盘。
6. 主节点将从生成RDB到接收完成期间执行的写命令，写入缓冲区中，等从节点保存RDB文件后，主节点再将缓冲区的数据补发给从节点，补发的数据仍然按照RDB的二进制格式追加写入到收到的RDb文件中，保持主从一致性。
7. 从节点清空自身原有旧数据。
8. 从节点加载RDB文件得到与主节点一致的数据。
9. 如果从节点加载RDB完成之后，并且开启了AOF持久化功能，它会进行bgrewrite操作，得到最近的AOF文件。

全量复制的场景发生在首次和主节点进行数据同步以及主节点不方便进行部分复制的时候。
全量复制是⼀件高成本的操作：主节点 bgsave 的时间，RDB 在网络传输的时间，从节点清空旧数据的时间，从节点加载 RDB 的时间等。所以⼀般应该尽可能避免对已经有⼤量数据集的 Redis 进⾏全量复制。

---

无硬盘模式
默认情况下, 进行全量复制需要主节点⽣成 RDB ⽂件到主节点的磁盘中, 再把磁盘上的 RDB文件通过发送给从节点。Redis 从 2.8.18 版本开始支持无磁盘复制。 主节点在执行 RDB ⽣成流程时, 不会⽣成 RDB 文件到磁盘中了, 而是直接把生成的 RDB 数据通过网络发送给从节点. 这样就节省了⼀系列的写硬盘和读硬盘的操作开销。
即使引入了无硬盘模式，仍然整个操作比较重，比较耗时的。因为网络传输时无法省略的，相比于网络传输来说，读写硬盘是小头。

部分复制

1. 当主节点之间出现网络中断时，如果超过repl-timeout时间，主节点会认为从节点故障并终端复制连接。
2. 主从连接中断期间主节点依然响应命令，但这些复制命令都因网络中断无法及时发送给从节点，所以暂时将这些命令滞留在复制积压缓冲区中。
3. 当主从节点网络恢复后，从节点再次连上主节点。
4. 从节点将之前保存的replicationid和复制偏移量作为psync的参数发送给主节点，请求进行部分复制。
5. 主节点接到psync请求后，进行必要的验证。随后根据offset去复制积压缓冲区查找合适的数据，并响应+CONTINUE给从节点。
6. 主节点将需要从节点同步的数据发送给从节点，最终完成一致性。

---

复制积压缓冲区
复制积压缓冲区是保存在主节点上的⼀个固定长度的队列，默认大小为 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 // 已保存数据的有效⻓度

实时复制

从节点已经和主节点同步好了数据，但是之后，主节点这边会源源不断的收到新的修改数据的请求，主节点上的数据就会随之改变，也需要能够同步给从节点。从节点和主节点之间会建立TCP的长连接，然后主节点把自己收到的修改数据的请求，通过上述连接，发送给主节点，从节点再根据这些修改请求，修改内存中的数据。
再进行实时复制的时候，需要保证连接处于可用状态，即通过过心跳包的方式来维护连接状态。

1. 主从节点彼此都有心跳检测机制，各⾃模拟成对方的客⼾端进行通信。
2. 主节点默认每隔 10 秒对从节点发送 ping 命令，判断从节点的存活性和连接状态。
3. 从节点默认每隔 1 秒向主节点发送 replconf ack {offset} 命令，给主节点上报自身当前的复制偏移量。

如果主节点发现从节点通信延迟超过 repl-timeout 配置的值（默认 60 秒），则判定从节点下线，断
开复制客⼾端连接。从节点恢复连接后，心跳机制继续进⾏。