【redis】主从复制：单点问题、配置详解、特点详解

单点问题

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

某个服务器程序，只有一个节点（只搞一个物理服务器，来部署这个服务器程序）。这就可能会遇到一些问题：

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

引入分布式系统，主要也就是为了解决上述的单点问题

什么是主从复制

在分布式系统中，往往希望有多个服务器来部署 redis 服务器，从而构成一个 redis 集群。此时就可以让这个集群给整个分布式系统重其他的服务，提供更稳定/更高效的数据存储功能

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

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

主从模式：

在若干个 redis 节点中，有的是“主节点”，有的是“从节点”。假设有三个物理服务器（称为三个节点），分别部署了一个 redis-server 进程

此时就可以把其中的一个节点，作为“主节点”，另外两个节点作为“从节点”。

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

redis 主从模式中，从节点上的数据不允许被修改，只能读取数据

主从模式能解决的问题

并发量有限

image.png|529

• 由于从节点的数据都是时刻和主节点保持一致的，所以其他的客户端从从节点读取数据，和从主节点这里读取数据，是没有区别的
• 后续如果有客户端来读取数据了，就可以从上述节点中，随机挑一个节点，给这个客户端提供读取数据的服务
  • 引入了更多的计算资源，自然能够支撑的并发量也就大幅提高了

可用性问题

之前只是单个 redis 服务器节点，此时这个机器挂了，整个 redis 就挂了

• 上述这个主从结构，这些 redis 的机器不太可能“同时挂了”

但是整个机房，是否可能被一锅端了？（也是可能存在的）

• 这个时候如果考虑到更高的可用性，就可以把这些机器放到多个不同的机房中（异地多活）
• 如果是挂掉了某个从节点，没什么影响。此时继续从主节点或者其他从节点读取数据，得到的效果完全相同
• 如果挂掉了主节点，还是有一定影响的。从节点只能读取数据，如果需要写数据，就没得写了 可用性是提高了，但还是没有到非常理想的程度

我们可以弄多个主节点吗？

• 一山容不得二虎
• 如果存在两个主节点，相互之间如何同步数据，是个麻烦事

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

主从结构，是分布式系统中比较经典的一种结构。不仅仅 redis 支持，MySQL 也支持

配置

建立复制

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

没有多个服务器，我们可以在一个服务器上，运行多个 redis-server 进程

• 我们要保证 redis-server 的端口是不同的
• 默认端口为：6379，此时就不能让新启动的 redis-server 再继续使用 6379 了

如何去指定 redis-server 的端口呢？

1. 可以在启动程序的时候，通过命令行来指定端口号。-port 选项
2. 也可以直接在配置文件中，来设定端口

通过配置文件来指定端口

此处我们准备搞一个主节点，两个从节点

image.png|234

• slave1 是从节点 1，配置文件设置的 6380
• slave2 是从节点 2，配置文件设置的 6381
• redis 是主节点，端口为 6379 从节点的配置文件都是复制的主节点的，只是把端口号改了。还需要把守护模式设为 yes（daemonize yes）

image.png|454

• 此时就可以看到启动了三个服务器（一主两从）
• 但此时这几个节点还未构成主从结构，而是各自为政。要想成为主从结构，还需要进一步的进行配置

配置主从

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

1. 在配置文件中加入 slaveof {masterHost} {masterPort} 随 Redis 启动生效
2. 在 redis-server 启动命令时加入 --slaveof {masterHost} {masterPort} 生效
3. 直接使用 Redis 命令：slaveof {masterHost} {masterPort} 生效 一般是使用配置文件更多，修改配置文件是一直持久生效的，重启后也能用

直接加上相关信息：

image.png

• Redis 服务器的配置文件改完之后，要重启服务器

主从结构配置好之后，我们看一下网络状态

image.png

image.png

• 主节点随时修改，从节点能立即感知到
• 但是从节点不能改，只能读

查看集群结构

使用：

info replication

image.png

• offset
  • 主节点上会收到源源不断的“修改数据”请求，从节点就需要从主节点这里同步这些修改请求
  • 从节点和主节点之间的数据同步，不是瞬间完成的
  • offset 就相当于是从节点和主节点之间，同步数据的进度
• lag
  • 表示延迟，单位为复制日志的条目数。
• connected slaves
  • 从节点下面还可以接从节点

断开复制

直接使用 slaveof no one 这个命令，来断开现有的主从复制关系

image.png|399

• 从节点断开主从关系，它就不再从属于其他节点了，里面已经有的数据，是不会抛弃的
• 但后续主节点再针对数据进行修改，从节点就无法再自动同步数据了

但是重启服务器之后，还是会回到之前一主两从的结构，因为配置文件里面是这样设置的

特点

安全性

对于数据比较重要的节点，主节点会通过设置 requirepass 参数进⾏密码验证，这时所有的客⼾端访问必须使⽤ auth 命令实⾏校验。

从节点与主节点的复制连接是通过⼀个特殊标识的客⼾端来完成，因此需要配置从节点的 masterauth 参数与主节点密码保持⼀致，这样从节点才可以正确地连接到主节点并发起复制流程。

只读

默认情况下，从节点使⽤ slave-read-only=yes 配置为只读模式。

由于复制只能从主节点到从节点，对于从节点的任何修改主节点都⽆法感知，修改从节点会造成主从数据不⼀致。所以建议线上不要修改从节点的只读模式。

传输延迟

主节点和从节点之间通过网络（TCP）来传输。TCP 内部支持了 nagle 算法（默认开启）

• 开启了，就会增加 TCP 的传输延迟，节省了网络带宽
• 关闭了，就会减少 TCP 的传输延迟，增加了网络带宽
• 目的和 TCP 的捎带应答是一样的，针对小的 TCP 数据报，进行合并，从而减少包的个数（等待合并的时候就会耗时）

repl-disable-tcp-nodelay 参数就可以用于在主从通信过程中，关闭 TCP 的 nagle 算法，从而减少传输延迟，不过会增加网络带宽

• 从节点更快的和主节点进行同步
• 一般游戏开发，有其是及时性要求很高的（fps、moba…）都要关闭 nagle 算法