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