具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
以下结合附图,详细说明本申请各实施例提供的技术方案。
在现有技术中,通常采用服务器集群对请求进行处理,服务器集群指将很多服务器集中起来一起进行同一种服务,在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度,也可以用多个计算机做备份,从而使得任何一个机器坏了整个系统还是能正常运行。可以将服务器集群的一个服务器称为一个服务器节点。
现有技术中,通常采用负载均衡技术进行流量分发,流量分发即指将请求具体路由至哪一个服务器节点。负载均衡技术是一种电子计算机技术,用来在多个计算机(计算机集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载,以达到优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。其主要作用是将大量作业合理地分摊到多个操作单元上进行执行,用于解决互联网架构中的高并发和高可用的问题。
当采用负载均衡技术为请求分配服务器节点时,需要对服务器节点的健康状态进行检查,现有技术中,主要包括两种检查方法:主动健康检查和被动健康检查。主动健康检查指每隔固定时间向服务器发送请求检查是否能够收到响应;被动健康检查指只有访问服务器时才根据访问结果判断服务器的健康状态。
主动检查方式需要额外的流量,被动检查不能及时了解服务器的状态,具体的,图1中的a示出根据现有技术中一种请求处理系统的结构示意图,从图1中的a可以看出,该请求处理系统100包括请求终端110、请求处理服务器120和服务器集群130,其中,服务器集群包括多个服务器节点131。
采用图1中的a所示的结构示意图进行请求处理时,其流程可以简单描述为:请求终端110向请求处理服务器120发起一个请求,请求处理服务器120在接到该请求后,通过负载均衡方法确定服务器集群130中的一个服务器节点131作为目标服务器节点,将该请求发送至该目标服务器节点,目标服务器节点在对请求处理后,产生请求结果,并将请求结果返回至请求处理服务器120,请求处理服务器120将请求结果返回至发起请求的请求终端110。
在这个过程中,请求处理服务器120对于服务器集群130中各服务器节点的健康检查方法有两种,一种是采用主动检查的方法,即采取定时任务的方式,每隔一段时间,主动获取服务器集群130中各服务器节点131的健康状态,但这个过程会产生额外的流量;另一种方式,是被动检查的过程,即在向服务器节点发送请求的过程中,发现某一个服务器节点宕机,就将其标记为不健康的节点,再次发送请求时,则规避掉该服务器节点,这种方法的弊端,由于可能选取到一个宕机的服务器节点作为目标节点,延长了请求处理的时间。
基于上述情况,本申请提供了一种请求处理的方法,该方法可由请求处理服务器执行,请参考图1中的b,图1中的b示出了根据本申请的一个实施例的请求处理系统的结构示意图,从图1中的b可以看出,请求处理系统100-1同现有技术一样包括请求终端110-1、请求处理服务器120-1和服务器集群130-1,其中,服务器集群包括多个服务器节点131-1;不同于现有技术之处在于,在请求处理服务器120-1中部署有请求处理装置121,请求处理装置121中存储有节点标签集合,根据节点标签集合的记录实现请求的负载均衡分发。
需要说明的是,本申请不仅仅局限于使用图2示出的请求处理系统实现,凡是能够本申请的方法的电子设备均可。
图2示出了根据本申请的一个实施例的请求处理方法的流程示意图,从图2可以看出,本申请至少包括步骤S210~步骤S240:
步骤S210:接收待处理请求。
待处理请求由请求终端110-1发送至请求处理服务器120-1,请求处理服务器120-1接到待处理请求后,执行下述步骤以对待处理请求进行处理。
步骤S220:读取节点标签集合,所述节点标签集合包括若干个服务器节点和各服务器节点的状态,所述状态用于表征相应的服务器节点是否可用。
本申请主要是针对集群式服务器的场景设计的,如果是单机服务器,不存在请求分发的环节,直接发给单机服务器即可。
在本申请中,在请求处理服务器120-1中建立并存储有节点标签集合,节点标签集合记录有服务器集群130-1的多个服务器节点,以及各个服务器节点的状态。如节点标签集合中记录有三个服务器节点,分别为服务器节点A、服务器节点B和服务器节点C,以及这三个服务器节点的状态,服务器节点的状态可以包括但不限于该服务器节点可用与否。
在节点标签集合中,可以默认包括服务器集群的所有对外提供服务的服务器节点,并且默认各服务器节点的状态都是可用的。
步骤S230:根据所述节点标签集合,选择状态可用目标服务器节点,以对所述待处理请求进行处理。
然后根据节点标签集合,选择目标服务器节点,具体的选择方式,可以在节点标签集合中记录的可用的服务器节点中进行选择,如将可用的服务器节点中的任意一个作为目标服务器节点;或者可以根据负载均衡方法,在可用的服务器节点中,选择一个比较“空闲”的服务器节点作为目标服务器节点。在确定目标服务器节点后,将待处理请求发送至目标服务器节点进行处理。在本申请的一些实施例中,对于目标服务器节点的选择,可以采用加权轮询的方法,即基于服务器分配的权重值进行轮流选择,权重越大,选择的比例越高。
也就是说,本申请通过设置节点标签集合,对请求在哪些服务器节点中进行流量分配进行了限定,即对请求分发时,只将其分发给状态为可用的服务器节点,虽然不完全排除服务器节点在两次处理请求期间发生宕机,但是这种分发方式极大程度上规避了不可用的服务器节点,从而显著提高了请求处理的成功率。
需要说明的是,目标服务器节点可能在两次处理请求期间发生宕机,这时在节点标签集合中,目标服务器节点的状态仍然是可用的,因此,有将请求发送给一个不可用的目标服务器节点的可能,对此,可设置一个第一预设阈值,在通过一个目标服务器节点对一个待处理请求进行连续处理失败的次数超过该第一预设阈值的情况下,将目标服务节点视为不可用节点,并进行标记。
这种情况下,将节点标签集合中除去该目标服务器节点的其余服务器节点中的任意一个或者比较“空闲”的一个作为目标服务器。
步骤S240:根据所述请求处理结果,更新所述节点标签集合中目标服务器节点的状态。
最后,对节点标签集合进行动态更新和维护,具体的,一方面根据目标服务器对待处理请求的处理结果进行更新。
根据目标服务器对待处理请求的处理结果进行更新时,具体的,根据请求处理结果更新节点标签集合中目标服务器的状态,如将服务器节点A、服务器节点B和服务器节点C中的服务器节点A作为目标服务器节点,将请求发送给服务器节点A进行处理,相当于对服务器节点A进行了再次校验,若请求发送成功,或服务器节点A会返回对待处理请求的处理结果为成功,则说明服务器节点A可用,此时可不更新服务器节点A的状态;若请求发送不成功,或服务器节点A会返回对待处理请求的处理结果为失败,则说明服务器节点A不可用,此时可将节点标签集合中服务器节点A的状态更改为不可用。
由图2所示的方法可以看出,本申请通过设置了读取节点标签集合,在节点标签集合中记录有若干个服务器节点和个服务器节点的状态,在接到待处理请求后,可以根据节点标签集合中各个服务器节点以及服务器节点的状态,选择可用的服务器节点作为目标服务器节点,以对所述待处理请求进行处理,在每次处理完请求后,根据请求处理结果对节点标签集合中目标服务器节点的状态进行更新,以最大程度上保障读取节点标签集合的记录与各服务器节点的状态一致;且极大提高了请求处理的成功率,同时弥补了现有技术中,主动和被动健康检查方法的不足。本申请通过在节点标签集合动态记录和更新各服务器节点的状态,从而实现了仅依赖被动健康检查的方式,即可准确地进行服务器健康监督,既大大减少流量开销,又能提高请求处理成功率;且算法简单、计算量小、实用性强。
在本申请的一些实施例中,在所述读取节点标签集合的步骤之前,还包括:从本地缓存中读取历史哈希记录,所述历史哈希记录中记载有若干个哈希值,每个所述哈希值用于表征相应的服务器节点;确定所述待处理请求的第一哈希值;确定在所述历史哈希记录中,是否存在与所述第一哈希值一致的第二哈希值;若存在,将与所述第二哈希值对应的服务器节点作为目标服务器节点。
在请求处理服务器的本地缓存中存储历史哈希记录,在历史哈希记录中包含过去时间内多个对请求处理产生的哈希值,每个哈希值对应一个服务器节点。
若存在多个请求为相同的请求的情况,也就是说多个请求是相同的,如果为相同的请求分配不同的服务器节点,那不仅会造成尤其当服务器状态不稳定时服务节点的频繁切换问题,还会造成资源的浪费。
针对上述问题,本申请提供了一种一致性哈希算法,整体的思路是,记录成功处理请求的服务器节点,在一致性哈希的算法选择下,当相同的请求再次到达时,首先选择上次成功处理请求的服务器节点进行服务,保证相同的请求优先由同一台服务器进行处理,保证会话状态的延续。
具体的,在请求处理服务器的历史哈希记录中,记录历史处理中包含历史成功处理请求的哈希值,每个哈希值用于表征相应的一个服务器节点。当一个待处理请求到达请求处理服务器时,请求处理服务器根据该待处理请求的属性,确定该待处理请求的第一哈希值,然后在历史哈希记录中进行检索,若检索到与第一哈希值一致的哈希值,将这个哈希值记为第二哈希值,则直接将与所述第二哈希值对应的服务器节点作为目标服务器节点。需要说明的是,第二哈希值和第一哈希值是针对同样的请求生成的,即为第二哈希值和第一哈希值为同一哈希值。
若采取上述目标服务器节点对待处理请求进行处理成功,则跳过读取节点标签集合,所述节点标签集合包括若干个服务器节点和个服务器节点的状态;以及根据所述节点标签集合,选择目标服务器节点,以对所述待处理请求进行处理的步骤。
若在所述历史哈希记录中,不存在与所述第一哈希值一致的第二哈希值,或者若采取上述目标服务器节点对待处理请求进行处理失败,则再进入,读取节点标签集合,所述节点标签集合包括若干个服务器节点和个服务器节点的状态;以及根据所述节点标签集合,选择目标服务器节点,以对所述待处理请求进行处理的步骤。
在本申请的一些实施例中,所述根据所述节点标签集合,选择目标服务器节点,以对所述待处理请求进行处理,包括:根据所述节点标签集合中各服务器节点,以及各服务器节点的状态,确定出可用节点集合和不可用节点集合;将所述可用节点集合中的任意一个作为目标服务器节点;所述方法还包括:若通过所述目标服务器节点对所述待处理请求连续处理失败的次数大于预设阈值,则确定该目标服务器节点不可用,并将所述目标服务器节点加入不可用节点集合;从所述可用节点集合的其余服务器节点中,选择任意一个作为新的目标服务器节点,并将通过所述新的目标服务器节点对所述待处理请求进行处理;若所述可用节点集合中没有节点,则将所述不可用节点集合中任意一个作为目标服务器节点;通过所述目标服务器节点对所述待处理请求进行处理。
在多服务器场景下,待处理请求到达请求处理服务器,请求处理服务器每次需要在多台服务器节点中选择一台进行请求的处理。
当请求处理服务器收到访问请求时,根据当前节点标签集合中服务器集群的各服务器节点的状态进行选择。服务器节点状态由历史请求的处理结果反馈进行确定,如果一个服务器节点处理一个历史请求失败,则将该服务器节点的状态标记为不可用,并放入不可用节点集合中;如果一个服务器节点处理一个历史请求成功,则将该服务器节点的状态标记为可用,并放入可用节点集合中。假设在当前的节点标签集合的不可用节点集合中包含服务器节点R1和服务器节点R2,而可用节点集合中包含服务器节点R3、服务器节点R4、服务器节点R5。在选择时,直接在可用节点集合中进行选择,假设选择了服务器节点R3作为目标服务器节点,则将待处理请求发送至服务器节点R3进行处理,通过服务器节点R3对待处理请求进行处理,若通过服务器节点R3对待处理请求连续进行处理,若处理失败次数到达预设的次数阈值,处理都不成功,则将服务器节点R3标记为不可用节点,并放入不可用节点集合中;然后从剩下的服务器节点,即服务器节点R4和服务器节点R5中,重新进行新一轮的选择。在本申请的一些实施例中,在从多个服务器节点中进行选择的时候,可以采用负载均衡方法进行选择。
若读取可用节点集合时,发现可用节点集合没有记录任何服务器节点,这时,可以在不可用节点集合中,任意选择一个尝试发送待处理请求,若能够发送成功,且该服务器节点能够对待处理请求处理成功,则将服务器节点作为目标服务器节点,并将服务器节点的状态标记为可用,并放入可用节点集合中。如果不能发送成功,或该服务器节点对待处理请求处理失败,则继续从余下的服务器节点中进行选择。
在本申请的一些实施例中,所述服务器节点的状态至少通过失败次数和失败时间进行确定;所述根据所述节点标签集合中各服务器节点,以及各服务器节点的状态,确定出可用节点集合和不可用节点集合,包括:若通过一个服务器节点对所述待处理请求连续处理失败的次数未达到失败阈值,或者通过该服务器节点对所述待处理请求处理的最晚失败时间距离当前时间超过时间阈值,则确定该服务器节点的状态为可用,并将该服务器节点放入所述可用节点集合;若通过一个服务器节点对所述待处理请求连续处理失败的次数达到失败阈值,或者通过该服务器节点对所述待处理请求处理的最晚失败时间距离当前时间未达到时间阈值,则确定该服务器节点状态为不可用,并将该服务器节点放入所述不可用节点集合;所述根据所述请求处理结果,更新所述节点标签集合中目标服务器节点的状态,包括:若请求处理结果为成功,则将目标服务器节点的失败次数和失败时间初始化;若请求处理结果为失败,则对目标服务器节点的失败次数和失败时间进行更新。
在本申请的一些实施例中,服务器节点的状态可以是可用或不可用,其中,服务器节点的状态可以是根据失败次数和失败时间确定出的,其中,所述失败次数是指同一个服务器节点处理待处理请求失败的次数;失败时间是指一个服务器节点最后一次处理待处理请求失败的时间节点,即服务器节点对所述待处理请求处理的最晚时间。
在向某一个服务器节点发送请求时,则根据失败次数和失败时间确定该服务器节点是否可用,若可用,则向其发送请求;若不可用,则将该服务器节点标记为不可用,并放弃向该服务器节点发送请求。
在根据失败次数和失败时间确定该服务器节点是否可用时,可采取下面的方法,若通过一个服务器节点对所述待处理请求连续处理失败的次数未达到失败阈值,或者通过该服务器节点对所述待处理请求处理的最晚失败时间距离当前时间超过时间阈值,则确定该服务器节点的状态为可用,并将该服务器节点放入所述可用节点集合;若通过一个服务器节点对所述待处理请求连续处理失败的次数达到失败阈值,或者通过该服务器节点对所述待处理请求处理的最晚失败时间距离当前时间未达到时间阈值,则确定该服务器节点状态为不可用,并将该服务器节点放入所述不可用节点集合。在现有技术中,采用被动检测方法,如果一个宕机的服务器节点恢复到正常状态,请求处理服务器可能在很长一段时间内均不知道,导致该服务器节点一直不被使用,造成资源的浪费。
针对上述情况,在本申请的一些实施例中,提供了一种节点自动恢复方法,具体的,所述方法还包括:根据预设的节点恢复条件,更新所述节点标签集合中各服务器节点的状态。
本申请还可以实现对不可用的节点进行自动恢复,在对节点标签集合进行动态更新和维护的过程中,可根据预设的节点恢复条件对所有的服务器节点进行更新,具体的,若一个服务器节点的状态为不可用的时长大于等于预设的恢复时长阈值,则将该服务器节点的状态修改为可用。
对于发生宕机的服务器节点,这些“坏掉”的服务器节点通常在一段时间后会自动恢复或者被人为修好,在现有技术中,一旦一个服务器节点被记录为宕机,在后续流量分配的过程中,就会将该服务器节点排除在外,并不能支持“坏节点”的恢复。
针对这种情况,本申请提供了一种出现过问题的服务器节点的自动恢复方法,具体的,设置一个恢复时长阈值,若一个服务器节点被标记为不可用的时长达到该预设的恢复时长阈值,则将该服务器节点的状态修改为可用,即将该服务器节点恢复为可用,其中,在将服务器节点的状态修改为可用后,也可以将该服务器节点放入可用节点集合。当然了,这种方式不能完全排除将不可用的服务器节点误恢复为可用的服务器节点,但当请求处理服务器将请求发送至该服务器节点时,若该服务器节点实际为不可用的节点,那在发送请求的时候就会发现,从而将该服务器节点的状态更新为正确的。
如一个服务器节点R1在某一时刻从故障中恢复,则通过上述方法,其状态还会从不可用被标注为可用,下次请求访问时,依旧可以选择服务器节点R1作为目标服务器节点进行尝试访问。
当然了,采用上述预设的节点恢复条件更新服务器节点的状态的方式,可能会发生将一个不可用的服务器节点被标记为可用的,这种情况下,请求被发送给这个服务器节点,确发送不成功或者处理不成功,则可继续将该服务器节点标记为不可用,然后再在其他节点中继续选择目标服务器节点;但采用这种方式能够将不可用的节点进行自动恢复,很大程度上更加合理利用了服务器资源。
图3示出了根据本申请的另一个实施例的请求处理方法的流程示意图,从图3可以看出,本实施例包括:
接收请求终端发送的待处理请求。
根据待处理请求的属性,确定待处理请求的第一哈希值。
读取历史哈希记录,并将历史哈希记录中进行检索,确定在历史哈希记录中是否与第一哈希值一致的第二哈希值;若存在,将第二哈希值对应的服务器节点作为目标服务器节点。
若不存在,则读取节点标签集合,并根据节点标签集合中各服务器的状态划分为可用节点集合和不可用节点集合。
确定可用节点集合中是否存在服务器节点,若存在,则从可用节点集合中选择一个服务器节点作为目标服务器节点;若不存在,则从不可用节点集合中选择一个服务器节点作为目标服务器节点。
将待处理请求尝试发送给目标服务器节点,若发送成功,则确定请求处理成功,且将确定目标服务器节点的状态为可用或将其状态标记为可用,并确定其处于或将其放入可用节点集合。
若将待处理请求尝试发送给目标服务器节点的次数大于预设阈值,则将目标服务器节点的状态标记为不可用,并确定其处于或将其放入不可用节点集合;且从可用节点集合或不可用节点集合中进行重新一轮的选择。
对于标记为不可用的服务器节点,确定其状态为不可用的时长大于等于预设的恢复时长阈值,若大于,则恢复该服务器节点,即将其状态标注为可用,并放入可用节点集合。
图4示出了根据本申请的一个实施例的一种请求处理装置的结构示意图,从图4可以看出,该请求处理装置121包括:
接收单元1211,用于接收待处理请求;
读取单元1212,用于读取节点标签集合,所述节点标签集合记录有若干个服务器节点和各服务器节点的状态,所述状态用于表征相应的服务器节点是否可用;
选择单元1213,用于根据所述节点标签集合,选择状态为可用的目标服务器节点,以对所述待处理请求进行处理;
第一更新单元1214,用于根据所述请求处理结果,更新所述节点标签集合中目标服务器节点的状态。
在本申请的一些实施例中,上述装置还包括:哈希路由单元,用于在所述读取节点标签集合的步骤之前,从本地缓存中读取历史哈希记录,所述历史哈希记录中记载有若干个哈希值,每个所述哈希值用于表征相应的服务器节点;确定所述待处理请求的第一哈希值;确定在所述历史哈希记录中,是否存在与所述第一哈希值一致的第二哈希值;若存在,将与所述第二哈希值对应的服务器节点作为目标服务器节点。
在本申请的一些实施例中,上述装置还包括:哈希路由单元,还用于若在所述历史哈希记录中,不存在与所述第一哈希值一致的第二哈希值;或根据目标服务器节点对所述待处理请求进行处理得到的结果,确定所述目标服务器节点不可用;则进入所述读取节点标签集合的步骤。
在本申请的一些实施例中,在上述装置中,选择单元1213,用于根据所述节点标签集合中各服务器节点,以及各服务器节点的状态,确定出可用节点集合和不可用节点集合;将所述可用节点集合中的任意一个作为目标服务器节点;第一更新单元1214,用于若通过所述目标服务器节点对所述待处理请求连续处理失败的次数大于预设阈值,则确定该目标服务器节点不可用,并将所述目标服务器节点加入不可用节点集合;以及从所述可用节点集合的其余服务器节点中,选择任意一个作为新的目标服务器节点,并通过所述新的目标服务器节点对所述待处理请求进行处理。
在本申请的一些实施例中,在上述装置中,选择单元1213,还用于若所述可用节点集合中没有节点,则将所述不可用节点集合中任意一个作为目标服务器节点;通过所述目标服务器节点对所述待处理请求进行处理。
在本申请的一些实施例中,在上述装置中,所述服务器节点的状态至少通过失败次数和失败时间进行确定;选择单元1213,用于若通过一个服务器节点对所述待处理请求连续处理失败的次数未达到失败阈值,或者通过该服务器节点对所述待处理请求处理的最晚失败时间距离当前时间超过时间阈值,则确定该服务器节点的状态为可用,并将该服务器节点放入所述可用节点集合;若通过一个服务器节点对所述待处理请求连续处理失败的次数达到失败阈值,或者通过该服务器节点对所述待处理请求处理的最晚失败时间距离当前时间未达到时间阈值,则确定该服务器节点状态为不可用,并将该服务器节点放入所述不可用节点集合;第一更新单元1214,用于若请求处理结果为成功,则将目标服务器节点的失败次数和失败时间初始化;若请求处理结果为失败,则对目标服务器节点的失败次数和失败时间进行更新。
在本申请的一些实施例中,上述装置还包括:第二更新单元1215,用于若一个服务器节点的状态为不可用的时长大于等于预设的恢复时长阈值,则将该服务器节点的状态修改为可用。需要说明的是,在将服务器节点的状态修改为可用后,也可以将该服务器节点放入可用节点集合。
能够理解,上述请求处理装置,能够实现前述实施例中提供的请求处理方法的各个步骤,关于请求处理方法的相关阐释均适用于请求处理装置,此处不再赘述。
图5是本申请的一个实施例电子设备的结构示意图。请参考图5,在硬件层面,该电子设备包括处理器,可选地还包括内部总线、网络接口、存储器。其中,存储器可能包含内存,例如高速随机存取存储器(Random-Access Memory,RAM),也可能还包括非易失性存储器(non-volatile memory),例如至少1个磁盘存储器等。当然,该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接,该内部总线可以是ISA(Industry Standard Architecture,工业标准体系结构)总线、PCI(PeripheralComponent Interconnect,外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture,扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图5中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。
存储器,用于存放程序。具体地,程序可以包括程序代码,所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器,并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行,在逻辑层面上形成请求处理装置。处理器,执行存储器所存放的程序,并具体用于执行以下操作:
接收待处理请求;
读取节点标签集合,所述节点标签集合记录有若干个服务器节点和各服务器节点的状态,所述状态用于表征相应的服务器节点是否可用;
根据所述节点标签集合,选择状态为可用的目标服务器节点,以对所述待处理请求进行处理;
根据所述请求处理结果,更新所述节点标签集合中目标服务器节点的状态;
根据预设的节点恢复条件,更新所述节点标签集合中各服务器节点的状态。
上述如本申请图4所示实施例揭示的请求处理装置执行的方法可以应用于处理器中,或者由处理器实现。处理器可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
该电子设备还可执行图4中请求处理装置执行的方法,并实现请求处理装置在图4所示实施例的功能,本申请实施例在此不再赘述。
本申请实施例还提出了一种计算机可读存储介质,该计算机可读存储介质存储一个或多个程序,该一个或多个程序包括指令,该指令当被包括多个应用程序的电子设备执行时,能够使该电子设备执行图4所示实施例中请求处理装置执行的方法,并具体用于执行:
接收待处理请求;
读取节点标签集合,所述节点标签集合记录有若干个服务器节点和各服务器节点的状态,所述状态用于表征相应的服务器节点是否可用;
根据所述节点标签集合,选择状态为可用的目标服务器节点,以对所述待处理请求进行处理;
根据所述请求处理结果,更新所述节点标签集合中目标服务器节点的状态;
根据预设的节点恢复条件,更新所述节点标签集合中各服务器节点的状态。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。