Redis主从复制知识点

参考书为 <<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断开与主节点的复制关系， 再重启主节点从而避免这一问题。

一主多从：

又叫星形拓扑结构

树状拓扑：

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

开发与运维中的问题

读写分离方面的问题

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等分布式解决方案， 这样不止扩展了读性能还可以扩展写性能和可支撑数据规模， 并且一致性和故障转移也可以得到保证， 对于客户端的维护逻辑也相对容易。