[Redis][主从复制][上]详细讲解

0.前言

说明：该章节相关操作不需要记忆，理解流程和原理即可，用的时候能自主查到即可
主从复制？
- 分布式系统中为了解决单点问题，通常会把数据复制多个副本部署到其他服务器，满⾜故障恢复和负载均衡等需求
- Redis也是如此，它提供了复制的功能，实现了相同数据的多个Redis副本
- 复制功能是⾼可⽤Redis的基础，哨兵和集群都是在复制的基础上构建的
从节点上的数据要跟随主节点变化，从节点的数据要和主节点保持一致
- 主从模式，主要是针对"读操作"，进行并发量和可用性的提高
- 写操作，无论是可用性还是并发量，都非常依赖主节点，主节点不能搞多个

1.配置

1.建立复制

参与复制的Redis实例划分为主节点(master)和从节点(slave)
- 每个从结点只能有⼀个主节点，⽽⼀个主节点可以同时具有多个从结点
- 复制的数据流是单向的，只能由主节点到从节点。
配置复制的⽅式有以下三种 ：
- 在配置文件中加入slaveof {masterHost} {masterPort}随Redis启动⽣效
- 在redis-server启动命令时加⼊--slaveof {masterHost} {masterPort}⽣效
- 直接使⽤Redis命令：slaveof {masterHost} {masterPort}⽣效

示例：

将redis.conf配置⽂件复制⼀份redis-slave.conf，并且修改其daemonize为yes

bash 复制代码

# By default Redis does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
daemonize yes

接下来，默认启动的Redis作为主Redis，重新通过命令行启动一个Redis实例作为从Redis
- 注意：修改配置主要是**修改从机的配置，主机配置不变**
  bash 复制代码
```
# ubuntu
redis-server /etc/redis/redis-slave.conf --port 6380 --slaveof 127.0.0.1 6379
```
通过netstat -nlpt确保两个Redis均已正确启动
通过redis-cli可以连接主Redis实例，通过redis-cli -p 6380连接从Redis，并且观察复制关系
bash 复制代码
```
127.0.0.1:6379> set hello world
OK
127.0.0.1:6379> get hello
"world"

127.0.0.1:6380> get hello 
"world"
```

可以通过info replication命令查看复制相关状态

主节点6379复制状态信息

offset：从节点和主节点之间，同步数据的进度

bash 复制代码

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=100,lag=0
master_replid:2fbd35a8b8401b22eb92ff49ad5e42250b3e7a06
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:100
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:100

从节点6380复制状态信息

bash 复制代码

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:170
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:2fbd35a8b8401b22eb92ff49ad5e42250b3e7a06
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:170
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:170

Redis主从节点复制过程

2.断开复制

slaveof命令不但可以建⽴复制，还可以在从节点执⾏slaveof no one来**断开**与主节点复制关系
- 例如：在6380节点上执⾏slaveof no one来断开复制
断开复制主要流程 ：
- 断开与主节点复制关系
- 从节点晋升为主节点
从节点断开复制后并不会抛弃原有数据，只是无法再获取主节点上的数据变化
通过slaveof命令还可以实现切主操作，将当前从节点的数据源切换到另⼀个主节点，执⾏slaveof {newMasterIp} {newMasterPort}命令即可
- 该方法的修改是临时性的，如果重启了Redis服务器，仍然会按照最初在配置文件中设置的内容来建立主从关系
切主操作主要流程 ：
- 断开与旧主节点复制关系
- 与新节点建立复制关系
- 删除从节点当前所有数据
- 从新主节点进行复制操作

3.安全性

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

4.只读

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

5.传输延迟

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

2.拓扑

1.一主一从结构

⼀主⼀从结构是最简单的复制拓扑结构，⽤于主节点出现宕机时从节点提供故障转移⽀持
当应⽤写命令并发量较⾼且需要持久化时，可以只在从节点上开启AOF，这样既可以保证数据安全性同时也避免了持久化对主节点的性能⼲扰
- 缺点：主节点一旦挂了，不能让它自动重启
  - 如果自动重启，此时主节点没有AOF文件，就会丢失数据
  - 进一步的主从同步，会把从节点的数据也删了
  - 改进方法：主节点挂了之后，让主节点从从节点这里获取到AOF文件，再启动

2.一主多从结构

⼀主多从结构(星形结构)使得应⽤端可以利⽤多个从节点实现读写分离
- 对于读⽐重较⼤的场景，可以把读命令负载均衡到不同的从节点上来分担压⼒
- 对于**⼀些耗时的读命令可以指定⼀台专⻔的从节点执⾏**，避免破坏整体的稳定性
缺点：对于写并发量较⾼的场景，多个从节点会导致主节点写命令的多次发送从⽽加重主节点的负载

2.树形主从结构

树形主从结构(分层结构)使得从节点不但可以复制主节点数据，同时可以作为其他从节点的主节点继续向下层复制
通过引⼊复制中间层，可以有效降低住系欸按负载和需要传送给从节点的数据量
适用场景 ：当主节点需要挂载等多个从节点时为了避免对主节点的性能⼲扰，可以采⽤这种拓扑结构
缺点：一旦数据进行修改，同步的延时是比上面两种结构更长的

[Redis][主从复制][上]详细讲解

目录

0.前言

1.配置

1.建立复制

2.断开复制

3.安全性

4.只读

5.传输延迟

2.拓扑

1.一主一从结构

2.一主多从结构

2.树形主从结构