业务请求处理方法和装置的制造方法
【专利摘要】本公开实施例公开了一种业务请求处理方法和装置。该业务请求处理方法包括：获取业务请求；将所述业务请求存储在业务队列中；确定服务器组内处理所述业务请求的至少一个可用服务器；将所述业务队列中的业务请求分发给所述至少一个可用服务器。采用该业务请求处理方法可以保证服务器不崩溃。
【专利说明】
业务请求处理方法和装置
技术领域
[0001 ]本公开涉及数据处理技术，尤其涉及一种业务请求处理方法和装置。
【背景技术】
[0002]现有技术中，可能存在短时间内访问量过大造成服务器崩溃的情况。
[0003]例如，在某一节目直播时，大量用户通过网络观看这一直播，致使服务器的访问量过大，而服务器无法处理造成服务器崩溃。或者，在某些电商的促销日，用户集中在某一时间段进行抢购，造成电商的服务器在该时间段内业务请求剧增，致使服务器在短时间内访问量过大，而服务器无法处理造成服务器崩溃。
[0004]为了应对上述情况，网络服务提供者如电商会设置更大容量的服务器或者更多的服务器，以应对来自客户端的大量业务请求。这样做存在的不足是，一方面会增加成本，而且在业务请求量降低之后又造成资源浪费。另一方面，仍然存在着业务请求量超过服务器的处理能力的情况，仍然会造成服务器的崩溃。
【发明内容】
[0005]本公开实施例可能的目的是:提供一种业务请求处理方法，包括:获取业务请求；将业务请求存储在业务队列中；确定服务器组内处理业务请求的至少一个可用服务器;将业务队列中的业务请求分发给至少一个可用服务器。
[0006]优选地，确定服务器组内具有负载能力的服务器的步骤包括:轮询服务器组内的服务器，根据轮询结果确定处理业务请求的至少一个可用服务器。
[0007]优选地，轮询服务器组内的服务器，根据轮询结果确定处理业务请求的至少一个可用服务器的步骤包括:读取询问控制表，其中，询问控制表中保存有对服务器组内的服务器进行轮询的询问顺序的信息;根据询问顺序的信息，轮询服务器组内的服务器，并根据轮询结果确定处理业务请求的至少一个可用服务器。
[0008]优选地，方法还包括:若服务器组内不存在处理业务请求的可用服务器，则将业务请求继续存储在业务队列中。
[0009]优选地，在将业务请求存储在业务队列中的步骤之后，方法还包括:接收业务取消请求;根据业务取消请求将业务队列中对应的业务请求删除。
[0010]另一方面，本公开的一可能的实施方案提供了一种业务请求处理装置，包括:获取模块，用于获取业务请求;队列管理模块，用于将业务请求存储在业务队列中；确定模块，用于确定服务器组内处理业务请求的至少一个可用服务器;分发模块，用于将业务队列中的业务请求分发给至少一个可用服务器。
[0011]优选地，确定模块包括:轮询模块，用于轮询服务器组内的服务器，根据轮询结果确定处理业务请求的至少一个可用服务器。
[0012]优选地，轮询模块包括:控制表读取模块，用于读取询问控制表，其中，询问控制表中保存有对服务器组内的服务器进行轮询的询问顺序的信息；询问模块，用于根据询问顺序的信息，轮询服务器组内的服务器，并根据轮询结果确定处理业务请求的至少一个可用服务器。
[0013]优选地，装置还包括:继续存储模块，用于在服务器组内不存在处理业务请求的可用服务器的情况下，将业务请求继续存储在业务队列中。
[0014]优选地，装置还包括:取消接收模块，用于在将业务请求存储在业务队列中之后，接收业务取消请求;删除模块，用于根据业务取消请求将业务队列中对应的业务请求删除。
[0015]本公开实施例的至少一个实施方案，在接收到业务请求后将其存储在业务队列中，根据服务器组内的服务器的负载情况分配业务请求，将业务请求分配给负载未满的服务器，即可用服务器，确保服务器不过载，而且能够均衡负载。
【附图说明】
[0016]图1为本公开实施例一的业务请求处理方法的流程图；
[0017]图2为本公开实施例二的业务请求处理方法的流程图；
[0018]图3为本公开实施例三的业务请求处理装置的结构示意图；
[0019]图4为本公开实施例四的业务请求处理装置的结构示意图；
[0020]图5为本公开实施例五的用户设备的结构示意图。
【具体实施方式】
[0021]下面结合附图(若干附图中相同的标号表示相同的元素)和实施例，对本公开的【具体实施方式】作进一步详细说明。以下实施例用于说明本公开，但不用来限制本公开的范围。
[0022]本领域技术人员可以理解，本公开中的“第一”、“第二”等术语仅用于区别不同步骤、设备或模块等，既不代表任何特定技术含义，也不表示它们之间的必然逻辑顺序。
[0023]实施例一
[0024]图1示出了本公开实施例一的业务请求处理方法的流程图。
[0025]参照图1，在本实施例中，该业务请求处理方法可以在负载均衡控制器上运行实现。该负载均衡控制器可以独立设置在一个设备(如计算机)上，该设备独立于服务器组。在其他实施例中，业务请求处理方法可以在服务器或其他设备上运行实现。
[0026]本实施例的业务请求处理方法包括以下步骤:
[0027]步骤SI 10:获取业务请求。
[0028]用户在操作终端设备时，根据用户的操作(包括但不限于对“购买”按钮的点击、对“付款”按钮的点击)生成业务请求(如下订单、付款等)，终端设备上的客户端或网页应用生成该业务请求，并将该业务请求发送给负载均衡控制器，负载均衡控制器获取到业务请求。
[0029]步骤S120:将业务请求存储在业务队列中。
[0030]获取业务请求后，负载均衡控制器将业务请求存储在业务队列中，以便后续对业务请求进行分配。其中，业务队列是一种线性表，该业务队列允许在表的前端(front)进行删除操作，而在表的后端(rear)进行插入操作。通过使用业务队列存储业务请求，一方面可以使得业务请求可以按照顺序得到处理，另一方面，也有效避免了任务拥堵。
[0031]步骤S130:确定服务器组内处理业务请求的至少一个可用服务器。
[0032]为了保证服务器组内的服务器不会由于负载过重而导致崩溃，负载均衡控制器在服务器组内选择可用的服务器进行业务请求分配。这里的可用服务器是指，能够处理对应类型的业务请求，且尚未满负载运行。
[0033]步骤S140:将业务队列中的业务请求分发给至少一个可用服务器。
[0034]负载均衡控制器在确定可用服务器后，将业务队列中的业务请求分发给可用服务器进行处理。其进行业务请求分发时，可以依照业务队列中的顺序将业务请求一个一个地发送给可用服务器，也可以一次将多个(两个及两个以上)业务请求分别发送给一个或至少两个可用服务器。
[0035]本实施例的业务请求处理方法，通过负载均衡控制器获取业务请求，并将业务请求存储在业务队列中，再将业务请求分发给可用服务器，确保服务器不会过载，能够有效地防止服务器崩溃。
[0036]实施例二
[0037]图2为本公开实施例二的业务请求处理方法的流程图。
[0038]本实施例以使用负载均衡控制器进行业务请求处理为例，对本公开的业务请求处理方法进行说明。负载均衡控制器集成在服务器上，该服务器可以为一个独立的服务器，也可以是服务器组内的任一服务器。但本领域技术人员应当明了，其他的终端设备也可参照本实施例实现本公开的内容获取方案。参照图2，本实施例的业务请求处理方法包括以下步骤:
[0039]步骤S210:获取业务请求。
[0040]用户在操作终端设备时，根据用户的操作(包括但不限于对“购买”按钮的点击、对“付款”按钮的点击)生成业务请求(如下订单、付款等)，终端设备上的客户端或网页应用生成该业务请求，并将该业务请求发送给负载均衡控制器，负载均衡控制器获取到业务请求。[0041 ] 步骤S220:将业务请求存储在业务队列中。
[0042]获取业务请求后，负载均衡控制器将业务请求存储在业务队列中，以便后续对业务请求进行分配。需要说明的是，负载均衡控制器接收到的业务请求后，根据业务请求的类型将其存储在不同业务类型的业务队列中。例如，接收到的业务请求为订单类业务，则将其存储在订单类业务的业务队列中。接收到的业务请求为付款类业务时，将其存储在付款类业务的业务队列中。
[0043]此外，不同业务类型的业务请求可以对应不同的业务处理服务器。
[0044]步骤S230:接收业务取消请求。
[0045]用户在点击购买按钮或付款按钮后，其可能点击取消按钮，取消之前的购买操作或付款操作，此时，客户端或网页会生成一个业务取消请求。负载均衡控制器可以从客户端或网页接收到该业务取消请求。
[0046]需要说明的是，如果用户在客户端或网页上进行了重新购买或重新付款等操作，也会生产业务取消请求，将之前存在的业务请求取消，同时会再生成一个新的业务请求。
[0047]步骤S240:根据业务取消请求将业务队列中对应的业务请求删除。
[0048]负载均衡控制器接收到业务取消请求后，将业务队列中对应的业务请求删除。
[0049]需要说明的是，步骤S230和步骤S240并非必须步骤，也即若用户未进行取消操作，则不进行此步骤。
[0050]步骤S250:确定服务器组内处理业务请求的至少一个可用服务器。
[0051]为了保证服务器组内的服务器不会由于负载过重而导致崩溃，负载均衡控制器在服务器组内选择可用的服务器进行业务请求分配。这里的可用服务器是指，能够处理对应类型的业务请求，且尚未满负载运行。
[0052]在本实施例中，可以采用轮询的方式确定可用服务器，S卩，轮询服务器组内的服务器，根据轮询结果确定处理业务请求的至少一个可用服务器。但不限于此，在实际应用中，也可以采用其他适当方式确定可用服务器，如通过并发消息的方式确定可用服务器，或者通过其他适当方式确定。
[0053]当采用轮询方式确定可用服务器时，本步骤可以包括如下子步骤:
[0054]步骤S2501:读取询问控制表，其中，询问控制表中保存有对服务器组内的服务器进行轮询的询问顺序的信息。
[0055]询问顺序的信息可以根据服务器组内的服务器的QPS(每秒查询量)确定。如，QPS高的服务器在询问控制表的位置靠前。
[0056]步骤S2502:根据询问顺序的信息，轮询服务器组内的服务器，并根据轮询结果确定处理业务请求的至少一个可用服务器。
[0057]进行轮询时，先向询问控制表第一位的服务器发送询问消息，根据服务器返回的响应消息确定服务器能否处理该业务请求并且该服务器是否满负载，若该服务器满负载，则向下一位服务器发送询问消息，直至找到未满负载且能处理该业务请求的可用服务器，或遍历服务器组内的所有服务器。
[0058]在本实施例中，满负载是指服务器的QPS已满，未满负载是指服务器的QPS未满。在其他实施例中，满负载可以根据其他参数确定，例如处理的业务请求数等。
[0059]若在服务器组内确定可用服务器，则执行步骤S260，若遍历服务器组内的服务器仍未找到可用服务器，则执行步骤S270。
[0060]步骤S260:将业务队列中的业务请求分发给至少一个可用服务器。
[0061]负载均衡控制器在确定可用服务器后，将业务队列中的业务请求分发给可用服务器进行处理。其进行业务请求分发时，可以依照业务队列中的顺序将业务请求一个一个地发送给可用服务器，也可以一次将多个(两个或两个以上)业务请求分别发送给一个或至少两个可用服务器。
[0062]在进行轮询时，负载均衡控制器找到一个可用服务器后，将业务队列中的第一个业务请求发送给找到的可用服务器，并将该业务请求从业务队列中删除。
[0063]若采用并发的形式确定可用服务器，则可以一次确定多个可用服务器，并将业务队列中的前N个(N的数量与可用服务器的数量一致)一一对应地分发给可用服务器。
[0064]步骤S270:若服务器组内不存在处理业务请求的可用服务器，则将业务请求继续存储在业务队列中。
[0065]若在服务器组内找不到可用服务器，则将业务请求继续存储在业务队列中，这样可以保证服务器不过载。
[0066]本实施例的业务请求处理方法，通过负载均衡控制器获取业务请求，并将业务请求存储在业务队列中，再将业务请求分发给可用服务器，确保服务器不会过载，能够有效地防止服务器崩溃。负载均衡控制器仅接收业务请求，并将业务请求放入业务队列，而不进行业务处理，从而保证负载均衡控制器不会崩溃。在业务请求暂时无法得到处理时，负载均衡控制器将服务器无法处理的业务请求继续存储，既可以使服务器不发生崩溃，也可以应对突发大业务请求的情况，还能保证服务器在应对了大业务请求之后还可以正常运行。
[0067]实施例三
[0068]图3为本公开实施例三的业务请求处理装置的结构示意图。
[0069]参照图3，本实施例的业务请求处理装置包括:获取模块310，用于获取业务请求；队列管理模块320，用于将业务请求存储在业务队列中；确定模块330，用于确定服务器组内处理业务请求的至少一个可用服务器;分发模块340，用于将业务队列中的业务请求分发给至少一个可用服务器。
[0070]本实施例的业务请求处理装置可以以任意适当的方式实现，设置于服务器中，用于实现前述实施例中相应的业务请求处理方法。或者，在服务器外单独设置一设备，该设备包括负载均衡控制器。
[0071]通过本实施例，在接收到业务请求后，将业务请求存储在业务队列中，根据服务器组内的服务器的负载情况分配业务请求，使得服务器组内的服务器的负载均衡，防止服务器负载过重崩溃。
[0072]实施例四
[0073]图4为本公开实施例四的业务请求处理装置的结构示意图。
[0074]参照图4，本实施例的业务请求处理装置包括:获取模块410，用于获取业务请求；队列管理模块420，用于将业务请求存储在业务队列中；确定模块，用于确定服务器组内处理业务请求的至少一个可用服务器;分发模块440，用于将业务队列中的业务请求分发给至少一个可用服务器。
[0075]优选地，确定模块包括轮询模块，用于轮询服务器组内的服务器，根据轮询结果确定处理业务请求的至少一个可用服务器。
[0076]优选地，轮询模块包括:控制表读取模块4301，用于读取询问控制表，其中，询问控制表中保存有对服务器组内的服务器进行轮询的询问顺序的信息；询问模块4302，用于根据询问顺序的信息，轮询服务器组内的服务器，并根据轮询结果确定处理业务请求的至少一个可用服务器。
[0077]优选地，装置还包括:继续存储模块450，用于在服务器组内不存在处理业务请求的可用服务器的情况下，将业务请求继续存储在业务队列中。
[0078]优选地，装置还包括:取消接收模块460，用于在将业务请求存储在业务队列中之后，接收业务取消请求;删除模块470，用于根据业务取消请求将业务队列中对应的业务请求删除。
[0079]本实施例的业务请求处理装置用于实现前述多个方法实施例中相应的业务请求处理方法，并具有相应的方法实施例的有益效果，在此不再赘述。
[0080]实施例五
[0081]图5为本公开实施例提供的一种用户设备的结构示意图，本公开具体实施例并不对用户设备的具体实现做限定。该用户设备可以包括:
[0082]处理器(processor)510、通信接口(Communicat1nsInterface)520、存储器(memory)530、以及通信总线540。其中:
[0083]处理器510、通信接口 520、以及存储器530通过通信总线540完成相互间的通信。
[0084]通信接口520，用于与比如客户端等的网元通信。
[0085]处理器510，用于执行程序532，具体可以执行上述方法实施例中的相关步骤。
[0086]具体地，程序532可以包括程序代码，程序代码包括计算机操作指令。
[0087]处理器510可能是一个中央处理器CPU，或者是特定集成电路ASIC(Applicati0nSpecific Integrated Circuit)，或者是被配置成实施本公开实施例的一个或多个集成电路。
[0088]存储器530，用于存放程序532。存储器530可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。程序532具体可以用于使得处理器510执行以下操作:
[0089]获取业务请求;将业务请求存储在业务队列中；确定服务器组内处理业务请求的至少一个可用服务器;将业务队列中的业务请求分发给至少一个可用服务器。
[0090]在一种可选地实施例中，程序532还用于使得处理器510轮询服务器组内的服务器，根据轮询结果确定处理业务请求的至少一个可用服务器。
[0091]在一种可选地实施例中，程序532还用于使得处理器510读取询问控制表，其中，询问控制表中保存有对服务器组内的服务器进行轮询的询问顺序的信息;根据询问顺序的信息，轮询服务器组内的服务器，并根据轮询结果确定处理业务请求的至少一个可用服务器。
[0092]在一种可选地实施例中，程序532还用于使得处理器510在服务器组内不存在处理业务请求的可用服务器的情况下，则将业务请求继续存储在业务队列中。
[0093]在一种可选地实施例中，程序532还用于使得处理器510在将业务请求存储在业务队列中之后，接收业务取消请求;根据业务取消请求将业务队列中对应的业务请求删除。
[0094]程序532中各步骤的具体实现可以参见上述实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。
[0095]本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。
[0096]所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(R0M，Read-0nly Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
[0097]以上实施方式仅用于说明本公开，而并非对本公开的限制，有关技术领域的普通技术人员，在不脱离本公开的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本公开的范畴，本公开的专利保护范围应由权利要求限定。
【主权项】
1.一种业务请求处理方法，包括: 获取业务请求； 将所述业务请求存储在业务队列中； 确定服务器组内处理所述业务请求的至少一个可用服务器； 将所述业务队列中的业务请求分发给所述至少一个可用服务器。2.根据权利要求1所述的方法，其中，所述确定服务器组内具有负载能力的服务器的步骤包括: 轮询服务器组内的服务器，根据轮询结果确定处理所述业务请求的至少一个可用服务器。3.根据权利要求2所述的方法，其中，所述轮询服务器组内的服务器，根据轮询结果确定处理所述业务请求的至少一个可用服务器的步骤包括: 读取询问控制表，其中，所述询问控制表中保存有对所述服务器组内的服务器进行轮询的询问顺序的信息； 根据所述询问顺序的信息，轮询服务器组内的服务器，并根据轮询结果确定处理所述业务请求的至少一个可用服务器。4.根据权利要求2所述的方法，其中，所述方法还包括: 若服务器组内不存在处理所述业务请求的可用服务器，则将所述业务请求继续存储在所述业务队列中。5.根据权利要求1所述的方法，其中，在将所述业务请求存储在业务队列中的步骤之后，所述方法还包括: 接收业务取消请求； 根据所述业务取消请求将所述业务队列中对应的业务请求删除。6.一种业务请求处理装置，包括: 获取模块，用于获取业务请求； 队列管理模块，用于将所述业务请求存储在业务队列中； 确定模块，用于确定服务器组内处理所述业务请求的至少一个可用服务器； 分发模块，用于将所述业务队列中的业务请求分发给所述至少一个可用服务器。7.根据权利要求6所述的装置，其中，所述确定模块包括: 轮询模块，用于轮询服务器组内的服务器，根据轮询结果确定处理所述业务请求的至少一个可用服务器。8.根据权利要求7所述的装置，其中，所述轮询模块包括: 控制表读取模块，用于读取询问控制表，其中，所述询问控制表中保存有对所述服务器组内的服务器进行轮询的询问顺序的信息； 询问模块，用于根据所述询问顺序的信息，轮询服务器组内的服务器，并根据轮询结果确定处理所述业务请求的至少一个可用服务器。9.根据权利要求7所述的装置，其中，所述装置还包括: 继续存储模块，用于在服务器组内不存在处理所述业务请求的可用服务器的情况下，将所述业务请求继续存储在所述业务队列中。10.根据权利要求6所述的装置，其中，所述装置还包括:取消接收模块，用于在将所述业务请求存储在业务队列中之后，接收业务取消请求；删除模块，用于根据所述业务取消请求将所述业务队列中对应的业务请求删除。
【文档编号】H04L29/08GK105847425SQ201610326268
【公开日】2016年8月10日
【申请日】2016年5月17日
【发明人】李洪福
【申请人】乐视控股（北京）有限公司, 乐视云计算有限公司