Redis分布式系统: 主从复制

“你小心保管我，不思议的念头。秘密从不会对谁泄漏~”

什么是分布式系统？

分布式系统的出现，就是为了解决单机问题(硬件资源不足)。在分布式系统中，通常会把数据复制多个副本部署到其他服务器，满⾜故障恢复和负载均衡等需求。

分布式系统中，往往会在多个服务器上部署redis服务，从而构成一个redis集群。此时，就可以让这个redis集群，为整个分布式的服务器提供更加稳定、高效的数据存储功能。

redis部署方式:

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

○ 主从模式

○ 主从+哨兵模式

○ 集群模式

什么是主从模式？

可以把每个服务器上的redis服务看成是一个节点。在这些若干节点中，有些是“主节点”，其他的为“从节点”。

假设现在有3个物理服务器，我们在这3个物理服务器上分别部署3个redis服务。此时，我们可以把其中的一个redis服务当成“主节点”，另外两个就当成“从节点”。“从节点”必须得听“主节点”的。(从节点的数据，需要跟随主节点的数据的变化而变化。始终与主节点的数据保持一致)。

也许你会说，如果针对了从节点的数据进行了修改，那么主节点又该怎么办？实际上，如果我修改了从节点的数据，就和主节点的数据不一致了，我们是否应该把从节点的数据同步到主节点上呢？答案是否定的！

Redis的主从模式中，“从节点上的数据只允许读取，但不允许修改！”

主从模式的特点:

所以，更准确地来说，主从模式主要还是优化保证的是: “读操作”的高并发、可用性。而写操作，无论是高并发、可用性都是十分依赖主节点的。实际场景中，读操作往往也比写操作频繁。

另外，如果主从模式中的从节点出现问题，挂掉了，对整个系统影响很小。当这个从节点重新恢复时，可以再从主节点同步、获取数据。但，如果是主节点挂掉了，还是有一定的影响。因为从节点只能读取，而不能写入，如果需要写入数据，那么可能就会发生错误。

当然，能不能出现多个主节点呢？那就不怕主节点挂掉了。可是，这又会引入一个它们之间“数据又该如何同步”的问题。

如何建立主从复制？

正常来说，每个redis都需要部署在单独的物理机器上。但，对于学生党来说，可能只有一台服务器。但这并不意味着我们不能模拟主从结构。

我们可以在一台云服务器上启动多个redis-server用来模拟多个redis服务。本来，redis-server默认的端口号为6379，因为我们需要在一台云服务器上启动多个redis-server，它们需要bind不同的端口号。

所以，我们需要更改原先的redis-server启动的配置文件，直接在配置文件中修改port即可。

注: 我们还需要开启守护进程:

修改完这些配置后，我们就可以在同一台服务器上启动redis-server。

配置主从结构

要想配置主从结构，就需要使用slaveof

1. 在配置文件中加入 salveof {masterHost} {masterPort} 生效。

2. 在redis-server 命令启动时加入 --salveof {masterHost} {masterPort} 生效。

3. 直接使用redis命令: salveof {masterHost} {masterPort} 生效。

因为后两个方法不是"永久的"，所以我们还是选择在配置文件上做这个事情。此处让6379为主节点，6380、6381为从节点。

修改完配置文件后，我们需要重启redis才能生效配置文件。

注:

主从连接状况:

我们再重新启动服务后，如何确定主从结构已经确立呢？这时候需要查看网络连接状况:

其中redis从节点和主节点之间会建立一个tcp连接，主节点此时就相当于服务器，从节点就相当于客户端。而所谓的数据同步，当主节点产生了任何数据更改，从节点就可以根据这个tcp连接获取到更改的信息。

主从节点通过TCP网络来进行数据同步、数据传输，TCP内部支持Nagle算法(默认开启)。

开启: 增加TCP传输延迟，节省网络带宽。

关闭: 降低TCP传输延迟，增加网络带宽。

我们可以通过关闭这个选项，从节点能够更快速地与主节点同步。

主从节点信息

我们如何区分主从节点呢？redis提供 “info" 命令可以让程序员观察节点信息:

其中的有些重要信息，我们会在之后细讲。

断开主从连接

slaveof no one (直接在redis命令中敲就行了)。一旦一个节点断开与主节点的从属关系，那么这个从节点就不再属于主节点了，但其中已有的数据是会被保留的。后续，主节点的任何操作也不会同步到该从节点上了。

主从模式拓扑

① ⼀主⼀从结构

⼀主⼀从结构是最简单的复制拓扑结构。

② ⼀主多从结构

⼀主多从结构使得应⽤端可以利⽤多个从节点实现读写分离。对于读⽐重较⼤的场景，可以把读命令负载均衡到不同的从节点上来分担压⼒。

③ 树形主从结构

树形主从结构使得从节点不但可以复制主节点数据，同时可以作为其他从节点的主节点继续向下层复制。

主从复制原理

建立复制流程

数据同步psync

Redis使⽤psync命令完成主从数据同步，同步的方式有两种: 全量复制和部分复制。

○ 全量复制：⼀般⽤于初次复制场景，Redis早期⽀持的复制功能只有全量复制，它会把主节点全部数据⼀次性发送给从节点，当数据量较⼤时，会对主从节点和⽹络造成很⼤的开销。

○ 部分复制：⽤于处理在主从复制中因⽹络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果条件允许，主节点会补发数据给从节点。因为补发的数据远⼩于全量数据，可以有效避免全量复制的过⾼开销。

# PSYNC的语法格式
PSYNC replicationid offset

要实现数据同步，我们得知道要从谁身上同步吧，又因为数据同步分为全量复制和部分复制，我总得知道从哪里开始复制起走吧。

replication id

这是由主节点自动生成的，当从节点与主节点建立复制关系时，就会从主节点那边获取到这个replication id。

我是找到了复制谁的数据，那我现在应该从哪里开始复制起走呢？

offset

参与复制的主从节点都会维护⾃⾝复制偏移量，主节点在处理完写⼊命令后，会把命令的字节⻓度做累加记录，统计信息在inforeplication中的master_repl_offset指标中。从节点在接受到主节点发送的命令后，也会累加记录⾃⾝的偏移量。统计信息在inforeplication中的
slave_repl_offset指标中。

我们可以根据从节点的偏移量，获取到从节点同步进度。

因此，replication id 和offset 共同描述了一组数据集合。如果这两台机器上的replication id、offset都是一样的，那么就可以认为这两台机器上存储的数据也是一样的。

replication id2

一般情况下，replication id2是用不上的。一个主节点A自动生成replication id，它的从节点B也会在建立连接时，获取到这个主节点A的replication id。

如果A和B通信中发生了网络抖动，此时从节点B认为主节点A已经挂了，B就会自动生成一个replication id，但B仍然会记得之前的主节点A的replication id，并把它保存在replication id2中。

就像这样：

psync运⾏流程

1) 从节点发送psync命令给主节点：offset写作-1 表示全量复制，写作具体正整数就是按偏移量复制。

2) 主节点根据psync参数和⾃⾝数据情况决定响应结果：

○ “+FULLRESYNC”，则从节点需要进⾏全量复制流程。

○ “+CONTINEU”，从节点进⾏部分复制流程。

○ "-ERR"，不支持"psync"，从节点可以使⽤sync命令进⾏全量复制。（sync会塞redisserver处理其他请求.psync则不会）

全量复制 vs 部分复制

啥时候选择进行全量复制\部分复制？

全量复制:

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

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

部分复制:

① 从节点同步过主节点的数据，因为别的原因从节点重启了。

② 从节点需要重新同步主节点数据，看看能不能只同步一小部分。

全量复制流程:

在主节点将RDB文件生成到接收的期间，这时候可能存在其他客户端发来的命令，这些命令会被写入到缓冲区中，并且也会以RDB文件重新发送给从节点，保持主从节点的一致性。

有磁盘复制vs⽆磁盘复制(diskless)

也许你会认为，生成RDB文件压根不需要这步操作。因为主节点生成的RDB二进制数据，完完全全可以直接发送，而不是先要保存持久化到磁盘上！

同样，从节点在写入时，也不用把收到的RDB数据写入到磁盘中，再进行加载。这样便省略了磁盘IO的过程。

但，即便是引入了无磁盘模式，操作全量数据仍然是十分耗时的，因为网络传输是没发省的！相比于网络传输，磁盘IO还是很快的。