Redis主从复制和哨兵机制
2021-03-01 23:26:59 0 举报AI智能生成
Redis主从复制+哨兵（Master/Slave/Sentinel）
作者其他创作
大纲/内容
喜欢收藏+点赞👍 谢谢
主从复制
一主多从读写分离
主负责写，写完同步到从节点，从负责读
可水平扩容，QPS再增加只需添加slave就ok了
主从复制产生短暂的数据延迟是允许的，保证最终一致性
心跳机制
主从节点彼此都有心跳检机制，各自模拟对方的客户端进行通信，主节点的连接状态为 flags=M，从节点连接状态为 flags=S
主节点默认每隔 10 秒对从节点发送 ping 命令，判断从节点的存活性和连接状态。可通过 repl-ping-replica-period 10 控制发送频率
从节点在主线程中每隔一秒发送 offset 命令，给主节点上报自身当前的复制偏移量。主节点根据 replconfa 命令判断从节点超时时间
数据同步
前提
master 和 slave 都会维护一个 offset 和 run id，slave 每秒都会上报自己的 offect 给 master
master记录在backlog中，这样才能知道双方数据是否一致
slave发送 run id 和 offset 到 master，master 根据自身情况返回相应信息(增量/全量)复制
全量复制
触发时机
slave 结点第一次启动时
master 重启或者加载了之前的备份文件（run id 会变）
复制过程
1、slave 启动时会向 master 发送 SYNC 指令（请求同步）
2、master 收到后通过 bgsave 保存快照，同时缓存后续的写命令
3、slave 收到文件后先写入本地磁盘，然后再从本地磁盘加载到内存中
4、最后 master 会将内存中缓存的写命令同步给 slave，slave 收到后再执行一遍
耗时原因
主节点 bgsave 时间
RDB 文件网络传输时间
从节点清空数据时间
可能伴随的 AOF 重写时间
增量复制
master 根据 slave 发送的同步请求中的 offset
在 backlog 中查找到部分丢失的数据，发送给 slave
过期key处理
slave不会过期key，只会等待master过期通知
存在问题
数据一致性（同步延迟）
不具备自动容错和恢复
主从+哨兵
概念
哨兵是一个分布式系统，监控主从架构中的节点通过 自动故障转移 保证集群的高可用
哨兵也是一台redis服务器，只是不提供任何服务，推荐配置为单数
避免相同票
主要功能
监控
监控主节点和从节点是否正常运行
通知
检测到服务出现问题会通知其他哨兵
自动故障转移
当确认主节点宕机后，在从节点中选一个作为主节点，将其他从节点连接到新的主节点上，通知客户端最新的地址
工作原理
1、发现master节点宕机
一台哨兵发现master宕机了，标记为sdown（主观下线），并通知其他哨兵
其他哨兵去查看，如果超过quorum数量的哨兵认为挂了就标记为odwon（客观下线）
2、选出一个哨兵去处理
每个哨兵作为参选者和投票者，向哨兵内网发送指令
指令中携带自己的竞选次数和runid，先收到谁的指令就投票给谁
3、哨兵从服务器列表中挑选master
先过滤掉不在线和响应慢的服务器
然后过滤掉与原master断开时间最久的
最后再比较优先级priority、偏移量offset、runid
4、新master诞生
哨兵向选举出的新master发送指令，断开与旧master的连接
把新master的ip地址同步到其他slave节点
0 条评论
回复 删除
下一页
