点突发宕机怎么办#xff1f;就坐等运维从床上爬起来#xff0c;然后手工进行从主切换#xff0c;再通知所有的程序把地址统统改一遍重新上线么#xff1f;毫无疑问…

Redis

点突发宕机怎么办就坐等运维从床上爬起来然后手工进行从主切换再通知所有的程序把地址统统改一遍重新上线么毫无疑问这样的人工运维效率太低事故发生时估计得至少

img

所以我们必须有一个高可用方案来抵抗节点故障当故障发生时可以自动进行从主切换程序可以不用重启运维可以继续睡大觉仿佛什么事也没发生一样。

Redis

Redis

它负责持续监控主从节点的健康当主节点挂掉时自动选择一个最优的从节点切换为主节点。

客户端来连接集群时会首先连接

sentinel

来查询主节点的地址然后再去连接主节点进行数据交互。

当主节点发生故障时客户端会重新向

sentinel

会将最新的主节点地址告诉客户端。

如此应用程序将无需重启即可自动完成节点切换。

比如上图的主节点挂掉后集群将可能自动调整为下图所示结构。

img

从这张图中我们能看到主节点挂掉了原先的主从复制也断开了客户端和损坏的主节点也断开了。

从节点被提升为新的主节点其它从节点开始和新的主节点建立复制关系。

客户端通过新的主节点继续进行交互。

Sentinel

img

此时原先挂掉的主节点现在变成了从节点从新的主节点那里建立复制关系。

消息丢失

主从采用异步复制意味着当主节点挂掉时从节点可能没有收到全部的同步消息这部分未同步的消息就丢失了。

如果主从延迟特别大那么丢失的数据就可能会特别多。

Sentinel

无法保证消息完全不丢失但是也尽可能保证消息少丢失。

它有两个选项可以限制主从延迟过大。

min-slaves-max-lag

10第一个参数表示主节点必须至少有一个从节点在进行正常复制否则就停止对外写服务丧失可用性。

何为正常复制何为异常复制这个就是由第二个参数控制的它的单位是秒表示如果

10s

没有收到从节点的反馈就意味着从节点同步不正常要么网络断开了要么一直没有给反馈。

Sentinel

发现主从节点的地址然后在通过这些地址建立相应的连接来进行数据存取操作。

我们来看看

Python

sentinel.discover_master(mymaster)(127.0.0.1,

6379)

sentinel.discover_slaves(mymaster)[(127.0.0.1,

6380)]

方法可以从连接池中拿出一个连接来使用因为从地址有多个redis

RoundRobin

连接池建立新连接时会去查询主库地址然后跟内存中的主库地址进行比对如果变更了就断开所有连接重新使用新地址建立新连接。

如果是旧的主库挂掉了那么所有正在使用的连接都会被关闭然后在重连时就会用上新地址。

sentinel

主动进行主从切换主库并没有挂掉而之前的主库连接已经建立了在使用了没有新连接需要建立那这个连接是不是一致切换不了

继续深入研究源码我发现

在另外一个点也做了控制。

那就是在处理命令的时候捕获了一个特殊的异常ReadOnlyError在这个异常里将所有的旧连接全部关闭了后续指令就会进行重连。

主从切换后之前的主库被降级到从库所有的修改性的指令都会抛出ReadonlyError。

如果没有修改性指令虽然连接不会得到切换但是数据不会被破坏所以即使不切换也没关系。

本文由