CN110442447B - 基于消息队列的负载均衡方法、装置和计算机设备 - Google Patents
基于消息队列的负载均衡方法、装置和计算机设备 Download PDFInfo
- Publication number
- CN110442447B CN110442447B CN201910602952.3A CN201910602952A CN110442447B CN 110442447 B CN110442447 B CN 110442447B CN 201910602952 A CN201910602952 A CN 201910602952A CN 110442447 B CN110442447 B CN 110442447B
- Authority
- CN
- China
- Prior art keywords
- request
- type
- requests
- preset
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5083—Techniques for rebalancing the load in a distributed system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5013—Request control
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Multi Processors (AREA)
Abstract
本申请涉及一种基于消息队列的负载均衡方法、装置、计算机设备和存储介质。所述方法涉及研发管理,具体包括:接收与用户触发操作对应的用户请求,利用预设校验规则对用户请求进行校验,生成校验结果,并根据校验结果,判断用户请求对应的请求类型,请求类型包括第一类请求和第二类请求。根据第一类请求设置对应的第一处理策略,第二类请求设置对应的第二处理策略,并将第一类请求按照第一处理策略、以及将第二类请求按照第二处理策略,分别发送至对应的目标服务器。采用本方法可将用户请求按照第一类请求和第二类请求区分开,分别执行对应的处理策略,避免所有用户请求均发送至同一个或固定的某几个目标服务器,解决服务器负载不均衡的问题。
Description
技术领域
本申请涉及计算机技术领域,特别是涉及一种基于消息队列的负载均衡方法、装置、计算机设备和存储介质。
背景技术
随着计算机技术的日益发展,企业应用系统内的实时数据和事务操作等,数量和规模也越来越大,为提高企业应用系统的业务处理能力,需要应用到负载均衡的技术。负载均衡建立在现有网络结构之上,可用于扩展网络设备和服务器的带宽、增加吞吐量以及加强网络数据处理能力,并提高网络的灵活性和可用性,主要思路是将工作分摊在多个操作单元上进行执行,例如web服务器、ftp服务器企业关键应用服务器以及其他任务服务器等,共同完成工作任务。
目前企业应用系统主要采用Nginx做负载均衡,由于系统需要使用session做登陆校验,故基本采用ip hash负载均衡策略,可通过引入消息队列中间件来解决系统高并发问题。但由于消息中间件发来的请求来源ip是固定的,会导致消息中间件来的请求都负载到某几台服务器,出现服务器集群内某几台服务器和其他服务器之间的负载悬殊非常大,导致出现负载不均衡的问题。
发明内容
基于此,有必要针对上述技术问题,提供一种能够实现服务器集群内各服务器间负载均衡的基于消息队列的负载均衡方法、装置、计算机设备和存储介质。
一种基于消息队列的负载均衡方法,所述方法包括:
接收与用户触发操作对应的用户请求;
利用预设校验规则对所述用户请求进行校验,生成校验结果;
根据所述校验结果,判断所述用户请求对应的请求类型;所述请求类型包括与第一类请求和第二类请求;
根据所述请求类型设置对应的处理策略;所述处理策略包括与所述第一类请求对应的第一处理策略,以及与所述第二类请求对应的第二处理策略;
将所述第一类请求按照所述第一处理策略、以及将所述第二类请求按照所述第二处理策略,分别发送至对应的目标服务器。
在其中一个实施例中,所述利用预设校验规则对所述用户请求进行校验,生成校验结果,包括:
获取预设校验规则;所述预设校验规则为cookie校验规则;
解析所述用户请求,获得所述用户请求携带的来源标志;
利用所述预设校验规则,对所述来源标志进行校验,生成校验结果。
在其中一个实施例中,所述校验结果包括与第一类请求对应的第一校验结果,和与第二类请求对应的第二校验结果;所述利用预设校验规则,对所述来源标志进行校验,生成校验结果,包括:
提取所述来源标志的属性信息;
根据所述cookie校验规则,对所述来源标志的属性信息进行校验;
当根据所述cookie校验规则,判断所述属性信息携带有预设系统来源标志对应的预设关键字时,生成第一校验结果;或
当根据所述cookie校验规则,判断所述属性信息未携带有预设系统来源标志对应的预设关键字时,生成第二校验结果。
在其中一个实施例中,所述根据所述请求类型设置对应的处理策略,包括:
从数据库中获取请求类型和处理策略的映射关系表;所述映射关系表包括所述第一类请求和所述第一处理策略的对应关系,以及所述第二类请求和所述第二处理策略的对应关系;
从所述映射关系表中,获取所述第一类请求和所述第一处理策略的对应关系,以及所述第二类请求和所述第二处理策略的对应关系;
根据所述第一类请求和所述第一处理策略的对应关系,为所述第一类请求设置对应的第一处理策略;根据所述第二类请求和所述第二处理策略的对应关系,为所述第二类请求设置对应的第二处理策略。
在其中一个实施例中,所述第一处理策略为轮询策略,所述第二处理策略为ip_hash策略;所述第一类请求为消息队列的回调请求,所述第二类请求为非回调请求;所述目标服务器包括第一类目标服务器和第二类目标服务器;所述将所述第一类请求按照所述第一处理策略、以及将所述第二类请求按照所述第二处理策略,分别发送至对应的目标服务器,包括:
根据将所述消息队列的回调请求按照所述轮询策略,发送至对应的第一类目标服务器;
将所述消息队列的非回调按照所述ip_hash策略,发送至对应的第二类目标服务器。
在其中一个实施例中,在所述利用预设校验规则对所述用户请求进行校验,生成校验结果之前,还包括:
获取待添加的预设系统来源标志,以及所述预设系统来源标志携带的预设关键字;所述预设关键字为"flag=mq";
将携带所述预设关键字的预设系统来源标志,添加至所述第二类请求对应的cookie中,并从本地浏览器的存储空间中获得预设cookie校验规则;
将所述cookie校验规则发送至反向代理服务器,在所述反向代理服务器中增加所述cookie校验规则;所述反向代理服务器内的cookie校验规则用于对所述用户请求进行IP地址校验。
一种基于消息队列的负载均衡装置,所述装置包括:
用户请求接收模块,用于接收与用户触发操作对应的用户请求;
用户请求校验模块,用于利用预设校验规则对所述用户请求进行校验,生成校验结果;
请求类型判断模块,用于根据所述校验结果,判断所述用户请求对应的请求类型;所述请求类型包括与第一类请求和第二类请求;
处理策略设置模块,用于根据所述请求类型设置对应的处理策略;所述处理策略包括与所述第一类请求对应的第一处理策略,以及与所述第二类请求对应的第二处理策略;
发送模块,用于将所述第一类请求按照所述第一处理策略、以及将所述第二类请求按照所述第二处理策略,分别发送至对应的目标服务器。
在其中一个实施例中,所述用户请求校验模块,还用于:
获取预设校验规则;所述预设校验规则为cookie校验规则;
解析所述用户请求,获得所述用户请求携带的来源标志;
利用所述预设校验规则,对所述来源标志进行校验,生成校验结果。
一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,所述处理器执行所述计算机程序时实现以下步骤:
接收与用户触发操作对应的用户请求;
利用预设校验规则对所述用户请求进行校验,生成校验结果;
根据所述校验结果,判断所述用户请求对应的请求类型;所述请求类型包括与第一类请求和第二类请求;
根据所述请求类型设置对应的处理策略;所述处理策略包括与所述第一类请求对应的第一处理策略,以及与所述第二类请求对应的第二处理策略;
将所述第一类请求按照所述第一处理策略、以及将所述第二类请求按照所述第二处理策略,分别发送至对应的目标服务器。
一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现以下步骤:
接收与用户触发操作对应的用户请求;
利用预设校验规则对所述用户请求进行校验,生成校验结果;
根据所述校验结果,判断所述用户请求对应的请求类型;所述请求类型包括与第一类请求和第二类请求;
根据所述请求类型设置对应的处理策略;所述处理策略包括与所述第一类请求对应的第一处理策略,以及与所述第二类请求对应的第二处理策略;
将所述第一类请求按照所述第一处理策略、以及将所述第二类请求按照所述第二处理策略,分别发送至对应的目标服务器。
上述基于消息队列的负载均衡方法、装置、计算机设备和存储介质,接收与用户触发操作对应的用户请求,利用预设校验规则对用户请求进行校验,生成校验结果。根据校验结果,判断用户请求对应的请求类型,请求类型包括与第一类请求和第二类请求。根据请求类型设置与第一类请求对应的第一处理策略,以及与第二类请求对应的第二处理策略,将第一类请求按照第一处理策略、以及将第二类请求按照第二处理策略,分别发送至对应的目标服务器。通过将用户请求按照第一类请求和第二类请求区分开后,分别执行对应的处理策略,避免所有用户请求均发送至同一个或固定的某几个目标服务器,解决了服务器负载不均衡的问题,提高了系统的稳定性。
附图说明
图1为一个实施例中基于消息队列的负载均衡方法的应用场景图;
图2为一个实施例中基于消息队列的负载均衡方法的流程示意图;
图3为一个实施例中利用预设校验规则得到校验结果的流程示意图;
图4为一个实施例中基于消息队列的负载均衡装置的结构框图;
图5为一个实施例中计算机设备的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
本申请提供的基于消息队列的负载均衡方法,可以应用于如图1所示的应用环境中。其中,终端102与目标服务器106通过反向代理中间件104进行通信。当终端102检测到用户的触发操作时,生成与触发操作对应的用户请求,并将用户请求发送至反向代理中间件104。反向代理中间件104接收终端102发送的与用户触发操作对应的用户请求时,利用预设校验规则对用户请求进行校验,生成校验结果。反向代理中间件104根据校验结果,判断用户请求对应的请求类型,请求类型包括与第一类请求和第二类请求,并根据请求类型设置与第一类请求对应的第一处理策略,以及与第二类请求对应的第二处理策略,将第一类请求按照第一处理策略、以及将第二类请求按照第二处理策略,分别发送至对应的目标服务器106。其中,终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机和平板电脑,目标服务器106可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
在一个实施例中,如图2所示,提供了一种基于消息队列的负载均衡方法,以该方法应用于图1中的服务器为例进行说明,包括以下步骤:
S202,接收与用户触发操作对应的用户请求。
具体地,当终端检测到用户的触发操作时,生成与触发操作对应的用户请求,并将用户请求发送至反向代理中间件。反向代理中间件可通过获取接收到的触发操作的类别,确定对应的用户请求。其中,触发操作包括检索操作、修改操作和删除操作,以及当前页面展示操作、前进页面展示操作和后退页面展示操作。
其中,用户请求包括与检索操作对应的检索请求、与修改操作对应的修改请求,与删除操作对应的删除请求,与当前页面展示操作对应的当前页面展示请求,与前进页面展示操作对应的前进页面展示请求,以及与后退页面展示操作后退页面展示请求。
进一步地,当反向代理中间件接收到的触发操作为检索操作时,生成与检索操作对应的检索请求,当接收到当前页面展示操作时,生成对应的当前页面展示请求。同样地,针对其他不同类别的触发操作,包括修改操作、删除操作、前进页面展示操作以及后退页面展示操作时,生成对应的修改请求、删除请求、前进页面展示请求以及后退页面展示请求。
S204,利用预设校验规则对用户请求进行校验,生成校验结果。
具体地,反向代理中间件通过获取预设校验规则,并解析用户请求,获得用户请求携带的来源标志,利用预设校验规则对来源标志进行校验,生成校验结果。
其中,预设校验规则为cookie校验规则,设置在反向代理服务器中,通过对用户请求携带的来源标志进行校验,判断来源标志是否携带预设关键字,进而判断来源标志是否为预设系统来源标志。其中,预设关键字为“flag=mq”。
进一步地,校验结果包括第一校验结果和第二校验结果。反向代理中间件通过提取来源标志的属性信息,利用cookie校验规则对来源标志的属性信息进行校验。当根据cookie校验规则,判断属性信息携带预设系统来源标志对应的预设关键字时,生成第一校验结果,第一校验结果表示用户请求携带的来源标志为预设系统来源标志。当根据cookie校验规则,判断属性信息未携带预设系统来源标志对应的预设关键字时,生成第二校验结果,第二校验结果表示用户请求携带的来源标志为非预设系统来源标志。
S206,根据校验结果,判断用户请求对应的请求类型。
具体地,用户请求对应的请求类型,包括与第一校验结果对应的第一类请求,以及与第二校验结果对应的第二类请求。当反向代理中间件根据第一校验结果,得到用户请求携带的来源标志为预设系统来源标志时,判断用户请求对应的请求类型为第一类请求。其中,第一类请求为消息队列的回调请求。当根据第二校验结果,得到用户请求携带的来源标志为非预设系统来源标志时,判断用户请求对应的请求类型为第二类请求。其中,第二类请求为除回调请求外的其他请求。
S208,根据请求类型设置对应的处理策略,处理策略包括第一类请求对应的第一处理策略,以及与第二类请求对应的第二处理策略。
具体地,处理策略包括第一处理策略和第二处理策略,反向代理中间件通过从数据库中获取请求类型和处理策略的映射关系表,其中,映射关系表包括第一类请求和第一处理策略的对应关系,以及第二类请求和第二处理策略的对应关系。进而反向代理中间件根据映射关系表,为第一类请求设置对应的第一处理策略,以及为第二类请求设置对应的第二处理策略。
其中,第一处理策略为轮询策略,其原理是将用户的请求轮流分配给内部的服务器,从服务器1开始,直到服务器N,然后开始重新循环,轮询策略无需记录当前所有连接的状态,是一种无状态的调度方式,十分简洁。但轮询算法假设所有服务器的处理性能都相同,不关心每台服务器的当前连接数和响应速度。
第二处理策略为ip_hash策略,在ip_hash策略中,它选择最初的server的方法是根据请求客户端的IP计算出一个哈希值,再根据哈希值选择后台的目标服务器,在选择下一个server时,ip_hash的选择策略会在上一次哈希值的基础上,再次哈希,就会得到一个全新的哈希值,再根据哈希值选择另外一个后台的目标服务器。
进一步地,反向代理中间件根据映射关系,为第一类请求,即回调请求,设置第一处理策略,即轮询策略。为第二类请求,即非回调请求的其他请求,设置第二处理策略,即ip_hash策略。
S210,将第一类请求按照第一处理策略、以及将第二类请求按照第二处理策略,分别发送至对应的目标服务器。
其中,目标服务器包括与第一类请求对应的第一类目标服务器,包括多个目标服务器,用于接收第一类请求,即回调请求,以及与第二类请求对应的第二类目标服务器,包括多个目标服务器,用于接收第二类奇请求,即除回调请求外的其他请求。
具体地,反向代理中间件将消息队列的回调请求按照轮询策略,发送至对应的第一类目标服务器,将非回调请求按照ip_hash策略,发送至对应的第二类目标服务器。
上述基于消息队列的负载均衡方法中,接收与用户触发操作对应的用户请求,利用预设校验规则对用户请求进行校验,生成校验结果。根据校验结果,判断用户请求对应的请求类型,请求类型包括与第一类请求和第二类请求。根据请求类型设置与第一类请求对应的第一处理策略,以及与第二类请求对应的第二处理策略,将第一类请求按照第一处理策略、以及将第二类请求按照第二处理策略,分别发送至对应的目标服务器。通过将用户请求按照第一类请求和第二类请求区分开后,分别执行对应的处理策略,避免所有用户请求均发送至同一个或固定的某几个目标服务器,解决了服务器负载不均衡的问题,提高了系统的稳定性。
在一个实施例中,如图3所示,提供了一种利用预设校验规则得到校验结果的步骤,即利用预设校验规则对用户请求进行校验,生成校验结果的步骤,包括以下S302至S306的步骤:
S302,获取预设校验规则,预设校验规则为cookie校验规则。
具体地,预设校验规则为cookie校验规则,设置在反向代理服务器中,通过对用户请求携带的来源标志进行校验,判断来源标志是否携带预设关键字,进而判断来源标志是否为预设系统来源标志。其中,预设关键字为“flag=mq”。
其中,在利用预设校验规则对用户请求进行校验,生成校验结果之前,还包括:反向代理中间件预先在第二类请求对应的cookie内添加预设系统来源标志,生成cookie校验规则,并在反向代理服务器中增加cookie校验规则。
S304,解析用户请求,获得用户请求携带的来源标志。
S306,利用预设校验规则,对来源标志进行校验,生成校验结果。
具体地,反向代理中间件通过提取来源标志的属性信息,利用cookie校验规则对来源标志的属性信息进行校验。当根据cookie校验规则,判断属性信息携带预设系统来源标志对应的预设关键字时,生成第一校验结果,第一校验结果表示用户请求携带的来源标志为预设系统来源标志。当根据cookie校验规则,判断属性信息未携带预设系统来源标志对应的预设关键字时,生成第二校验结果,第二校验结果表示用户请求携带的来源标志为非预设系统来源标志。
上述利用预设校验规则得到校验结果的步骤中,反向代理中间件通过获取预设校验规则,并解析用户请求,获得用户请求携带的来源标志,进而利用预设校验规则,对来源标志进行校验,生成校验结果。由于预先对用户请求的来源标志进行了校验,根据校验结果可判断用户是否携带预设系统来源标志,可避免将两种用户请求发送至相同的服务器,避免负载不均衡的问题。
在一个实施例中,校验结果包括与第一类请求对应的第一校验结果,和与第二类请求对应的第二校验结果,利用预设校验规则对用户请求进行校验,生成校验结果的步骤,具体包括:
反向代理中间件提取来源标志的属性信息;
根据cookie校验规则,对来源标志的属性信息进行校验;
当根据cookie校验规则,判断属性信息携带有预设系统来源标志对应的预设关键字时,生成第一校验结果;或
当根据cookie校验规则,判断属性信息,未携带有预设系统来源标志对应的预设关键字时,生成第二校验结果。
具体地,来源标志的属性信息包括用户请求的来源地以及发送时间等,根据cookie校验规则可对用户请求的属性信息进行校验,判断属性信息是否携带预设关键字“flag=mq”。当根据cookie校验规则,判断属性信息携带有预设系统来源标志对应的预设关键字“flag=mq”时,生成第一校验结果,第一校验结果表示,用户请求携带的来源标志为预设系统来源标志。当根据cookie校验规则,判断属性信息,未携带有预设系统来源标志对应的预设关键字“flag=mq”时,生成第二校验结果,第二校验结果表示,用户请求携带的来源标志为非预设系统来源标志。
上述利用预设校验规则对用户请求进行校验,生成校验结果的步骤,由于反向代理中间件利用cookie校验规则,预先对来源标志的属性信息进行了校验,根据得到校验结果可判断用户是否携带预设系统来源标志,进而可避免将两种用户请求发送至相同的目标服务器,解决负载不均衡的问题。
在一个实施例中,提供了一种根据请求类型设置对应的处理策略的步骤,具体包括:
反向代理中间件从数据库中获取请求类型和处理策略的映射关系表;映射关系表包括第一类请求和第一处理策略的对应关系,以及第二类请求和第二处理策略的对应关系;
从映射关系表中,获取第一类请求和第一处理策略的对应关系,以及第二类请求和第二处理策略的对应关系;
根据第一类请求和第一处理策略的对应关系,为第一类请求设置对应的第一处理策略;根据第二类请求和第二处理策略的对应关系,为第二类请求设置对应的第二处理策略。
具体地,反向代理中间件根据请求类型和处理策略的映射关系表,为第一类请求,即回调请求,设置第一处理策略,即轮询策略。为第二类请求,即非回调请求的其他请求,设置第二处理策略,即ip_hash策略。
其中,第一处理策略为轮询策略,其原理是将用户的请求轮流分配给内部的服务器,从服务器1开始,直到服务器N,然后开始重新循环,轮询策略无需记录当前所有连接的状态,是一种无状态的调度方式,十分简洁。但轮询算法假设所有服务器的处理性能都相同,不关心每台服务器的当前连接数和响应速度。
第二处理策略为ip_hash策略,在ip_hash策略中,它选择最初的server的方法是根据请求客户端的IP计算出一个哈希值,再根据哈希值选择后台的目标服务器,在选择下一个server时,ip_hash的选择策略会在上一次哈希值的基础上,再次哈希,就会得到一个全新的哈希值,再根据哈希值选择另外一个后台的目标服务器。
上述根据请求类型设置对应的处理策略的步骤中,从数据库中获取请求类型和处理策略的映射关系表,并从映射关系表中,获取第一类请求和第一处理策略的对应关系,以及第二类请求和第二处理策略的对应关系,并根据第一类请求和第一处理策略的对应关系,为第一类请求设置对应的第一处理策略,以及根据第二类请求和第二处理策略的对应关系,为第二类请求设置对应的第二处理策略。针对不同用户请求分别设置对应的处理策略,可按照不同处理策略,对不同类别的用户请求进行处理,避免不同类别的用户请求,采用相同处理策略,导致负载不均衡的问题。
在一个实施例中,提供了一种将第一类请求按照第一处理策略、以及将第二类请求按照第二处理策略,分别发送至对应的目标服务器的步骤,其中,第一处理策略为轮询策略,第二处理策略为ip_hash策略;第一类请求为消息队列的回调请求,第二类请求为非回调请求;目标服务器包括第一类目标服务器和第二类目标服务器。上述步骤具体包括:
反向代理中间件将消息队列的回调请求按照轮询策略,发送至对应的第一类目标服务器;将非回调请求按照ip_hash策略,发送至对应的第二类目标服务器。
其中,目标服务器包括与第一类请求对应的第一类目标服务器,包括多个目标服务器,用于接收第一类请求,即回调请求,以及与第二类请求对应的第二类目标服务器,包括多个目标服务器,用于接收第二类请求,即除回调请求外的其他请求。
上述步骤中,反向代理中间件通过将消息队列的回调请求按照轮询策略,发送至对应的第一类目标服务器,将非回调请求按照ip_hash策略,发送至对应的第二类目标服务器。针对不同类别的用户请求,设置了对应的处理策略,并按照不同处理策略,将用户请求发送至对应的目标服务器,避免将不同用户请求按照相同处理策略发送至同一类目标服务器,实现了服务器集群内各服务器间的负载均衡。
在一个实施例中,在利用预设校验规则对用户请求进行校验生成校验结果之前,还提供了以下步骤:
获取待添加的预设系统来源标志,以及预设系统来源标志携带的预设关键字;预设关键字为"flag=mq";
将携带预设关键字的预设系统来源标志,添加至第二类请求对应的cookie中,并从本地浏览器的存储空间中获得预设cookie校验规则;
将cookie校验规则发送至反向代理服务器,在反向代理服务器中增加cookie校验规则;反向代理服务器内的cookie校验规则用于对用户请求进行IP地址校验。
具体地,由于大多企业应用系统的接口设置了登录校验,需要实现会话保持功能,考虑到消息队列回调应用系统的接口均是免登陆请求,可预先在和消息队列的回调请求对应的cookie内,添加预设系统来源标志,并修改Nginx配置。之后在反向代理服务器内增加cookie校验,利用cookie对用户请求进行IP地址校验,进一步判断用户请求是否携带系统来源标识,如果携带系统来源标识,则表示该用户请求为与消息队列对应的回调请求,如果不携带系统来源标识,则表示该用户请求为其他请求,与消息队列的回调请求无关。
其中,在与消息队列的回调请求对应的cookie内增加的预设系统来源标志具体为"flag=mq",即通过反向代理服务器内增加的cookie校验,对用户请求进行IP地址校验,判断用户请求是否携带系统来源标识,进一步判断用户请求属于哪类请求,是属于与消息队列对应的回调请求,还是除回调请求外的其他请求。
上述步骤中,获取待添加的预设系统来源标志,以及预设系统来源标志携带的预设关键字,预设关键字为"flag=mq"。通过将携带预设关键字的预设系统来源标志,添加至第二类请求对应的cookie中,从本地浏览器的存储空间中获得预设cookie校验规则,并将cookie校验规则发送至反向代理服务器,在反向代理服务器中增加cookie校验规则,反向代理服务器内的cookie校验规则用于对用户请求进行IP地址校验。利用校验规则,可实现对用户请求的用户类型进行判断,进而为不同类型的用户请求设置对应的轮询策略或ip_hash策略,并发送至对应的第一类目标服务器或第二类目标服务器,实现服务器集群内各服务器间的负载均衡。
在一个实施例中,提供了一种当检测到触发操作时,生成与触发操作对应的用户请求的步骤,包括:
当反向代理中间件检测到触发操作时,获取触发操作的类别;触发操作的类别包括检索操作、修改操作、删除操作,当前页面展示操作、前进页面展示操作以及后退页面展示操作;
根据所触发操作的类别,生成对应的用户请求;用户请求包括与检索操作对应的检索请求、与修改操作对应的修改请求,与删除操作对应的删除请求,与当前页面展示操作对应的当前页面展示请求,与前进页面展示操作对应的前进页面展示请求,以及与后退页面展示操作后退页面展示请求。
其中,当反向代理中间件检测到的触发操作为检索操作时,生成与检索操作对应的检索请求,当检测到当前页面展示操作时,生成对应的当前页面展示请求。同样地,针对其他不同类别的触发操作,包括修改操作、删除操作、前进页面展示操作以及后退页面展示操作时,生成对应的修改请求、删除请求、前进页面展示请求以及后退页面展示请求。
上述步骤中,当反向代理中间件检测不同触发操作时,生成与触发操作对应的用户请求,实现了触发操作和用户请求的一一对应,后续可分别将不同用户请求发送至对应的目标服务器,提高了工作效率。
应该理解的是,虽然图2-3的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,图2-3中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些子步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
在一个实施例中,如图4所示,提供了一种基于消息队列的负载均衡装置,包括:用户请求接收模块402、用户请求校验模块404、请求类型判断模块406、处理策略设置模块408和发送模块410,其中:
用户请求接收模块402,用于接收与用户触发操作对应的用户请求。
用户请求校验模块404,用于利用预设校验规则对用户请求进行校验,生成校验结果。
请求类型判断模块406,用于根据校验结果,判断用户请求对应的请求类型;请求类型包括与第一类请求和第二类请求。
处理策略设置模块408,用于根据请求类型设置对应的处理策略;处理策略包括与第一类请求对应的第一处理策略,以及与第二类请求对应的第二处理策略。
发送模块410,用于将第一类请求按照第一处理策略、以及将第二类请求按照第二处理策略,分别发送至对应的目标服务器。
上述基于消息队列的负载均衡装置中,通过将用户请求按照第一类请求和第二类请求区分开后,分别执行对应的处理策略,避免所有用户请求均发送至同一个或固定的某几个目标服务器,解决了服务器负载不均衡的问题,提高了系统的稳定性。
在一个实施例中,提供了一种用户请求校验模块,还用于:
获取预设校验规则;预设校验规则为cookie校验规则;解析用户请求,获得用户请求携带的来源标志;利用预设校验规则,对来源标志进行校验,生成校验结果。
上述用户请求校验模块,由于预先对用户请求的来源标志进行了校验,根据校验结果可判断用户是否携带预设系统来源标志,可避免将两种用户请求发送至相同的服务器,避免负载不均衡的问题。
在一个实施例中,提供了一种用户请求校验模块,还用于:
提取来源标志的属性信息;根据cookie校验规则,对来源标志的属性信息进行校验;
当根据cookie校验规则,判断属性信息携带有预设系统来源标志对应的预设关键字时,生成第一校验结果;或
当根据cookie校验规则,判断属性信息,未携带有预设系统来源标志对应的预设关键字时,生成第二校验结果。
上述用户校验模块中,由于反向代理中间件利用cookie校验规则,预先对来源标志的属性信息进行了校验,根据得到校验结果可判断用户是否携带预设系统来源标志,进而可避免将两种用户请求发送至相同的目标服务器,解决负载不均衡的问题。
在一个实施例中,提供了一种处理策略设置模块,还用于:
从数据库中获取请求类型和处理策略的映射关系表;映射关系表包括第一类请求和第一处理策略的对应关系,以及第二类请求和第二处理策略的对应关系;
从映射关系表中,获取第一类请求和第一处理策略的对应关系,以及第二类请求和第二处理策略的对应关系;
根据第一类请求和第一处理策略的对应关系,为第一类请求设置对应的第一处理策略;根据第二类请求和第二处理策略的对应关系,为第二类请求设置对应的第二处理策略。
上述处理策略设置模块中,针对不同用户请求分别设置对应的处理策略,可按照不同处理策略,对不同类别的用户请求进行处理,避免不同类别的用户请求,采用相同处理策略导致负载不均衡的问题。
在一个实施例中,提供了一种发送模块,还用于:
将消息队列的回调请求按照轮询策略,发送至对应的第一类目标服务器;或将非回调请求按照ip_hash策略,发送至对应的第二类目标服务器。
上述发送模块,针对不同类别的用户请求,设置了对应的处理策略,并按照不同处理策略,将用户请求发送至对应的目标服务器,避免将不同用户请求按照相同处理策略发送至同一类目标服务器,实现了服务器集群内各服务器间的负载均衡。
在一个实施例中,提供了一种基于消息队列的负载均衡方法,还包括校验规则添加模块,用于:
获取待添加的预设系统来源标志,以及预设系统来源标志携带的预设关键字;预设关键字为"flag=mq";
将携带预设关键字的预设系统来源标志,添加至第二类请求对应的cookie中,并从本地浏览器的存储空间中获得预设c ookie校验规则;
将cookie校验规则发送至反向代理服务器,在反向代理服务器中增加cookie校验规则;反向代理服务器内的cookie校验规则用于对用户请求进行IP地址校验。
上述校验规则添加模块,反向代理中间件利用校验规则,可实现对用户请求的用户类型进行判断,进而为不同类型的用户请求设置对应的轮询策略或ip_hash策略,并发送至对应的第一类目标服务器或第二类目标服务器,实现服务器集群内各服务器间的负载均衡。
在一个实施例中,提供了一种用户请求生成模块,还用于:
当检测到触发操作时,获取触发操作的类别;触发操作的类别包括检索操作、修改操作、删除操作,当前页面展示操作、前进页面展示操作以及后退页面展示操作;
根据所触发操作的类别,生成对应的用户请求;用户请求包括与检索操作对应的检索请求、与修改操作对应的修改请求,与删除操作对应的删除请求,与当前页面展示操作对应的当前页面展示请求,与前进页面展示操作对应的前进页面展示请求,以及与后退页面展示操作后退页面展示请求。
上述用户请求生成模块,当反向代理中间件检测不同触发操作时,生成与触发操作对应的用户请求,实现了触发操作和用户请求的一一对应,后续可分别将不同用户请求发送至对应的目标服务器,提高了工作效率。
关于基于消息队列的负载均衡装置的具体限定,可以参见上文中对于基于消息队列的负载均衡方法的限定,在此不再赘述。上述基于消息队列的负载均衡装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中,提供了一种计算机设备,该计算机设备可以是终端,其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中,该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于消息队列的负载均衡方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏,该计算机设备的输入装置可以是显示屏上覆盖的触摸层,也可以是计算机设备外壳上设置的按键、轨迹球或触控板,还可以是外接的键盘、触控板或鼠标等。
本领域技术人员可以理解,图5中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
在一个实施例中,提供了一种计算机设备,包括存储器和处理器,该存储器存储有计算机程序,该处理器执行计算机程序时实现以下步骤:
接收与用户触发操作对应的用户请求;
利用预设校验规则对用户请求进行校验,生成校验结果;
根据校验结果,判断用户请求对应的请求类型;请求类型包括与第一类请求和第二类请求;
根据请求类型设置对应的处理策略;处理策略包括与第一类请求对应的第一处理策略,以及与第二类请求对应的第二处理策略;
将第一类请求按照第一处理策略、以及将第二类请求按照第二处理策略,分别发送至对应的目标服务器。
在一个实施例中,处理器执行计算机程序时还实现以下步骤:
获取预设校验规则;预设校验规则为cookie校验规则;
解析用户请求,获得用户请求携带的来源标志;
利用预设校验规则,对来源标志进行校验,生成校验结果。
在一个实施例中,处理器执行计算机程序时还实现以下步骤:
提取来源标志的属性信息;
根据cookie校验规则,对来源标志的属性信息进行校验;
当根据cookie校验规则,判断属性信息携带有预设系统来源标志对应的预设关键字时,生成第一校验结果;或
当根据cookie校验规则,判断属性信息,未携带有预设系统来源标志对应的预设关键字时,生成第二校验结果。
在一个实施例中,处理器执行计算机程序时还实现以下步骤:
从数据库中获取请求类型和处理策略的映射关系表;映射关系表包括第一类请求和第一处理策略的对应关系,以及第二类请求和第二处理策略的对应关系;
从映射关系表中,获取第一类请求和第一处理策略的对应关系,以及第二类请求和第二处理策略的对应关系;
根据第一类请求和第一处理策略的对应关系,为第一类请求设置对应的第一处理策略;根据第二类请求和第二处理策略的对应关系,为第二类请求设置对应的第二处理策略。
在一个实施例中,处理器执行计算机程序时还实现以下步骤:
将消息队列的回调请求按照轮询策略,发送至对应的第一类目标服务器;或将非回调请求按照ip_hash策略,发送至对应的第二类目标服务器。
在一个实施例中,处理器执行计算机程序时还实现以下步骤:
预先在第二类请求对应的cookie内添加预设系统来源标志,生成cookie校验规则;
在反向代理服务器中增加cookie校验规则。
在一个实施例中,提供了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现以下步骤:
接收与用户触发操作对应的用户请求;
利用预设校验规则对用户请求进行校验,生成校验结果;
根据校验结果,判断用户请求对应的请求类型;请求类型包括与第一类请求和第二类请求;
根据请求类型设置对应的处理策略;处理策略包括与第一类请求对应的第一处理策略,以及与第二类请求对应的第二处理策略;
将第一类请求按照第一处理策略、以及将第二类请求按照第二处理策略,分别发送至对应的目标服务器。
在一个实施例中,计算机程序被处理器执行时还实现以下步骤:
获取预设校验规则;预设校验规则为cookie校验规则;
解析用户请求,获得用户请求携带的来源标志;
利用预设校验规则,对来源标志进行校验,生成校验结果。
在一个实施例中,计算机程序被处理器执行时还实现以下步骤:
提取来源标志的属性信息;
根据cookie校验规则,对来源标志的属性信息进行校验;
当根据cookie校验规则,判断属性信息携带有预设系统来源标志对应的预设关键字时,生成第一校验结果;或
当根据cookie校验规则,判断属性信息,未携带有预设系统来源标志对应的预设关键字时,生成第二校验结果。
在一个实施例中,计算机程序被处理器执行时还实现以下步骤:
从数据库中获取请求类型和处理策略的映射关系表;映射关系表包括第一类请求和第一处理策略的对应关系,以及第二类请求和第二处理策略的对应关系;
从映射关系表中,获取第一类请求和第一处理策略的对应关系,以及第二类请求和第二处理策略的对应关系;
根据第一类请求和第一处理策略的对应关系,为第一类请求设置对应的第一处理策略;根据第二类请求和第二处理策略的对应关系,为第二类请求设置对应的第二处理策略。
在一个实施例中,计算机程序被处理器执行时还实现以下步骤:
将消息队列的回调请求按照轮询策略,发送至对应的第一类目标服务器;或将非回调请求按照ip_hash策略,发送至对应的第二类目标服务器。
在一个实施例中,计算机程序被处理器执行时还实现以下步骤:
获取待添加的预设系统来源标志,以及预设系统来源标志携带的预设关键字;预设关键字为"flag=mq";
将携带预设关键字的预设系统来源标志,添加至第二类请求对应的cookie中,并从本地浏览器的存储空间中获得预设cookie校验规则;
将cookie校验规则发送至反向代理服务器,在反向代理服务器中增加cookie校验规则;反向代理服务器内的cookie校验规则用于对用户请求进行IP地址校验。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限,RAM以多种形式可得,诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。
以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。
Claims (10)
1.一种基于消息队列的负载均衡方法,应用于反向代理中间件,所述方法包括:
接收与用户触发操作对应的用户请求;其中,不同触发操作对应不同触发操作类别,不同触发操作类别的触发操作分别对应不同请求类型的用户请求,不同请求类型的用户请求用于发送至不同的目标服务器进行处理;所述触发操作包括检索操作、修改操作和删除操作、当前页面展示操作、前进页面展示操作以及后退页面展示操作;
利用设置在反向代理服务器中的预设校验规则对所述用户请求进行IP地址校验,判断所述用户请求是否携带包括预设关键字的系统来源标志,以生成校验结果;
根据所述校验结果,判断所述用户请求对应的请求类型;所述请求类型包括携带系统来源标志的第一类请求、和不携带系统来源标志的第二类请求;所述第一类请求为消息队列的回调请求,所述第二类请求为除所述消息队列的回调请求之外的其他请求;
根据所述请求类型设置对应的处理策略;所述处理策略包括与所述第一类请求对应的第一处理策略,以及与所述第二类请求对应的第二处理策略;所述第一处理策略为轮询策略,用于将用户的请求轮流分配给内部的服务器,从服务器1开始,直到服务器N,并不断重新循环;所述第二处理策略为ip_hash策略,用于根据请求客户端的IP计算出一个哈希值,再根据哈希值选择后台的目标服务器;其中,在选择下一个服务器时时,在上一次哈希值的基础上,再次哈希,得到更新后的哈希值,再根据更新后的哈希值选择另外一个目标服务器;
将所述第一类请求按照所述第一处理策略、以及将所述第二类请求按照所述第二处理策略,分别发送至对应的目标服务器。
2.根据权利要求1所述的方法,其特征在于,所述利用预设校验规则对所述用户请求进行校验,生成校验结果,包括:
获取预设校验规则;所述预设校验规则为cookie校验规则;
解析所述用户请求,获得所述用户请求携带的来源标志;
利用所述预设校验规则,对所述来源标志进行校验,生成校验结果。
3.根据权利要求2所述的方法,其特征在于,所述校验结果包括与第一类请求对应的第一校验结果,和与第二类请求对应的第二校验结果;所述利用预设校验规则,对所述来源标志进行校验,生成校验结果,包括:
提取所述来源标志的属性信息;
根据所述cookie校验规则,对所述来源标志的属性信息进行校验;
当根据所述cookie校验规则,判断所述属性信息携带有预设系统来源标志对应的预设关键字时,生成第一校验结果;或
当根据所述cookie校验规则,判断所述属性信息未携带有预设系统来源标志对应的预设关键字时,生成第二校验结果。
4.根据权利要求3所述的方法,其特征在于,所述根据所述请求类型设置对应的处理策略,包括:
从数据库中获取请求类型和处理策略的映射关系表;所述映射关系表包括所述第一类请求和所述第一处理策略的对应关系,以及所述第二类请求和所述第二处理策略的对应关系;
从所述映射关系表中,获取所述第一类请求和所述第一处理策略的对应关系,以及所述第二类请求和所述第二处理策略的对应关系;
根据所述第一类请求和所述第一处理策略的对应关系,为所述第一类请求设置对应的第一处理策略;根据所述第二类请求和所述第二处理策略的对应关系,为所述第二类请求设置对应的第二处理策略。
5.根据权利要求4所述的方法,其特征在于,所述目标服务器包括第一类目标服务器和第二类目标服务器;所述将所述第一类请求按照所述第一处理策略、以及将所述第二类请求按照所述第二处理策略,分别发送至对应的目标服务器,包括:
根据将所述消息队列的回调请求按照所述轮询策略,发送至对应的第一类目标服务器;
将所述消息队列的非回调按照所述ip_hash策略,发送至对应的第二类目标服务器。
6.根据权利要求4所述的方法,其特征在于,在所述利用预设校验规则对所述用户请求进行校验,生成校验结果之前,还包括:
获取待添加的预设系统来源标志,以及所述预设系统来源标志携带的预设关键字;所述预设关键字为" flag=mq";
将携带所述预设关键字的预设系统来源标志,添加至所述第二类请求对应的cookie中,并从本地浏览器的存储空间中获得预设cookie校验规则;
将所述cookie校验规则发送至反向代理服务器,在所述反向代理服务器中增加所述cookie校验规则;所述反向代理服务器内的cookie校验规则用于对所述用户请求进行IP地址校验。
7.一种基于消息队列的负载均衡装置,应用于反向代理中间件,其特征在于,所述装置包括:
用户请求接收模块,用于接收与用户触发操作对应的用户请求;其中,不同触发操作对应不同触发操作类别,不同触发操作类别的触发操作分别对应不同请求类型的用户请求,不同请求类型的用户请求用于发送至不同的目标服务器进行处理;所述触发操作包括检索操作、修改操作和删除操作、当前页面展示操作、前进页面展示操作以及后退页面展示操作;
用户请求校验模块,用于利用设置在反向代理服务器中的预设校验规则对所述用户请求进行IP地址校验,判断所述用户请求是否携带包括预设关键字的系统来源标志,以生成校验结果;
请求类型判断模块,用于根据所述校验结果,判断所述用户请求对应的请求类型;所述请求类型包括携带系统来源标志的第一类请求、和不携带系统来源标志的第二类请求;所述第一类请求为消息队列的回调请求,所述第二类请求为除所述消息队列的回调请求之外的其他请求;
处理策略设置模块,用于根据所述请求类型设置对应的处理策略 ;所述处理策略包括与所述第一类请求对应的第一处理策略,以及与所述第二类请求对应的第二处理策略;所述第一处理策略为轮询策略,用于将用户的请求轮流分配给内部的服务器,从服务器1开始,直到服务器N,并不断重新循环;所述第二处理策略为ip_hash策略,用于根据请求客户端的IP计算出一个哈希值,再根据哈希值选择后台的目标服务器;其中,在选择下一个服务器时时,在上一次哈希值的基础上,再次哈希,得到更新后的哈希值,再根据更新后的哈希值选择另外一个目标服务器;
发送模块,用于将所述第一类请求按照所述第一处理策略、以及将所述第二类请求按照所述第二处理策略,分别发送至对应的目标服务器。
8.根据权利要求7所述的装置,其特征在于,所述用户请求校验模块,还用于:
获取预设校验规则;所述预设校验规则为cookie校验规则;
解析所述用户请求,获得所述用户请求携带的来源标志;
利用所述预设校验规则,对所述来源标志进行校验,生成校验结果。
9.一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,其特征在于,所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述方法的步骤。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910602952.3A CN110442447B (zh) | 2019-07-05 | 2019-07-05 | 基于消息队列的负载均衡方法、装置和计算机设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910602952.3A CN110442447B (zh) | 2019-07-05 | 2019-07-05 | 基于消息队列的负载均衡方法、装置和计算机设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110442447A CN110442447A (zh) | 2019-11-12 |
CN110442447B true CN110442447B (zh) | 2023-07-28 |
Family
ID=68429087
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910602952.3A Active CN110442447B (zh) | 2019-07-05 | 2019-07-05 | 基于消息队列的负载均衡方法、装置和计算机设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110442447B (zh) |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102404229A (zh) * | 2011-12-14 | 2012-04-04 | 华为技术有限公司 | 负载均衡系统、装置及方法 |
CN103945000A (zh) * | 2014-05-05 | 2014-07-23 | 安徽科大讯飞信息科技股份有限公司 | 一种负载均衡方法及负载均衡器 |
CN104753817A (zh) * | 2013-12-25 | 2015-07-01 | 中国移动通信集团公司 | 一种云计算消息队列服务本地模拟方法和系统 |
CN106790692A (zh) * | 2017-02-20 | 2017-05-31 | 郑州云海信息技术有限公司 | 一种多集群的负载均衡方法和装置 |
CN107844524A (zh) * | 2017-10-12 | 2018-03-27 | 金蝶软件(中国)有限公司 | 数据处理方法、数据处理装置、计算机设备和存储介质 |
CN108881430A (zh) * | 2018-06-14 | 2018-11-23 | 平安科技(深圳)有限公司 | 会话保持方法、装置、计算机设备及存储介质 |
CN109218355A (zh) * | 2017-06-30 | 2019-01-15 | 华为技术有限公司 | 负载均衡引擎,客户端,分布式计算系统以及负载均衡方法 |
CN109672711A (zh) * | 2017-10-17 | 2019-04-23 | 航天信息股份有限公司 | 一种基于反向代理服务器 Nginx 的http 请求处理方法及系统 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6728748B1 (en) * | 1998-12-01 | 2004-04-27 | Network Appliance, Inc. | Method and apparatus for policy based class of service and adaptive service level management within the context of an internet and intranet |
-
2019
- 2019-07-05 CN CN201910602952.3A patent/CN110442447B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102404229A (zh) * | 2011-12-14 | 2012-04-04 | 华为技术有限公司 | 负载均衡系统、装置及方法 |
CN104753817A (zh) * | 2013-12-25 | 2015-07-01 | 中国移动通信集团公司 | 一种云计算消息队列服务本地模拟方法和系统 |
CN103945000A (zh) * | 2014-05-05 | 2014-07-23 | 安徽科大讯飞信息科技股份有限公司 | 一种负载均衡方法及负载均衡器 |
CN106790692A (zh) * | 2017-02-20 | 2017-05-31 | 郑州云海信息技术有限公司 | 一种多集群的负载均衡方法和装置 |
CN109218355A (zh) * | 2017-06-30 | 2019-01-15 | 华为技术有限公司 | 负载均衡引擎,客户端,分布式计算系统以及负载均衡方法 |
CN107844524A (zh) * | 2017-10-12 | 2018-03-27 | 金蝶软件(中国)有限公司 | 数据处理方法、数据处理装置、计算机设备和存储介质 |
CN109672711A (zh) * | 2017-10-17 | 2019-04-23 | 航天信息股份有限公司 | 一种基于反向代理服务器 Nginx 的http 请求处理方法及系统 |
CN108881430A (zh) * | 2018-06-14 | 2018-11-23 | 平安科技(深圳)有限公司 | 会话保持方法、装置、计算机设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN110442447A (zh) | 2019-11-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109492019B (zh) | 业务请求响应方法、装置、计算机设备和存储介质 | |
CN108683668B (zh) | 内容分发网络中的资源校验方法、装置、存储介质及设备 | |
CN112099979B (zh) | 一种访问控制方法、装置、计算机设备和存储介质 | |
CN108965450B (zh) | 业务请求响应方法、装置、计算机设备和存储介质 | |
CN111260475A (zh) | 一种数据处理方法、区块链节点设备及存储介质 | |
CN111339057A (zh) | 减少回源请求的方法、装置及计算机可读存储介质 | |
CN114281263A (zh) | 容器集群管理系统的存储资源处理方法、系统和设备 | |
CN113342767A (zh) | 一种日志生成方法、装置、设备及存储介质 | |
CN113886496A (zh) | 区块链的数据同步方法、装置、计算机设备和存储介质 | |
CN114089921A (zh) | 电力系统数据存储方法、装置、计算机设备和存储介质 | |
CN111901383B (zh) | 数据请求处理方法、装置、计算机设备和存储介质 | |
CN115221156A (zh) | 数据库集群扩容方法、装置、计算机设备和存储介质 | |
CN110442447B (zh) | 基于消息队列的负载均衡方法、装置和计算机设备 | |
CN111949681A (zh) | 数据的聚合处理装置、方法和存储介质 | |
CN116661873A (zh) | 数据并行处理方法、装置、计算机设备及存储介质 | |
CN111124932B (zh) | 方案验证方法、系统、装置、计算机设备和存储介质 | |
CN114238264A (zh) | 数据处理方法、装置、计算机设备和存储介质 | |
CN111552551A (zh) | 基于主从系统的用户管理方法、装置、计算机设备和介质 | |
CN113821495A (zh) | 数据库集群实现系统及方法 | |
CN111144771A (zh) | 确定风评策略的方法、装置及计算机存储介质 | |
CN112084827B (zh) | 数据处理方法及装置 | |
CN115604041B (zh) | 安全代理方法、系统、装置、计算机设备和存储介质 | |
CN114422594B (zh) | 业务处理方法、装置、计算机设备和存储介质 | |
CN115455914A (zh) | 工单处理方法、装置、计算机设备和存储介质 | |
CN118540094A (zh) | 业务访问方法、装置、计算机设备、介质和产品 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |