发明内容
本申请提供一种在线业务请求识别方法,用以解决现有技术中基于黑名单和白名单进行在线业务请求识别时,识别准确度降低,从而导致服务器的性能降低,甚至导致服务器瘫痪的问题。
本申请还提供了一种在线业务请求识别***、服务器和在线服务器集群,用以保证上述方法在实际中的实现及应用。
为了解决上述问题,本申请提供了一种在线业务请求识别方法,包括:
获取待识别的在线业务请求;
获取响应所述待识别的在线业务请求过程中消耗的***资源;
判断所述***资源是否大于资源阈值,如果是,则识别所述待识别的在线业务请求为异常请求;如果否,则识别所述待识别的在线业务请求为正常请求。
优选地,所述获取响应所述待识别的在线业务请求过程中消耗的***资源之前,还包括:
判断当前工作状态是否为异常状态;如果是,则执行所述获取响应所述待识别的在线业务请求过程中消耗的***资源的步骤;
如果否,则执行所述识别所述待识别的在线业务请求为正常请求的步骤。
优选地,还包括:
在所述当前工作状态由正常状态切换至异常状态时,设置响应所述待识别的在线业务请求的初始预设条数;
则所述获取响应所述待识别的在线业务请求过程中消耗的***资源,具体为:
针对多条待识别的在线业务请求,逐条获取响应所述多条待识别的在线业务请求过程中消耗的***资源,直到已经响应的所述待识别的在线业务请求的总条数达到所述初始预设条数。
优选地,在所述当前工作状态保持在所述异常状态,且获取到新的待识别的在线业务请求之后,还包括:
判断当前响应的所述待识别的在线业务请求的总条数是否大于所述初始预设条数;
如果是,则重新设定响应所述待识别的在线业务请求的总条数,并将重新设定的总条数作为所述初始预设条数。
优选地,还包括:
在所述当前工作状态为异常状态时,判断所述待识别的在线业务请求是否携带有预先设定的关键词;
如果否,执行所述获取响应所述待识别的在线业务请求过程中消耗的***资源步骤;
如果是,则执行所述识别所述待识别的在线业务请求为异常请求的步骤。
优选地,所述判断当前工作状态是否为异常状态包括:判断缓存的待识别的在线业务请求的总条数是否大于预设总条数。
优选地,所述判断所述***资源是否大于资源阈值,包括:判断响应所述待识别的在线业务请求时间是否大于预设时间或者响应所述待识别的在线业务请求消耗的内存资源是否大于预设内存使用量。
本申请还提供了一种在线业务请求识别***,包括:
请求获取单元,用于获取待识别的在线业务请求;
资源获取单元,用于获取响应所述待识别的在线业务请求过程中消耗的***资源;
资源判断单元,用于判断所述***资源是否大于资源阈值;
第一识别单元,用于在所述资源判断单元的结果为是的情况下,识别所述待识别的在线业务请求为异常请求;
第二识别单元,用于在所述资源判断单元的结果为否的情况下,识别所述待识别的在线业务请求为正常请求。
本申请还提供了一种服务器,包括:上述在线业务请求识别***
本申请还提供了一种在线服务器集群,多个服务器,所述任一服务器包括:上述在线业务请求识别***。
与现有技术相比,本申请包括以下优点:
本申请实施例所提供的在线业务请求识别方法对于每个待识别的在线业务请求,可以及时获取响应待识别的在线业务请求过程中消耗的***资源,在***资源大于资源阈值的情况下,即识别待识别的在线业务请求为异常请求,从而提高识别准确度。
更进一步地,待识别的在线业务请求被识别为异常请求后,服务器立即停止该异常请求的后续响应,避免了服务器响应异常请求过程中消耗大量的***资源,从而提高了服务器的性能,进一步避免服务器瘫痪。
当然,实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请可用于众多通用或专用的计算装置环境或配置中。例如:个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器装置、包括以上任何装置或设备的分布式计算环境等等。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本申请的主要思想之一可以包括,获取响应待识别的在线业务请求过程中消耗的***资源,在***资源大于资源阈值的情况下,识别待识别的在线业务请求为异常请求,提高了识别准确度,进一步提高服务器的性能,避免服务器瘫痪的问题。
参考图1,其示出了本申请一种在线业务请求识别方法实施例1的流程图,可以包括以下步骤:
步骤101:获取待识别的在线业务请求。
待识别的在线业务请求由不同客户端发送至在线服务器集群中的各个服务器,对于不同客户端发送的待识别的在线业务请求可以缓存至服务器的同一个任务队列中,也可以缓存至服务器的不同任务队列中,如服务器为每个客户端预先设置有一个任务队列,以缓存相对应的客户端发送的在线业务请求。
服务器获取待识别的在线业务请求时,可以按照待识别的在线业务请求缓存至任务队列的先后顺序获取,如FIFO(First Input First Output,先进先出)方式。FIFO是指先缓存至任务队列的请求优先被获取。
步骤102:获取响应待识别的在线业务请求过程中消耗的***资源。
其中:获取响应待识别的在线业务请求过程中消耗的***资源是为了使得服务器可以及时判断出获取的***资源是否大于资源阈值,并进一步地,在判断出***资源大于资源阈值的情况下,及时识别待识别的在线业务请求为异常请求,停止对该异常请求的响应。
上述***资源可以有不同含义,例如,***资源可以为响应待识别的在线业务请求时间。服务器可以从其内设置的一个计时器中获取响应待识别的在线业务请求时间,其中:计时器,用于记录响应待识别的在线业务请求时间。服务器还可以通过其内设置的两个计时器和一个运算器中获取响应待识别的在线业务请求时间,其中,一个计时器,用于记录获取到待识别的在线业务请求的当前时间,另一个计时器用于记录执行完该待识别的在线业务请求的当前时间,运算器则计算两个计时器的差值,得出响应该待识别的在线业务请求时间。
***资源还可以为内存资源,其中,内存资源为响应待识别的在线业务请求时,服务器的内存存储该请求执行过程结果所消耗的内存使用量。
步骤103:判断***资源是否大于资源阈值,如果是,执行步骤104,如果否,执行步骤105。
可根据***资源的不同预先设置不同的资源阈值。例如,在***资源为响应待识别的在线业务请求时间情况下,判断***资源是否大于资源阈值,可以为判断响应待识别的在线业务请求时间是否大于预设时间。其中,预设时间是服务器响应正常请求的平均时间,由服务器配置的硬件资源和软件资源决定。如预设时间可以为3秒。
在***资源为内存资源的情况下,判断***资源是否大于资源阈值,可以为判断响应待识别的在线业务请求消耗的内存资源是否大于预设内存使用量。其中,预设内存使用量是指服务器响应正常请求的最小内存使用量。
步骤104:识别待识别的在线业务请求为异常请求。
在***资源大于资源阈值的情况下,表明当前响应的待识别的在线业务请求在响应过程中会占用大量的***资源,该待识别的在线业务请求为一个不正常的请求。服务器响应该不正常的请求时,会消耗大量的***资源,导致服务器的性能降低,甚至会导致服务器瘫痪,所以将该待识别的在线业务请求识别为异常请求。
步骤105:识别待识别的在线业务请求为正常请求。
在***资源不大于资源阈值的情况下,表明当前响应的待识别的在线业务请求在响应过程中不会占用大量的***资源,该待识别的在线业务请求为一个正常的请求。服务器响应该正常的请求时,消耗适当的***资源,不会降低服务器的性能,所以将该待识别的在线业务请求识别为正常请求。
进一步地,服务器依据该正常请求中携带的具体请求内容进行后续响应。例如待识别的在线业务请求为正常查询请求,该正常查询请求中携带查询网站A中的产品B数据时,服务器接收到正常查询请求后,搜索网站A,获取网站A包括的产品B的数据,并将获取到的数据反馈给客户端。
综上所述,本申请实施例所提供的在线业务请求识别方法对于每个待识别的在线业务请求,可以及时获取响应待识别的在线业务请求过程中消耗的***资源,在***资源大于资源阈值的情况下,即识别待识别的在线业务请求为异常请求,从而提高识别准确度。
更进一步地,待识别的在线业务请求被识别为异常请求后,服务器立即停止该异常请求的响应,避免了服务器响应异常请求过程中消耗大量的***资源,从而提高了服务器的性能,进一步避免服务器瘫痪。
参考图2,其示出了本申请一种在线业务请求识别方法实施例2的流程图,可以包括以下步骤:
步骤201:获取待识别的在线业务请求。
步骤202:判断当前工作状态是否为异常状态;如果是,则执行步骤203;如果否,则执行步骤206。
本实施例与实施例1的不同之处在于,本实施例还包括对服务器的当前工作状态的判断。在不同的应用场景下,判断当前工作状态是否为异常状态可以有不同的实现方式。例如:判断缓存的待识别的在线业务请求的总条数是否大于预设总条数。当缓存的待识别的在线业务请求的总条数大于预设总条数时,表明服务器的当前工作状态为异常状态,需要停止异常请求的后续响应;当缓存的待识别的在线业务请求的总条数不大于预设总条数时,表明服务器的当前工作状态为正常状态,可以将待识别的在线业务请求全部作为正常请求响应。其中预设总条数为服务器将待识别的在线业务请求全部作为正常请求响应的最小总条数。
其中,预设总条数可以在服务器初始化时,由操作人员指定,也可以在服务器响应请求过程中,发送携带有预设总条数数值的更新请求至服务器,由服务器依据更新请求中的预设总条数数值实时更新其内设置的预设总条数。
步骤203:获取响应待识别的在线业务请求过程中消耗的***资源。
步骤204:判断***资源是否大于资源阈值,如果是,执行步骤205,如果否,执行步骤206。
步骤205:识别待识别的在线业务请求为异常请求。
步骤206:识别待识别的在线业务请求为正常请求。
本实施例所提供的在线业务请求识别方法,相对于上一个实施例提供的在线业务请求识别方法可以在当前工作状态为正常状态情况下,减少步骤203和204的执行过程,减少了正常状态情况下,服务器获取响应待识别的在线业务请求过程中消耗的***资源所消耗的时间以及***资源,从而提高了服务器的性能。
更进一步地,待识别的在线业务请求被识别为异常请求后,服务器立即停止该异常请求的后续响应,避免了服务器响应异常请求过程中消耗大量的***资源,从而进一步提高了服务器的性能,甚至可以避免服务器瘫痪。
参考图3,其示出了本申请一种在线业务请求识别方法实施例3的流程图,本实施例可以理解为将本申请的在线业务请求方法应用于实际中的一个具体例子,可以包括以下步骤:
步骤301:获取待识别的在线业务请求。
步骤302:在当前工作状态为异常状态情况下,判断当前工作状态与上一次工作状态是否相同;如果是,表明当前工作状态一直保持在异常状态,则执行步骤303;如果否,表明当前工作状态由上一次的正常状态切换至异常状态,则执行步骤310。
本实施例与实施例2的不同之处在于,本实施例还包括对服务器的当前工作状态和上一次工作状态是否相同的判断。在不同的应用场景下,判断当前工作状态和上一次工作状态是否相同可以有不同的实现方式。例如:判断当前工作状态和上一次工作状态是否相同,可以通过判断标志位的当前值和上一次值是否相同,其中,标志位用于标记工作状态。当标志位的当前值和上一次值相同时,表明当前工作状态和上一次工作状态相同;当标志位的当前值和上一次值不相同时,表明当前工作状态和上一次工作状态不相同。
需要说明的是,在当前工作状态一直保持在正常状态或者当前工作状态由上一次的异常状态切换至正常状态情况下,都执行步骤309。
步骤303:判断当前响应的待识别的在线业务请求的总条数是否大于初始预设条数,如果是,则执行步骤304,如果否,则执行步骤305。
其中,服务器可以从其内设置的计数器中获取当前响应的待识别的在线业务请求的总条数。上述计数器,用于记录当前响应的待识别的在线业务请求的总条数。
初始预设条数为服务器的当前工作状态第一次为异常状态时,服务器的当前工作状态一直保持在异常状态情况下,响应待识别的在线业务请求的最小总条数。
步骤304:重新设定响应待识别的在线业务请求的总条数,并将重新设定的总条数作为初始预设条数。
其中,重新设定可以为初始预设条数的加倍,也可以在初始预设条数基础上增加固定条数,如增加15条。
在本实施例中,设定初始预设条数适用于在线服务器集群接收到大量异常请求的情况,避免在每次获取到一个待识别的在线业务请求,重新判断工作状态,从而可以有效避免正常状态和异常状态的来回切换,更进一步地,可以有效避免在正常状态下,执行异常请求。
步骤305:判断待识别的在线业务请求是否携带有预先设定的关键词。如果否,执行步骤306,如果是,执行步骤308。
上述关键词是操作人员通过分析服务器之前响应的异常请求,获取多个异常请求中相同的词作为关键词。
步骤306:获取响应多条待识别的在线业务请求过程中消耗的***资源。
步骤307:判断***资源是否大于资源阈值,如果是,执行步骤308,如果否,执行步骤309。
步骤308:识别待识别的在线业务请求为异常请求。
步骤309:识别待识别的在线业务请求为正常请求。
需要说明的是:对于多条待识别的在线业务请求,在获取多条待识别的在线业务请求中的第一条待识别的在线业务请求,判断出当前工作状态一直保持在异常状态的情况后,后续获取多条中的其他待识别的在线业务请求后,依次执行步骤303至309,无需对工作状态再次进行判断,直到已经响应的待识别的在线业务请求的总条数达到初始预设条数。同样,在获取多条待识别的在线业务请求中的第一条待识别的在线业务请求,判断出当前工作状态由上一次的正常状态切换至异常状态的情况后,后续获取多条中的其他待识别的在线业务请求后,依次执行步骤310以及步骤305至309,也无需对工作状态再次进行判断,直到已经响应的待识别的在线业务请求的总条数达到初始预设条数。
步骤310:设置响应待识别的在线业务请求的初始预设条数,返回执行步骤305。
应用上述本实施例所提供的在线业务请求识别方法在提高识别准确度同时,相对于图1和图2所示的在线业务请求识别方法通过关键字判断可以及时识别出异常请求,降低服务器的***资源消耗,从而提高了服务器的性能。
更进一步地,待识别的在线业务请求被识别为异常请求后,服务器立即停止该异常请求的后续响应,避免了服务器响应异常请求过程中消耗大量的***资源,从而进一步提高了服务器的性能,甚至可以避免服务器瘫痪。
对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
与上述本申请一种在线业务请求识别方法实施例1所提供的方法相对应,参见图4,本申请还提供了一种在线业务请求识别***的优选实施例1,在本实施例中,该***可以包括:
请求获取单元41,用于获取待识别的在线业务请求。
待识别的在线业务请求由不同客户端发送至在线服务器集群中的不同服务器,对于不同客户端发送的待识别的在线业务请求可以缓存至服务器的同一个任务队列中,也可以缓存至服务器的不同任务队列中,如服务器为每个客户端预先设置有一个任务队列,以缓存相对应的客户端发送的在线业务请求。
服务器获取待识别的在线业务请求时,按照待识别的在线业务请求缓存至任务队列的先后顺序获取,如FIFO方式。FIFO是指先缓存至任务队列的请求优先被获取。
资源获取单元42,用于获取响应待识别的在线业务请求过程中消耗的***资源。
其中:获取响应待识别的在线业务请求过程中消耗的***资源是为了使得服务器可以及时判断出获取的***资源是否大于资源阈值,并进一步地,在判断出***资源大于资源阈值的情况下,及时识别待识别的在线业务请求为异常请求,停止对该异常请求的响应。
上述***资源可以有不同含义,例如,***资源可以为响应待识别的在线业务请求时间。服务器可以从其内设置的一个计时器中获取响应待识别的在线业务请求时间,其中:计时器,用于记录响应待识别的在线业务请求时间。服务器还可以通过其内设置的两个计时器和一个运算器中获取响应待识别的在线业务请求时间,其中,一个计时器,用于记录获取到待识别的在线业务请求的当前时间,另一个计时器用于记录执行完该待识别的在线业务请求的当前时间,运算器则计算两个计时器的差值,得出响应该待识别的在线业务请求时间。
***资源还可以为内存资源,其中,内存资源为响应待识别的在线业务请求时,服务器的内存存储该请求执行过程结果所消耗的内存使用量。
资源判断单元43,用于判断***资源是否大于资源阈值。
在***资源的含义不同时,资源阈值也需要预先设置的不同的数值。例如,资源判断单元43,可以用于判断响应待识别的在线业务请求时间是否大于预设时间。其中:预设时间是服务器响应正常请求的平均时间,由服务器配置的硬件资源和软件资源决定。如预设时间可以为3秒。
资源判断单元43,也可以用于判断响应待识别的在线业务请求消耗的内存资源是否大于预设内存使用量。其中:预设内存使用量是指服务器响应正常请求的最小内存使用量。
第一识别单元44,用于在资源判断单元43的结果为是的情况下,识别待识别的在线业务请求为异常请求。
在资源判断单元43的结果为是的情况下,表明当前响应的待识别的在线业务请求在响应过程中会占用大量的***资源,该待识别的在线业务请求为一个不正常的请求。服务器响应该不正常的请求时,会消耗大量的***资源,导致服务器的性能降低,甚至会导致服务器瘫痪,所以第一识别单元44,将该待识别的在线业务请求识别为异常请求。
第二识别单元45,用于在资源判断单元43的结果为否的情况下,识别待识别的在线业务请求为正常请求。
在资源判断单元43的结果为否的情况下,表明当前响应的待识别的在线业务请求在响应过程中不会占用大量的***资源,该待识别的在线业务请求为一个正常的请求。服务器响应该正常的请求时,消耗适当的***资源,不会降低服务器的性能,所以第二识别单元45将该待识别的在线业务请求识别为正常请求。
进一步地,服务器依据该正常请求中携带的具体请求内容进行后续响应。例如待识别的在线业务请求为正常查询请求,该正常查询请求中携带查询网站A中的产品B数据时,服务器接收到正常查询请求后,搜索网站A,获取网站A包括的产品B的数据,并将获取到的数据反馈给客户端。
本实施例所述的***可以集成到搜索引擎的服务器上,也可以单独作为一个实体与搜索引擎服务器相连,另外,需要说明的是,当本申请所述的方法采用软件实现时,可以作为搜索引擎的服务器新增的一个功能,也可以单独编写相应的程序,本申请不限定所述方法或***的实现方式。
本实施例对于每个待识别的在线业务请求,资源获取单元42可以及时获取响应待识别的在线业务请求过程中消耗的***资源,并在资源判断单元43判断***资源大于资源阈值的情况下,第一识别单元44即识别待识别的在线业务请求为异常请求,从而提高识别准确度。
更进一步地,待识别的在线业务请求被识别为异常请求后,服务器立即停止该异常请求的后续响应,避免了服务器响应异常请求过程中消耗大量的***资源,从而提高了服务器的性能,进一步避免服务器瘫痪。
与上述本申请一种在线业务请求识别方法实施例2所提供的方法相对应,参见图5,本申请还提供了一种在线业务请求识别***的优选实施例2,在本实施例中,该***以图4所示的在线业务请求识别***为基础,增加了状态判断单元46和触发器47。其中:
状态判断单元46,用于判断当前工作状态是否为异常状态。
在不同的应用场景下,状态判断单元46判断当前工作状态是否为异常状态可以有不同的实现方式。例如:判断缓存的待识别的在线业务请求的总条数是否大于预设总条数。当缓存的待识别的在线业务请求的总条数大于预设总条数时,表明服务器的当前工作状态为异常状态,需要停止异常请求的后续响应;当缓存的待识别的在线业务请求的总条数不大于预设总条数时,表明服务器的当前工作状态为正常状态,可以将待识别的在线业务请求全部作为正常请求响应。其中预设总条数为服务器将待识别的在线业务请求全部作为正常请求响应的最小总条数。
其中,预设总条数可以在服务器初始化时,由操作人员指定,也可以在服务器响应请求过程中,发送携带有预设总条数数值的更新请求至服务器,由服务器依据更新请求中的预设总条数数值实时更新其内设置的预设总条数。
触发器47,用于在状态判断单元46的结果为是的情况下,触发资源获取单元42,由资源获取单元42获取响应待识别的在线业务请求过程中消耗的***资源,以及在状态判断单元46的结果为否的情况下,触发第二识别单元45,由第二识别单元45,直接识别待识别的在线业务请求为正常请求。
综上所述,本实施例提供的在线业务请求识别***在提高识别准确度同时,触发器47可以状态判断单元46判断当前工作状态为正常状态情况下,触发第二识别单元45,由第二识别单元45,直接识别待识别的在线业务请求为正常请求,从而减少了正常状态情况下,服务器获取响应待识别的在线业务请求过程中消耗的***资源所消耗的时间以及***资源,提高了服务器的性能。
更进一步地,待识别的在线业务请求被识别为异常请求后,服务器立即停止该异常请求的后续响应,避免了服务器响应异常请求过程中消耗大量的***资源,从而进一步提高了服务器的性能,甚至可以避免服务器瘫痪。
与上述本申请一种在线业务请求识别方法实施例3所提供的方法相对应,参见图6,本申请还提供了一种在线业务请求识别***的优选实施例3,在本实施例中,该***以图5所示的在线业务请求识别***为基础,增加了预设条数设置单元48、条数判断单元49和关键词判断单元50。其中:
预设条数设置单元48,用于在当前工作状态由正常状态切换至异常状态时,设置响应待识别的在线业务请求的初始预设条数。
其中,服务器可以从其内设置的计数器中获取当前响应的待识别的在线业务请求的总条数。上述计数器,用于记录当前响应的待识别的在线业务请求的总条数。
初始预设条数为服务器的当前工作状态第一次为异常状态时,服务器的当前工作状态一直保持在异常状态情况下,响应待识别的在线业务请求的最小总条数。
条数判断单元49,用于在当前工作状态保持在异常状态,且请求获取单元41获取到新的待识别的在线业务请求后,判断当前响应的待识别的在线业务请求的总条数是否大于初始预设条数。
进一步触发器47,还用于在条数判断单元49的结果为是的情况下,触发预设条数设置单元48重新设定响应待识别的在线业务请求的总条数,并将重新设定的总条数作为初始预设条数。
其中:重新设定可以为初始预设条数的加倍,也可以在初始预设条数基础上增加固定条数,如增加15条。
关键词判断单元50,用于在当前工作状态为异常状态时,判断待识别的在线业务请求是否携带有预先设定的关键词。关键词是操作人员通过分析服务器之前响应的异常请求,获取多个异常请求中相同的词作为关键词。
进一步,触发器47,还用于在关键词判断单元50的结果为否的情况下,触发资源获取单元42,由资源获取单元42获取响应待识别的在线业务请求过程中消耗的***资源,以及在关键词判断单元的结果为是的情况下,触发第一识别单元44,直接识别待识别的在线业务请求为异常请求。
在本实施例中,应用上述本实施例所提供的在线业务请求识别方法在提高识别准确度同时,相对于图4和图5所示的在线业务请求识别***可以通过关键词判断单元50的关键字判断,由第一识别单元44及时识别出异常请求,降低服务器的***资源消耗,从而提高了服务器的性能。
更进一步地,待识别的在线业务请求被识别为异常请求后,在线服务器集群服务器立即停止该异常请求的后续响应,避免了在线服务器集群服务器响应异常请求过程中消耗大量的***资源,从而进一步提高了在线服务器集群服务器的性能,甚至可以避免在线服务器集群服务器瘫痪。
与上述本申请一种在线业务请求方法和***实施例相对应,本申请还提供了一种服务器的实施例,在本实施例中,服务器具体可以包括:在线业务请求识别***,该在线业务请求的具体组成可以参阅上述***实施例中的阐述,并可以结合相对应的结构框图,对此不再加以阐述。
与上述***实施例和服务器实施例相对应,本申请还提供了一种在线服务器集群的实施例,在本实施例中,在线服务器集群包括多个服务器,多个服务器并行处理由客户端发送的待识别的在线业务请求。任一服务器可以包括:在线业务请求识别***,该在线业务请求的具体组成可以参阅上述***实施例中的阐述,并可以结合相对应的结构框图,对此不再加以阐述。
需要说明的是,本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。对于***类实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个......”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
为了描述的方便,描述以上***时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
以上对本申请所提供的一种在线业务请求方法、***、服务器及在线服务器集群进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。