一、简介¶
主机数据更新后根据配置和策略, 自动同步到备机的master/slave机制
Master以写为主,Slave以读为主
Redis的复制拓扑结构类型
1)一主一从
2)一主多从
3)树状主从结构
目的:
- 容灾恢复
- 数据冗余
- 负载均衡
- 高可用

配置复制的方式有以下三种:
1)在配置文件中加入slaveof{masterHost}{masterPort}随Redis启动生效。
2)在redis-server启动命令后加入--slaveof{masterHost}{masterPort}生效。
3)直接使用命令:slaveof{masterHost}{masterPort}生效。
二、搭建主从集群¶
主:192.168.9.78:6410
从:192.168.9.78:6411
redis部署安装
(1)目录初始化
mkdir -p /data/redis/{6410,6411}
cp -r /usr/local/redis/bin/ /data/redis/6410/
cp -r /usr/local/redis/bin/ /data/redis/6411/
(2)生成配置文件
6410主节点
cat > /data/redis/6410/redis_6410.conf <<EOF
daemonize yes
timeout 0
databases 16
dir "/data/redis/6410"
slowlog-log-slower-than 10000
slowlog-max-len 128
hz 10
port 6410
maxmemory 100mb
appendonly yes
appendfsync everysec
appendfilename "appendonly-6410.aof"
dbfilename "dump-6410.rdb"
logfile "/data/redis/6410/redis_6410.log"
pidfile /data/redis/6410/redis_6410.pid
protected-mode no
requirepass ""
masterauth ""
EOF
6411从节点
cat > /data/redis/6411/redis_6411.conf <<EOF
daemonize yes
timeout 0
databases 16
dir "/data/redis/6411"
slowlog-log-slower-than 10000
slowlog-max-len 128
hz 10
port 6411
maxmemory 100mb
appendonly yes
appendfsync everysec
appendfilename "appendonly-6411.aof"
dbfilename "dump-6411.rdb"
file "/data/redis/6411/redis_6411.log"
pidfile /data/redis/6411/redis_6411.pid
protected-mode no
requirepass ""
masterauth ""
EOF
启动
/data/redis/6410/bin/redis-server /data/redis/6410/redis_6410.conf
/data/redis/6411/bin/redis-server /data/redis/6411/redis_6411.conf
配置主从复制
从节点的配置文件增加一行:slaveof 192.168.9.78 6410 ,然后重启即可生效,变为slave
从节点在线使用命令挂载
127.0.0.1:6411> slaveof 127.0.0.1 6410 OK
查看主从复制的状态
127.0.0.1:6411> info Replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6410
master_link_status:up
验证
主节点 #redis-cli -p 6410 set hello oldboy
OK
从节点 #redis-cli -p 6411 get hello"oldboy"
从节点设置断开主从复制
127.0.0.1:6411> slaveof no one OK
127.0.0.1:6411> info Replication
role:master
从库切换主库
slaveofnewmasterIPPort
断开旧主节点复制关系
-
与新主节点建立复制关系
-
删除从节点当前所有数据
-
对新主数据复制
三、主从复制原理¶
3.1 复制的过程¶
主从复制过程大体可以分为3个阶段:
-
连接建立阶段(即准备阶段)
-
数据同步阶段
-
命令传播阶段
主从复制过程大体可以分为6个过程:
- 从节点保存主节点(master)信息。
建立Socket连接
发送PING命令
权限验证
-
全量数据同步
-
命令持续复制

3.2 数据同步¶
同步过程分为:
-
全量复制
-
增量复制
psync命令运行需要以下组件支持:
主从节点各自复制偏移量
- 主节点复制积压缓冲区
主节点运行id
127.0.0.1:6410> info server
run_id:aa7828c0cbdf62432ad3b4174bdaaa6dd2c9ba4c

复制偏移量维护

复制积压缓冲区示意图
3.2.1 全量数据同步¶
全量数据同步: 先执行一次全同步, 请求master BgSave出自己的一个RDB Snapshot文件发给slave,slave接收完毕后,清除掉自己的旧数据,然后将RDB载入内存。

全量复制流程
1.发送psync数据同步, psync -1 第一次
2.主节点解析全量复制 ,恢复
3.保存主节点ID和偏移量offset
4.主节点bgsave-->RDB— —>本地-->从节点
数据量级较大rdb超过60s传输,调大repl-timeout
5.从节点清空数据-->接受RDB快照-->网络传输-->主节点积压增量命令数据-->接受RDB完毕——>接受增量积压命令数据
- 参数 client-output-buffer-limit slave 256MB 64MB 60: 60s持续大于64MBG或者超过256MB,同步失败,需要调整参数(高并发场景)
6.加载RDB文件
7.加载成功,且开启AOF则做bgrewriteaof操作
总结:全量复制开销
主bgsave
-
rdb网络传输
-
从节点flushdata
-
从 load RDB
-
AOF重写

增量数据同步:master作为一个普通的client连入slave,将所有写操作转发给slave,没有特殊的同步协议

3.2.2 增量数据同步¶
增量复制流程
psync runid offset
场景:网络断连,命令丢失,从补充数据,主的缓冲区有命令直接发送给从流程
1.主从网络断连,repl-timeout
2.主节点缓冲命令,默认缓存1MB
3.从节点网络恢复,在此连接主节点
4.主从恢复,从节点根据 offset和主的ID psync部分复制
5.主节点校验,如果有offset除命令少数据,发送给从
6.从节点恢复数据

四、主从复制相关参数¶
slaveof <masterip> <masterport> #添加从节点
slave-serve-stale-data yes #同步数据期间,是否可使用陈旧数据向客户端提供服务
slave-read-only yes
repl-diskless-sync no #无盘复制适用于主节点所在机器磁盘性能较差但网络带宽较充裕的场景*/
repl-diskless-sync-delay 5 #两次diskless模式的数据同步操作的时间间隔
repl-ping-slave-period 10 #Slave节点向Master节点发送ping指令的事件间隔,10s
repl-timeout 60 #Master和Slave之间的超时时间
repl DISABLE-tcp-nodelay no #主从复制时使用的网络资源优化参数
默认关闭
关闭:所有命令数据发送从节点,延迟变少,但是网络带宽消耗增加。适合同机房
开启:合并较小tcp数据包,默认40ms,节省带宽增大主从延时,适合跨机房部署
repl-backlog-size 1MB #主节点复制积压缓冲区大小
slave-priority #当前Slave节点的优先级权重
min-slaves-to-write和min-slaves-max-lag #拒绝数据写操作的策略
五、主从复制避坑实践¶
读写分离
缺点:写并发较高,多个从节点到主主节点写命令多次过度消耗网络带宽
优点:高并发读写分离
问题:
-
复制数据延迟:监控报警
-
过期数据read:惰性删除和定期删除
-
惰性删除:如果读取命令数据发现data过期,del命令删除数据
-
定期删除:循环采取一定key采样发现key过期 del
-
从节点故障
规避全量复制
低峰期建立第一次复制
使用故障转移功能,避免节点运行ID不匹配
设置合理的复制积压缓冲区大小
规避复制风暴
-
减少主节点(master)挂载从节点(slave)的数量
-
采用树状复制结构
-
主节点尽量分散在多台机器上,避免在单台机器上部署过多的主节点
主从配置不一致
