Redis主从实例切换方法、装置、存储介质、计算机设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种Redis主从实例切换方法、装置、存储介质、计算机设备。

背景技术

Redis(Remote Dictionary Server)主要运行在Kubernete集群上，通过Operator自动化部署Redis相关的Kubernete资源，为负责请求转发以及负载均衡的Service以及触发哨兵切换主从标签事件驱动的程序资源，主要包括Redis主从实例的StatefulSet控制器、Redis哨兵的Deployment控制器，Redis实例以及Redis哨兵配置信息相关的ConfigMap。

Kubernete管理的云化环境中，Redis的主实例、从实例以及哨兵实例均被视为Kubernete系统中最小单为Pod，集群环境发生抖动造成的不稳定影响很大几率会让Pod发生重启，重启之后Pod会发生漂移，Redis的主实例和从实例访问地址也因此发生变动，导致对外缺乏一个稳定的访问入口。

发明内容

本申请的目的旨在至少能解决上述的技术缺陷之一，特别是现有技术中集群环境发生抖动造成的不稳定导致Redis的主实例和从实例访问地址发生变动，从而对外缺乏一个稳定的访问入口的技术缺陷。

本申请提供了一种Redis主从实例切换方法，所述方法包括：

获取监控程序以及钩子程序，并利用所述监控程序实时监听Redis中每一实例的心跳变化；

当监听到所有实例中存在任一实例的心跳异常时，将该心跳异常的实例作为第一实例，并判断所述第一实例是否为所述Redis的主实例；

若所述第一实例为所述Redis的主实例，则根据预设选举规则，在所述第一实例关联的所有从实例中选举出一个从实例作为第二实例，并触发所述监控程序进行角色切换，将所述第二实例的角色切换为所述Redis的主实例，所述第一实例的角色切换为所述第二实例的从实例；

利用所述监控程序获取所述第一实例对应的第一参数以及所述第二实例对应的第二参数，并将所述第一参数和所述第二参数传递给所述钩子程序；

基于所述第一参数和所述第二参数，利用所述钩子程序将所述第一实例和所述第二实例的Pod标签进行切换。

可选地，所述获取监控程序以及钩子程序，包括：

确定自定义资源定义CRD，所述CRD包括创建监控程序以及钩子程序的配置；

基于所述CRD，生成监控程序以及钩子程序。

可选地，所述利用所述监控程序监听Redis中每一实例的心跳变化，包括：

按照预设频率，利用所述监控程序向Redis的每一实例发送心跳检测命令；

基于所述心跳检测命令，获取每一所述实例的心跳检测结果；

根据每一所述实例的心跳检测结果，监听每一所述实例的心跳变化。

可选地，所述监听到所有实例中存在任一实例的心跳异常，包括：

若监听到所有实例中存在实例心跳间隔时间超过预设心跳超时时间，则判断该实例的心跳存在异常。

可选地，所述将所述第二实例的角色切换为所述Redis的主实例，所述第一实例的角色切换为所述第二实例的从实例，包括：

获取所述第一实例对应的第一实例ID和第一配置信息以及所述第二实例对应的第二实例ID和第二配置信息；

将所述第一实例ID和所述第二实例ID进行替换，并根据所述第一实例ID和所述第二实例ID修改所述第一实例对应的第一配置信息和所述第二实例对应的第二配置信息，以实现所述第一实例与所述第二实例的角色切换。

可选地，所述方法还包括：

对Redis中所有主实例的Pod标签进行实时检测，当检测到所有主实例中存在任一主实例的角色与Pod标签不符合，则确定所述Pod标签对应的从实例，并对所述主实例与所述从实例的Pod标签进行切换。

可选地，所述方法还包括：

若所述第一实例不为所述Redis的主实例，则断开所述第一实例和与所述第一实例关联的主实例之间的连接。

本申请还提供一种Redis主从实例切换装置，包括：

程序获取模块，用于获取监控程序以及钩子程序，并利用所述监控程序监听Redis中每一实例的心跳变化；

实例判断模块，用于当监听到所有实例中存在任一实例的心跳异常时，将该心跳异常的实例作为第一实例，并判断所述第一实例是否为所述Redis的主实例；

实例角色切换模块，用于根据预设选举规则，在所述第一实例关联的所有从实例中选举出一个从实例作为第二实例，并触发所述监控程序进行角色切换，将所述第二实例的角色切换为所述Redis的主实例，所述第一实例的角色切换为所述第二实例的从实例；

参数确定模块，用于利用监控程序确定所述第一实例对应的第一参数以及所述第二实例对应的第二参数，并将所述第二实例的角色切换为所述Redis的主实例，所述第一实例的角色切换为所述第二实例的从实例；

实例标签切换模块，用于基于所述第一参数和所述第二参数，利用所述钩子程序将所述第一实例和所述第二实例的Pod标签进行切换。

本申请还提供一种存储介质，所述存储介质中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述实施例中任一项所述Redis主从实例切换方法的步骤。

本申请还提供一种计算机设备，包括：一个或多个处理器，以及存储器；

所述存储器中存储有计算机可读指令，所述计算机可读指令被所述一个或多个处理器执行时，执行如上述实施例中任一项所述Redis主从实例切换方法的步骤。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请提供的Redis主从实例切换方法、装置、存储介质、计算机设备，在对Redis主从实例进行切换前，可以先获取监控程序以及钩子程序，以便在主实例发生异常时分别对主从实例的角色和Pod标签进行切换，并利用监控程序实时监听Redis中每一实例的心跳变化，当监听到所有实例中存在一个主实例心跳异常时，可以根据预设选举规则，在主实例关联的所有从实例中选举出一个从实例，并触发监控程序进行主从实例的角色切换，将选举出来的从实例角色切换为Redis新主实例，异常的主实例角色切换为新主实例的从实例，防止主实例长时间异常导致Pod发生重启进而改变了Redis主从实例的访问地址，接着可以获取切换角色后新主从实例的对应的参数并将参数传递给钩子程序，以触发钩子程序进行Pod标签切换，利用钩子程序将新主实例和新从实例的Pod标签进行切换，完成Redis主从实例的全部切换过程，从而对外保持一个稳定的访问入口。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。

图1为本申请实施例提供的一种Redis主从实例切换方法的流程示意图；

图2为本申请实施例提供的一种Redis主从实例切换方法的Redis故障转移流程示意图；

图3为本申请实施例提供的一种Redis主从实例切换装置的结构示意图；

图4为本申请实施例提供的一种计算机设备的内部结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

Kubernete管理的云化环境中，Redis的主实例、从实例以及哨兵实例均被视为Kubernete系统中最小单为Pod，集群环境发生抖动造成的不稳定影响很大几率会让Pod发生重启，重启之后Pod会发生漂移，Redis的主实例和从实例访问地址也因此发生变动，导致对外缺乏一个稳定的访问入口。

基于此，本申请提出了如下技术方案，具体参见下文：

在一个实施例中，如图1所示，图1为本申请实施例提供的一种Redis主从实例切换方法的流程示意图；本申请提供了一种Redis主从实例切换方法，所述方法可以包括：

S110：获取监控程序以及钩子程序，并利用监控程序实时监听Redis中每一实例的心跳变化。

本实施例中，为了监听集群中Redis的运行状态，能够在Redis发生故障时及时转移，可以在集群中对监控程序以及钩子程序进行配置，并利用监控程序实时监听Redis中每一实例的心跳变化，以便在Redis的主实例发生心跳异常时及时触发监控程序和钩子程序进行主从实例切换，及时转移故障。

可以理解的是，Redis是一个key-value存储系统，主要运行在Kubernete集群上，Redis支持主从同步，数据可以从主实例同步到任意数量的从实例上，在Kubernete集群上，主实例可以进行读写操作，当读写操作导致数据变化时会自动将数据同步到从实例，复制的数据流为单向，只能从主实例同步到从实例，而从实例一般都是只读的，并且接收主实例同步过来的数据，一个主实例可以拥有多个从实例，但一个从实例只能对应一个主实例。

进一步地，在集群中，当主实例宕机后，需要将一个从实例切换为主实例，会造成一段时间集群不可用，因此，Redis集群模式大都采用哨兵模式，哨兵为一个独立的监控程序，可以独立运行，对Redis中的主实例和从实例的运行状态进行监控，当哨兵监测到Redis主实例宕机，会自动将从实例切换成主实例，将主从切换过程从手动转换为自动，同时也减少主实例宕机导致的集群不可用时长。

S120：当监听到所有实例中存在任一实例的心跳异常时，将该心跳异常的实例作为第一实例，并判断所述第一实例是否为所述Redis的主实例。

本步骤中，通过S110获取监控程序后，可以利用该监控程序对Redis中的所有实例进行监听，当监听到所有实例中存在任一实例的心跳异常时，可以将该心跳异常的实例作为第一实例，并判断所述第一实例是否为所述Redis的主实例。

具体地，在集群中，主实例和从实例间需要进行信息交换，可以使用心跳机制进行维护，实现双方连接保持在线，配置监控程序后，监控程序可以向Redis上的所有主实例和从实例建立连接，对所有实例的心跳进行监听，以便在主实例出现故障时能够及时响应并对故障进行转移，以便维持集群的正常运行。

进一步地，在集群中，为减少监控程序的的误判，一般会配置多个监控程序，在判定主实例是否心跳异常时，不是由一个监控程序来决定的，而是只有大多数监控程序认为主实例已经下线，主实例才会标记为下线，这种判断机制为少数服从多数，当主实例被标记为下线的同时触发监控程序的主从切换模式。

举例来说，在一个Kubernetes集群部署有一套一主二从三哨兵的Redis实例，三个实例间彼此间有心跳检测机制，用于实现主实例与从实例之间连接保持在线，同时可以利用哨兵地对Kubernetes集群中的三个实例进行心跳监听，当所有哨兵在对三个实例进行监听时，若所有实例在规定时间内响应了两个或两个以上的哨兵，则判断所有实例都处于存活状态，若存在实例在规定时间内没有或只响应一个哨兵，则哨兵会判定该实例心跳异常。

S130：根据预设选举规则，在第一实例关联的所有从实例中选举出一个从实例作为第二实例，并触发监控程序进行角色切换，将第二实例的角色切换为Redis的主实例，第一实例的角色切换为第二实例的从实例。

本步骤中，通过步骤S120监听到第一实例的心跳异常，且该第一实例为主实例后，监控程序判定第一实例已经下线，接着可以根据预设选举规则，从第一实例关联的所有从实例中选举出一个从实例作为第二实例，并触发监控程序对第一实例和第二实例的角色进行切换，将第二实例的角色切换为Redis的主实例，第一实例的角色切换为第二实例的从实例，防止主实例长时间异常导致Pod发生重启进而改变了Redis主从实例的访问地址。

具体地，当集群中的主实例异常后，将会导致整个集群不可用，因此需要在第一实例关联的所有从实例中选举出一个从实例并切换为主实例，其中，与第一实例关联的所有从实例中的数据与第一实例的数据同步，根据预设选举规则，选举出一个一个从实例作为第二实例后，可以触发监控程序对第一实例和第二实例的角色进行切换，进而恢复整个集群的正常运行。

进一步地，在部署了一主多从Redis实例的集群中，当主实例心跳异常后对第一实例关联的所有从实例中选举新主实例时，可以通过预设选举规则对所有从实例进行选举，该选举过程可以是筛选和排序相结合，监控程序可以按照预设选举规则筛选掉不符合要求的从实例，然后从符合条件的从实例中进行排序，从而诞生出新主实例。

举例来说，在对Redis重新选主时，在筛选过程中，可以先筛除掉所有处于下线或者断线状态的从实例，保证剩余的从实例都是正常在线的，接着可以筛除掉所有在规定时间内没有响应哨兵的INFO命令的从实例，保证剩余的从实例都是最近成功进行通信的，最后筛除掉所有与已下线主实例连接断开超过down-after-milliseconds*10毫秒的从实例，保证剩余的从实例保存的数据都是比较新的，然后可以对筛选后的从实例进行排序，选择优先级最高的从实例，若有多个优先级最高的从实例，则选择复制偏移量最大的，当出现多个多个优先级最高、复制偏移量最大的从服务器时，比较运行ID，从而选择运行ID最小的从实例作为新主实例，其他可以实现本申请中新主实例选举的方式，均可以作为本申请优选的方案，在此不做限制。

S140：利用监控程序获取第一实例对应的第一参数以及第二实例对应的第二参数，并将第一参数和第二参数传递给钩子程序。

本实施例中，通过步骤S130对第一实例和第二实例的角色进行切换后，可以利用监控程序获取第一实例对应的第一参数以及第二实例对应的第二参数，并将第一参数和第二参数传递给所述钩子程序，以触发钩子程序的主从Pod标签切换。

需要说明的是，本申请的钩子程序可以是在监控程序主从实例角色切换事件后触发，用于对主从实例的Pod标签进行切换，而第一实例对应的第一参数以及第二实例对应的第二参数为第一实例与第二实例在角色切换后修改得到的最新参数，作为检验实例对应角色的依据。

S150：基于第一参数和第二参数，利用钩子程序将第一实例和第二实例的Pod标签进行切换。

本实施例中，通过步骤S140在钩子程序接收到第一实例对应的第一参数以及第二实例对应的第二参数后，对第一参数和第二参数进行解析，并确定第一实例和第二实例相对应的角色，在判断角色与实例携带的Pod标签不一致后，可以对第一实例和第二实例的Pod标签进行切换。

可以理解的是，在集群中的应用需要访问Redis时，是通过服务器关联到带有主实例Pod标签的Pod，进而访问Pod中的Redis实例，因此，在集群中Redis实例的角色和Pod标签要保持一致，才可以对外提供一个稳定的访问入口，其中，这里的Pod为Redis的主实例、从实例以及哨兵实例在集群中最小的原子调度单位。

上述实施例中，在对Redis主从实例进行切换前，可以先获取监控程序以及钩子程序，以便在主实例发生异常时分别对主从实例的角色和Pod标签进行切换，并利用监控程序实时监听Redis中每一实例的心跳变化，当监听到所有实例中存在一个主实例心跳异常时，可以根据预设选举规则，在主实例关联的所有从实例中选举出一个从实例，并触发监控程序进行主从实例的角色切换，将选举出来的从实例角色切换为Redis新主实例，异常的主实例角色切换为新主实例的从实例，防止主实例长时间异常导致Pod发生重启进而改变了Redis主从实例的访问地址，接着可以获取切换角色后新主从实例的对应的参数并将参数传递给钩子程序，以触发钩子程序进行Pod标签切换，利用钩子程序将新主实例和新从实例的Pod标签进行切换，完成Redis主从实例的全部切换过程，从而对外保持一个稳定的访问入口。

在一个实施例中，步骤S110中获取监控程序以及钩子程序的步骤，可以包括：

S111：确定自定义资源定义CRD，所述CRD包括创建监控程序以及钩子程序的配置。

S112：基于所述CRD，生成监控程序以及钩子程序。

本实施例中，为了监听集群中Redis的运行状态，能够在Redis发生故障时及时转移，可以在集群中利用自定义资源自定义创建监控程序以及钩子程序的配置的CRD(CustomResource Definition，自定义资源定义)，接着可以根据该CRD生成监控程序以及钩子程序，以便在Redis发生故障时及时对异常的主实例进行切换。

可以理解的是，自定义资源为Kubernetes集群中一种常见的扩展方式，即可以将自己定义的资源添加到Kubernetes集群中，用来扩展Kubernetes集群的功能，并像使用Kubernetes内置资源一样使用这些资源，本申请中通过CRD可以实现自定义资源，用来创建监控程序和钩子程序，从而实现Redis主从实例的切换。

在一个实施例中，步骤S110中利用监控程序监听Redis中每一实例的心跳变化的步骤，可以包括：

S113：按照预设频率，利用所述监控程序向Redis的每一实例发送心跳检测命令。

S114：基于所述心跳检测命令，获取每一实例的心跳检测结果。

S115：根据每一实例的心跳检测结果，监听每一实例的心跳变化。

本实施例中，在监听Redis中每一实例的心跳变化过程中，可以先按照预设频率，对利用监控程序向Redis的每一实例发送心跳检测命令，每一实例接收到心跳检测命令后进行响应，将心跳检测结果返回给监控程序，监控程序对每一实例的心跳检测进行判断，从而获取到每一实例的心跳变化，进而可以判断是否有实例下线。

举例来说，在一个部署了一套一主二从三哨兵的Redis实例的Kubernetes集群中，每个哨兵可以以每10秒一次的频率向Redis中的所有实例发送INFO命令，该频率可以由repl-ping-slave-period决定，一般默认10秒，进一步地，若主实例没有响应两个或两个以上的哨兵，被标记为客观下线时，哨兵对所有从实例发送INFO命令的频率会改为1秒一次，根据所有实例的返回结果确定主实例最终的状态，并最为主实例后下线Redis重新选主时的选举依据。

在一个实施例中，步骤S120中监听到所有实例中存在任一实例的心跳异常的步骤，可以包括：

S121：若监听到所有实例中存在实例心跳间隔时间超过预设心跳超时时间，则判断该实例的心跳异常。

本实施例中，在监听Redis中每一实例的心跳变化过程中，根据监控程序接收到的每一实例的心跳检测结果，对每一实例的心跳检测结果进行分析，若有实例心跳间隔时间超过预设心跳超时时间，则可以判断该实例的心跳异常。

举例来说，在Kubernetes集群中，可以通过参数为cluster-node-timeout的配置文件指定心跳超时时间，这里默认设置为15秒，通过对Kubernetes集群中所有实例返回的心跳检测结果进行分析，当Redis实例中存在实例没有返回心跳检测结果时长超过15秒，则可以判断该实例的心跳异常。

在一个实施例中，步骤S130中将第二实例的角色切换为Redis的主实例，所述第一实例的角色切换为第二实例的从实例的步骤，可以包括：

S131：获取所述第一实例对应的第一实例ID和第一配置信息以及所述第二实例对应的第二实例ID和第二配置信息。

S132：将所述第一实例ID和所述第二实例ID进行替换，并根据所述第一实例ID和所述第二实例ID修改所述第一实例对应的第一配置信息和所述第二实例对应的第二配置信息，以实现所述第一实例与所述第二实例的角色切换。

本实施例中，在对第一实例和第二实例进行主从实例角色切换时，可以先获取第一实例对应的第一实例ID和第一配置信息，以及第二实例对应的第二实例ID和第二配置信息，接着可以将获取到的第一实例ID和第二实例ID进替换，替换结束后，第一实例和第二实例可以根据新的实例ID对配置信息进行修改，从而实现所述第一实例与所述第二实例的角色切换，确保主实例的访问地址不会因长时间失联而改变。

可以理解的是，这里的实例ID为集群中每一个实例提供一个唯一ID，用于对实例进行唯一标识和跟踪，本申请利用替换主从实例ID，并根据实例ID进而修改主从实例对应的配置信息，完成主从实例角色切换事件，其中，主从实例的配置信息可以包括IP地址，端口号，保护模式，后台守护进程等。

在一个实施例中，所述方法还可以包括：

S160：对Redis中所有主实例的Pod标签进行实时检测，当检测到所有主实例中存在任一主实例的角色与Pod标签不符合，则确定所述Pod标签对应的从实例，并对所述主实例与所述从实例的Pod标签进行切换。

本实施例中，Redis集群上的Operator可以通过协程监听Redis主实例所在的Pod标签，当发现存在着主实例的Redis实际角色与Pod标签不符合时，会确定Pod标签对应的从实例，并及时切换主从实例的Pod标签，确保集群中应用访问Redis时可以通过Pod标签确定主实例，从而获取到相关数据。

具体地，本申请利用Operator和监控程序两者进行自动巡检，双重保证Redis的主从切换以及Pod标签与Redis实例角色保持一致，当哨兵出现异常没有触发钩子程序的主从Pod标签切换时间时，可以通过Operator的自动巡检及时发现并进行切换。

进一步地，若监控程序异常无法进行工作，Redis故障转移以及主从切换工作可以由Operator进行，同时对主从实例的角色和Pod标签进行切换，通过Operator和监控程序的双重保障实现Redis故障能够自动转移，无需人为介入修复故障Redis，减少运维人员的成本以及发现的时间。

在一个实施例中，所述方法还可以包括：

S170：若所述第一实例不为所述Redis的主实例，则断开所述第一实例和与所述第一实例关联的主实例之间的连接。

本实施例中，当监控程序Redis的所有实例进行监听，且监听到心跳异常的第一实例不为所述Redis的主实例时，断开第一实例和与第一实例关联的主实例之间的连接，待第一实例恢复正常后再与主实例进行连接。

举例来说，在Kubernetes集群中，哨兵在检测从实例时，发现从实例在规定时间内未响应，那么哨兵就会把它标记为“主观在线”，因为从实例的下线影响一般不大，Kubernetes集群的对外服务不会因此而间断，从实例掉线后，会断开与主实例的连接进行重启，若从实例重启后恢复正常，会根据Kubernetes集群信息加入集群，首先检查主实例是否在线，如果在线则自动重新进行连接，如果主实例不在线，则成为新选举出的主实例的从实例。

为了更好地对本申请的Redis主从实例切换方法进行解释，下面将通过图2来进一步说明，示意性地，如图2所示，图2为本申请实施例提供的一种Redis主从实例切换方法的Redis故障转移流程示意图。

图2中，在对Redis主从实例进行切换前，Operator可以通过自定义资源定义CRD添加监控程序以及钩子程序，并利用监控程序对Redis中的主实例和从实例的心跳进行监听，当监听到主实例的心跳异常导致Redis出现故障时，监控程序可以进行重新选主，从运行正常的从实例中重新选举出一个主实例，同时对选举出来的从实例进行角色切换，在监控程序触发选主事件后，钩子程序可以对切换角色后的主从实例进行标签切换，实现Redis故障转移，在监控程序对Redis中的主实例和从实例的心跳进行监听的同时，Operator可以持续对Redis中主实例和从实例的角色和标签进行检测，防止redis实例角色Pod标签不一致导致集群内应用无法通过关联访问主实例Pod标签进而访问主实例，从而对外提供稳定的服务。

下面对本申请实施例提供的Redis主从实例切换装置进行描述，下文描述的Redis主从实例切换装置与上文描述的Redis主从实例切换方法可相互对应参照。

在一个实施例中，如图3所示，图3为本申请实施例提供的一种Redis主从实例切换装置的结构示意图；本申请还提供了一种Redis主从实例切换装置，包括程序获取模块210，实例判断模块220，实例角色切换模块230，参数确定模块240，实例标签切换模块250，具体包括如下：

程序获取模块210，用于获取监控程序以及钩子程序，并利用监控程序监听Redis中每一实例的心跳变化。

实例判断模块220，用于当监听到所有实例中存在任一实例的心跳异常时，将该心跳异常的实例作为第一实例，并判断第一实例是否为所述Redis的主实例。

实例角色切换模块230，用于根据预设选举规则，在第一实例关联的所有从实例中选举出一个从实例作为第二实例，并触发监控程序进行角色切换，将第二实例的角色切换为Redis的主实例，第一实例的角色切换为第二实例的从实例。

参数确定模块240，用于利用监控程序获取第一实例对应的第一参数以及第二实例对应的第二参数，并将第一参数和第二参数传递给钩子程序。

实例标签切换模块250，用于基于第一参数和第二参数，利用钩子程序将第一实例和第二实例的Pod标签进行切换。

上述实施例中，在对Redis主从实例进行切换前，可以先获取监控程序以及钩子程序，以便在主实例发生异常时分别对主从实例的角色和Pod标签进行切换，并利用监控程序实时监听Redis中每一实例的心跳变化，当监听到所有实例中存在一个主实例心跳异常时，可以根据预设选举规则，在主实例关联的所有从实例中选举出一个从实例，并触发监控程序进行主从实例的角色切换，将选举出来的从实例角色切换为Redis新主实例，异常的主实例角色切换为新主实例的从实例，防止主实例长时间异常导致Pod发生重启进而改变了Redis主从实例的访问地址，接着可以获取切换角色后新主从实例的对应的参数并将参数传递给钩子程序，以触发钩子程序进行Pod标签切换，利用钩子程序将新主实例和新从实例的Pod标签进行切换，完成Redis主从实例的全部切换过程，从而对外保持一个稳定的访问入口。

在一个实施例中，所述程序获取模块210可以包括：

CRD定义子模块，用于确定自定义资源定义CRD，所述CRD包括创建监控程序以及钩子程序的配置；

程序生成子模块，用于基于所述CRD，生成监控程序以及钩子程序。

在一个实施例中，所述监控程序获取模块210还可以包括：

命令发送子模块，用于按照预设频率，利用所述监控程序向Redis的每一实例发送心跳检测命令。

结果获取子模块，用于基于所述心跳检测命令，获取每一所述实例的心跳检测结果。

心跳监听子模块，用于根据每一所述实例的心跳检测结果，监听每一所述实例的心跳变化。

在一个实施例中，所述实例判断模块220可以包括：

异常判断子模块，用于若监听到所有实例中存在实例心跳间隔时间超过预设心跳超时时间，则判断该实例的心跳异常。

在一个实施例中，所述实例角色切换模块230可以包括：

信息获取子模块，用于获取所述第一实例对应的第一实例ID和第一配置信息以及所述第二实例对应的第二实例ID和第二配置信息。

实例角色切换子模块，用于将所述第一实例ID和所述第二实例ID进行替换，并根据所述第一实例ID和所述第二实例ID修改所述第一实例对应的第一配置信息和所述第二实例对应的第二配置信息，以实现所述第一实例与所述第二实例的角色切换。

在一个实施例中，所述装置还可以包括：

标签巡检模块，用于对Redis中所有主实例的Pod标签进行实时检测，当检测到所有主实例中存在任一主实例的角色与Pod标签不符合，则确定所述Pod标签对应的从实例，并对所述主实例与所述从实例的Pod标签进行切换。

在一个实施例中，所述装置还可以包括：

主从实例连接模块，用于若所述第一实例不为所述Redis的主实例，则断开所述第一实例和与所述第一实例关联的主实例之间的连接。

在一个实施例中，本申请还提供了一种存储介质，所述存储介质中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述实施例中任一项所述Redis主从实例切换方法的步骤。

在一个实施例中，本申请还提供了一种计算机设备，所述计算机设备中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述实施例中任一项所述Redis主从实例切换方法的步骤。

示意性地，如图4所示，图4为本申请实施例提供的一种计算机设备的内部结构示意图，该计算机设备300可以被提供为一服务器。参照图4，计算机设备300包括处理组件302，其进一步包括一个或多个处理器，以及由存储器301所代表的存储器资源，用于存储可由处理组件302的执行的指令，例如应用程序。存储器301中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件302被配置为执行指令，以执行上述任意实施例的Redis主从实例切换方法。

计算机设备300还可以包括一个电源组件303被配置为执行计算机设备300的电源管理，一个有线或无线网络接口304被配置为将计算机设备300连接到网络，和一个输入输出(I/O)接口305。计算机设备300可以操作基于存储在存储器301的操作系统，例如WindowsServer TM、Mac OS XTM、Unix TM、Linux TM、Free BSDTM或类似。

本领域技术人员可以理解，图4中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间可以根据需要进行组合，且相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。