Redis主从复制知识点

末蓝、 2022-09-12 15:42 186阅读 0赞

> 参考书为 <<Redis开发与运维>> Redis相关的知识非常全面，非常推荐阅读

### 手动将从节点设置为主节点 ###

手动将从节点设置成主节点。命令：

# redis-cli -h <主节点ip> -p <主节点端口号> slaveof [host] [port]
    127.0.0.1:6380> slaveof 127.0.0.1 6379
    OK

配置复制的方式：

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

主从节点复制成功建立后， 可以使用info replication命令查看复制相关状态

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:5946163
    slave_priority:100
    slave_read_only:1
    connected_slaves:0
    master_repl_offset:0
    repl_backlog_active:0
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:2
    repl_backlog_histlen:5541

从节点执行slaveof no one命令断开与主节点的复制关系，

断开复制主要流程：  
1） 断开与主节点复制关系。  
2） 从节点晋升为主节点

从节点断开复制后并不会抛弃原有数据， 只是无法再获取主节点上的数据变化。

但是切主后从节点会清空之前所有的数据， 线上人工操作时小心slaveof在错误的节点上执行或者指向错误的主节点。

Redis复制的拓扑结构，分为一主一从，一主多从，树状主从结构。

一主一从：

当应用写命令并发量较高且需要持久化时， 可以只在从节点上开启AOF， 这样既保证数据安全性同时也避免了持久化对主节点的性能干扰。但需要注意的是， 当主节点关闭持久化功能时，如果主节点脱机要避免自动重启操作。 因为主节点之前没有开启持久化功能自动重启后数据集为空， 这时从节点如果继续复制主节点会导致从节点数据也被清空的情况， 丧失了持久化的意义。 安全的做法是在从节点上执行slaveof no one断开与主节点的复制关系， 再重启主节点从而避免这一问题。

一主多从：

又叫星形拓扑结构

![1632642145495-20210926154225.png][]

树状拓扑：

树状主从结构（又称为树状拓扑结构） 使得从节点不但可以复制主节点数据， 同时可以作为其他从节点的主节点继续向下层复制。 通过引入复制中间层， 可以有效降低主节点负载和需要传送给从节点的数据量。数据实现了一层一层的向下复制。 当主节点需要挂载多个从节点时为了避免对主节点的性能干扰， 可以采用树状主从结构降低主节点压力。

![1632642183844-20210926154303.png][]

### 开发与运维中的问题 ###

#### 读写分离方面的问题 ####

1）复制数据延迟

Redis复制数据的延迟由于异步复制特性是无法避免的， 延迟取决于网络带宽和命令阻塞情况， 比如刚在主节点写入数据后立刻在从节点上读取可能获取不到。 需要业务场景允许短时间内的数据延迟。 对于无法容忍大量延  
迟场景， 可以编写外部监控程序监听主从节点的复制偏移量， 当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点，

实现逻辑说明：

1.  监控程序（monitor） 定期检查主从节点的偏移量， 主节点偏移量在info replication的master\_repl\_offset指标记录， 从节点偏移量可以查询主节点的slave0字段的offset指标， 它们的差值就是主从节点延迟的字节量。
2.  当延迟字节量过高时， 比如超过10MB。 监控程序触发报警并通知客户端从节点延迟过高。 可以采用Zookeeper的监听回调机制实现客户端通知。
3.  客户端接到具体的从节点高延迟通知后， 修改读命令路由到其他从节点或主节点上。 当延迟恢复后， 再次通知客户端， 恢复从节点的读命令请求。

这种方案的成本比较高， 需要单独修改适配Redis的客户端类库。 如果涉及多种语言成本将会扩大。 客户端逻辑需要识别出读写请求并自动路由，还需要维护故障和恢复的通知。 采用此方案视具体的业务而定， 如果允许不一致性或对延迟不敏感的业务可以忽略， 也可以采用Redis集群方案做水平扩展。

2）读到过期数据

当主节点存储大量设置超时的数据时。

Redis在3.2版本解决了这个问题， 从节点读取数据之前会检查键的过期时间来决定是否返回数据， 可以升级到3.2版本来规避这个问题。

3）从节点故障

对于从节点的故障问题， 需要在客户端维护可用从节点列表， 当从节点故障时立刻切换到其他从节点或主节点上。 这个过程类似上文提到的针对延迟过高的监控处理， 需要开发人员改造客户端类库。

总结：使用Redis做读写分离存在一定的成本。 Redis本身的性能非常高， 开发人员在使用额外的从节点提升读性能之前， 尽量在主节点上做充分优化， 比如解决慢查询， 持久化阻塞， 合理应用数据结构等， 当主节点优  
化空间不大时再考虑扩展。 笔者建议大家**在做读写分离之前， 可以考虑使用Redis Cluster等分布式解决方案， 这样不止扩展了读性能还可以扩展写性能和可支撑数据规模， 并且一致性和故障转移也可以得到保证， 对于客户端的维护逻辑也相对容易**。

[1632642145495-20210926154225.png]: /images/20220828/1d66b20c8b7b4cd19375bec13addcc68.png
[1632642183844-20210926154303.png]: /images/20220828/61536967aed64fb6a26fcec20ab74a6f.png