建立复制
参与复制的Redis实例划分为主节点（master） 和从节点（slave） 。 默认情况下， Redis都是主节点。 每个从节点只能有一个主节点， 而主节点可以同时具有多个从节点。 复制的数据流是单向的， 只能由主节点复制到从节点。 配置复制的方式有以下三种：
127.0.0.1:6379> info replication --默认情况下每个节点都是master节点
# Replication
role:master
connected_slaves:0
master_replid:b4c7335839af0228e8f3318baf68c7a38c29c5f1
master_replid2:93e727752d0ea5557a89dfb2bf6d78dfe6c437c2
master_repl_offset:1050
second_repl_offset:1051
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:407
repl_backlog_histlen:644
1） 在配置文件中加入slaveof {masterHost} {masterPort}随Redis启动生效。
2） 在redis-server启动命令后加入--slaveof {masterHost} {masterPort}生效。
3） 直接使用命令： slaveof {masterHost} {masterPort}生效。
综上所述， slaveof命令在使用时， 可以运行期动态配置， 也可以提前写到配置文件中。 例如本地启动两个端口为6379和6380的Redis节点， 在127.0.0.1： 6380执行如下命令：
127.0.0.1:6380>slaveof 127.0.0.1 6379
slaveof配置都是在从节点发起， 这时6379作为主节点， 6380作为从节点。 复制关系建立后执行如下命令测试：
127.0.0.1:6379>set hello redis
OK
127.0.0.1:6379>get hello
"redis"
127.0.0.1:6380>get hello
"redis"
从运行结果中看到复制已经工作了， 针对主节点6379的任何修改都可以同步到从节点6380中， 复制过程如图所示。
1） 主节点6379复制状态信息：
[root@localhost 6379]# export PATH=$PATH:/usr/local/redis/bin/
[root@localhost 6379]# redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=1260,lag=1
....
2） 从节点6380复制状态信息：
[root@localhost ~]# export PATH=$PATH:/usr/local/redis/bin/
[root@localhost ~]# redis-cli -h 127.0.0.1 -p 6380
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:7
master_sync_in_progress:0
...
断开复制
slaveof命令不但可以建立复制， 还可以在从节点执行slaveof no one来断开与主节点复制关系。 例如在6380节点上执行slaveof no one来断开复制， 如图所示。
断开复制主要流程：
1） 断开与主节点复制关系。
2） 从节点晋升为主节点。
从节点断开复制后并不会抛弃原有数据， 只是无法再获取主节点上的数据变化。
通过slaveof命令还可以实现切主操作， 所谓切主是指把当前从节点对主节点的复制切换到另一个主节点。 执行slaveof {newMasterIp} {newMasterPort} 命令即可， 例如把6380节点从原来的复制6379节点变为复制6381节点， 如图所示。
从节点通过slave of切换新的主节点，切主操作流程如下：
1） 断开与旧主节点复制关系。
2） 与新主节点建立复制关系。
3） 删除从节点当前所有数据。
4） 对新主节点进行复制操作。
从节点slaveof no one之后再重新的主节点建立复制关系，从节点日志如下：
21609:S 08 May 2020 08:37:59.236 * Full resync from master: dbddc80fe41195ca35706a8a7bb396cde1bf1753:2548
21609:S 08 May 2020 08:37:59.237 * Discarding previously cached master state.
21609:S 08 May 2020 08:37:59.290 * MASTER <-> REPLICA sync: receiving 204 bytes from master
21609:S 08 May 2020 08:37:59.290 * MASTER <-> REPLICA sync: Flushing old data -- 删除从节点当前所有数据
运维提示：切主后从节点会清空之前所有的数据， 线上人工操作时小心slaveof在错误的节点上执行或者指向错误的主节点。
只读
默认情况下， 从节点使用slave-read-only=yes配置为只读模式。 由于复制只能从主节点到从节点， 对于从节点的任何修改主节点都无法感知， 修改从节点会造成主从数据不一致。 因此建议线上不要修改从节点的只读模式。如果你尝试着修改从节点数据，会出现下面提示：
127.0.0.1:6379> set key hellow
(error) READONLY You can't write against a read only replica.
传输延迟
主从节点一般部署在不同机器上， 复制时的网络延迟就成为需要考虑的问题， Redis为我们提供了repl-disable-tcp-nodelay参数用于控制是否关闭TCP_NODELAY， 默认关闭， 说明如下：
·当关闭时， 主节点产生的命令数据无论大小都会及时地发送给从节点， 这样主从之间延迟会变小， 但增加了网络带宽的消耗。 适用于主从之间的网络环境良好的场景， 如同机架或同机房部署。
·当开启时， 主节点会合并较小的TCP数据包从而节省带宽。 默认发送时间间隔取决于Linux的内核， 一般默认为40毫秒。 这种配置节省了带宽但增大主从之间的延迟。 适用于主从网络环境复杂或带宽紧张的场景， 如跨机房部署
运维提示：
部署主从节点时需要考虑网络延迟、 带宽使用率、 防灾级别等因素， 如要求低延迟时， 建议同机架或同机房部署并关闭repl-disable-tcp-nodelay。如果考虑高容灾性， 可以同城跨机房部署并开启repl-disable-tcp-nodelay。
主从拓扑结构
Redis的复制拓扑结构可以支持单层或多层复制关系， 根据拓扑复杂性可以分为以下三种： 一主一从、 一主多从、 树状主从结构， 下面分别介绍。
1.一主一从结构：
一主一从结构是最简单的复制拓扑结构， 用于主节点出现宕机时从节点提供故障转移支持（如图所示） 。 当应用写命令并发量较高且需要持久化时， 可以只在从节点上开启AOF， 这样既保证数据安全性同时也避免了持久化对主节点的性能干扰。 但需要注意的是， 当主节点关闭持久化功能时，如果主节点脱机要避免自动重启操作。 因为主节点之前没有开启持久化功能自动重启后数据集为空， 这时从节点如果继续复制主节点会导致从节点数据也被清空的情况， 丧失了持久化的意义。 安全的做法是在从节点上执行slaveof no one断开与主节点的复制关系， 再重启主节点从而避免这一问题。
2.一主多从结构：
一主多从结构（又称为星形拓扑结构） 使得应用端可以利用多个从节点实现读写分离（见图） 。 对于读占比较大的场景， 可以把读命令发送到从节点来分担主节点压力。 同时在日常开发中如果需要执行一些比较耗时的读命令， 如： keys、 sort等， 可以在其中一台从节点上执行， 防止慢查询对主节点造成阻塞从而影响线上服务的稳定性。 对于写并发量较高的场景， 多个从节点会导致主节点写命令的多次发送从而过度消耗网络带宽， 同时也加重了主节点的负载影响服务稳定性。
3.树状主从结构：
树状主从结构（又称为树状拓扑结构） 使得从节点不但可以复制主节点数据， 同时可以作为其他从节点的主节点继续向下层复制。 通过引入复制中间层， 可以有效降低主节点负载和需要传送给从节点的数据量。 如图所示， 数据写入节点A后会同步到B和C节点， B节点再把数据同步到D和E节点， 数据实现了一层一层的向下复制。 当主节点需要挂载多个从节点时为了避免对主节点的性能干扰， 可以采用树状主从结构降低主节点压力。
