发布日期:
2024-09-10
文章字数:
798
阅读时长:
2 分
阅读次数:
主从架构
- 从节点配置文件
- replicaof 192.168.0.60 6379 从主节点IP-Port复制数据
- replica‐read‐only yes 从节点只读
- 全量复制：bgsave，如果master收到了多个slave并发连接请求，它只会进行一次持久化
- 部分复制（断点续传，从节点断线重连）：offset
- info命令查看主从节点信息
- 主从复制风暴：多个从节点同时复制主节点导致主节点压力过大
哨兵
- 哨兵（sentinel）：不提供读写服务，主要用来监控redis实例节点
- 配置文件
- sentinel monitor mymaster 192.168.0.60 6379 2
- sentinel总数/2 + 1 ，指明当有多少个sentinel认为一个master失效时，master才算真正失效，这里是：3/2 + 1 = 2
- mymaster这个名字随便取，客户端访问时会用到
- sentinel集群都启动完毕后，会将哨兵集群的元数据信息写入所有sentinel的配置文件里去（追加在文件的最下面）
- 当redis主节点如果挂了，哨兵集群会重新选举出新的redis主节点，同时会修改所有sentinel节点配置文件的集群元数据信息，同时还会修改sentinel配置文件中的 mymaster
- 当挂了的redis实例再次启动时，哨兵集群就会根据集群元数据信息将它作为从节点加入集群
- Leader选举
- 当一个master服务器被某sentinel视为下线状态后，该sentinel会与其他sentinel协商选出sentinel的leader进行故障转移工作
- 每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的leader，选举是先到先得
- 同时每个sentinel每次选举都会自增配置纪元（选举周期），每个纪元中只会选择一个sentinel的leader
- 如果所有超过一半的sentinel选举某sentinel作为leader。之后该sentinel进行故障转移操作，从存活的slave中选举出新的master，这个选举过程跟集群的master选举很类似（超过半数选举）
- 哨兵集群即使只有一个哨兵节点，redis的主从也能正常运行以及选举master，如果master挂了，那唯一的那个哨兵节点就是哨兵leader了，可以正常选举新master。不过为了高可用一般都推荐至少部署三个哨兵节点（奇数）
- 为什么推荐奇数个哨兵节点原理跟集群奇数个master节点类似
- 缺点
- 主从切换时会发生访问瞬断
- 无法水平扩容
- 只有一个提供服务的主节点
- 主节点内存不易过大，否则持久化会消耗大量性能
- client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis主节点通知给client端（这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息）
