什么是主从复制
主从复制
为什么要使用主从复制
- redis-server单点故障
- 单节点QPS有限
- 持久化，从处理持久化，避免对主性能影响
使用场景
- 读写分离场景，规避redis单机瓶颈
- 故障切换，master出问题后还有slave节点可以使用
搭建主从复制
1 使用命令行
# 连接需要实现从节点的redis，执行下面的命令
slaveof [ip] [port]
2 第二种方式：redis.conf 配置文件
# 配置文件中增加
slaveof [ip] [port]
# 从服务器是否只读(默认yes)
slave-read-only yes
3 退出主从集群的方式
Slaveof no one
查看主从复制信息
127.0.0.1:6379> info replication
# Replication # 角色 主
role:master
# 当前从服务器数量1
connected_slaves:1
# 从服务器信息
slave0:ip=127.0.0.1,port=6380,state=online,offset =15,lag=1
# 计数器，主节点复制偏移量(复制的字节数)
master_repl_offset:351
# 主从同步缓存区
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:14
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
slave_repl_offset:351
# 从节点优先级
slave_priority:100
# 是否为只读节点
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576 r
epl_backlog_first_byte_offset:0
repl_backlog_histlen:0
主从复制的流程
主从复制的流程
- 从服务器通过psync命令发送服务器已有的同步进度(同步源ID、同步进度offset)
- master收到请求，同步源为当前master，则根据偏移量增量同步
- 同步源非当前master，则进入全量同步：master生成rdb，传输到slave，加载到slave内存
主从复制的核心知识
- Redis 默认使用异步复制，slave 和 master 之间异步地确认处理的数据量
- 一个 master 可以拥有多个 slave
- slave 可以接受其他 slave 的连接。 slave 可以有下级sub slave
- 主从同步过程在 master 侧是非阻塞的
- slave初次同步需要删除旧数据，加载新数据，会阻塞到来的连接请求
主从复制
主从复制的应用场景
- 主从复制可以用来支持读写
- slave服务器设定为只读，可以用在数据安全的场景下。
- 可以使用主从复制来避免 master 持久化造成的开销。master 关闭持久化，slave 配置为不定期保存或是启用 AOF。（注意：重新启动的 master 程序将从一个空数据集开始，如果一个 slave 试图与它同步，那么这个 slave 也会被清空。 ）
主从复制的注意事项
读写分离场景
- 数据复制延时导致读到过期数据或者读不到数据（网络原因、slave阻塞）
- 从节点故障（多个client如何迁移）
全量复制的情况下
- 第一次建立主从关系或者runid不匹配会导致全量复制
- 故障转移的时候也会出现全量复制
复制风暴
- master故障重启，如果slave节点较多，所有slave都要复制，对服务器的性能，网络的压力都有很大影响。
- 如果一个机器部署了多个master
写能力有限
- 主从复制还是只有一台master，提供的写服务能力有限
MAster宕机的情况下
- 如果是master无持久化，slave开启持久化来保留数据的场景，建议不要配置redis自动重启。
- 启动redis自动重启，master启动后，无备份数据，可能导致集群数据丢失的情况。
带有效期的Key
- slave不会让key过期，而是等待 master 让 key 过期
- 在Lua脚本执行期间，不执行任何 key 过期操作
监控
Monitor 命令
monitor 是一个调试命令，返回服务器处理的每个命令。对于发现程序的错误非常有用。出于安全考虑，某些特殊管理命令CONFIG 不会记录到MONITOR输出
Info 命令
INFO命令以一种易于理解和阅读的格式，返回关于Redis服务器的各种信息和统计数值。
info 命令
哨兵之间如何通信的
哨兵通信机制
什么是主管下线
单个哨兵自身认为redis实例已经不能提供服务
检测机制：哨兵向redis发送ping请求，+PONG、-LOADING、 -MASTERDOWN这三种情况视为正常，其他回复均视为无效
什么是客观下线
客观下线
一定数量值的哨兵认为master已经下线
检测机制：当哨兵主观认为master下线后，则会通过 SENTINEL is-master-down-by-addr命令 询问其他哨兵是否认为master已经下线，如果达成共识（达到quorum个数），就会认为master节点客观下线，开始故障转移流程。
slave选举方案
slave 节点状态，非 S_DOWN,O_DOWN，DISCONNECTED
判断规则：(down-after-milliseconds * 10) milliseconds_since_master_is_in_SDOWN_state
SENTINEL slaves mymaster
优先级
redis.conf中的一个配置项： slave-priority 值越小，优先级越高
数据同步情况
Replication offset processed
最小的run id
run id 比较方案： 字典顺序， ASCII码
最终主从切换状况
-
针对即将成为master的slave节点，将其撤出主从集群
自动执行：slaveof NO ONE -
针对其他slave节点，使它们成为新master的从属
自动执行：slaveof new_master_host new_master_port
哨兵如何高可用
哨兵如何高可用
哨兵内部通讯原理
1、通过redis-server来发布订阅发现对方
2、直接发送命令来发现
3、sub pub来发现
哨兵领导选举机制
- 拉票阶段：每个哨兵节点希望自己成为领导者；
- sentinel节点收到拉票命令后，如果没有收到或同意过其他sentinel节点的请求，就同意该sentinel
节点的请求（每个sentinel只持有一个同意票数）； - 如果sentinel节点发现自己的票数已经超过一半的数值，那么它将成为领导者，去执行故障转移；
- 投票结束后，如果超过failover-timeout的时间内，没进行实际的故障转移操作，则重新拉票选举。
网友评论