docker学习笔记之入门,Redis哨兵机制理论

编程

主从复制的问题

    Redis 复制有一个缺点,当主机 Master 宕机以后,我们需要人工解决切换,比如使用 slaveof no one 。实际上主从复制并没有实现高可用。
    高可用侧重备份机器, 利用集群中系统的冗余,当系统中某台机器发生损坏的时候,其他后备的机器可以迅速的接替它来启动服务

    一旦主节点宕机,写服务无法使用,就需要手动去切换,重新选取主节点,手动设置主从关系。

哨兵机制的原理及实现

    Redis Sentinel 一个分布式架构,其中包含若干个  Sentinel 节点和  Redis 数据节点,每个  Sentinel 节点会对数据节点和其余  Sentinel 节点进行监控,当它发现节点不可达时,会对节点做下线标识。

    如果被标识的是主节点,它还会和其他  Sentinel 节点进行“协商”,当大多数  Sentinel 节点都认为主节点不可达时,它们会选举出一个  Sentinel 节点来完成自动故障转移的工作,同时会将这个变化实时通知给  Redis 应用方。整个过程完全是自动的,不需要人工来介入,所以这套方案很有效地解决了  Redis的高可用问题。

基本的故障转移流程:

1)、主节点出现故障,此时两个从节点与主节点失去连接,主从复制失败。

2)、每个 Sentinel 节点通过定期监控发现主节点出现了故障

    

3)、多个 Sentinel 节点对主节点的故障达成一致会选举出其中一个节点作为领导者负责故障转移。

4)、Sentinel 领导者节点执行了故障转移,整个过程基本是跟我们手动调整一致的,只不过是自动化完成的。

5)、故障转移后整个 Redis Sentinel 的结构,重新选举了新的主节点

    

并且Redis Sentinel 具有以下几个功能:

    监控:Sentinel 节点会定期检测 Redis 数据节点、其余 Sentinel 节点是否可达

    通知:Sentinel 节点会将故障转移的结果通知给应用方

    主节点故障转移: 实现从节点晋升为主节点并维护后续正确的主从关系

    配置提供者: 在 Redis Sentinel 结构中,客户端在初始化的时候连接的是 Sentinel 节点集合 ,从中获取主节点信息。

同时Redis Sentinel 包含了若个 Sentinel 节点,这样做也带来了两个好处:

    对于节点的故障判断是由多个 Sentinel 节点共同完成,这样可以有效地防止误判。

    Sentinel 节点集合是由若干个 Sentinel 节点组成的,这样即使个别 Sentinel 节点不可用,整个 Sentinel 节点集合依然是健壮的。

    但是 Sentinel 节点本身就是独立的 Redis 节点,只不过它们有一些特殊,它们不存储数据, 只支持部分命令

以上是 docker学习笔记之入门,Redis哨兵机制理论 的全部内容, 来源链接: utcz.com/z/517812.html

回到顶部