CN111756789A - 请求信息的分发方法、装置、存储介质和电子设备 - Google Patents

Abstract

本申请的实施例提供了一种请求信息的分发方法、装置、存储介质和电子设备，涉及通信技术领域。该方法包括：获取客户端发送的请求信息中的请求资源字段；请求资源字段表征请求信息所请求的有状态资源；从至少一个服务器中确定出管理该有状态资源的服务器；将该请求信息发送至服务器。由于所获取的请求资源字段表征该请求信息所请求的有状态资源，故而根据该请求资源字段可以从至少一个服务器中确定出管理该有状态资源的服务器，并将该请求信息发送至同一管理该有状态资源的服务器，进而实现了将请求信息正确分发至服务器，避免在公共存储区域进行大量读写，以及避免使用全局加锁处理技术，提高了设备运行效率，减小了开发难度。

Description

请求信息的分发方法、装置、存储介质和电子设备

技术领域

本申请涉及通信技术领域，具体而言，涉及一种请求信息的分发方法、装置、存储介质和电子设备。

背景技术

随着互联网技术的发展，互联网公司能够为用户提供各种各样的业务服务(例如，提供计算服务、存储服务等)，用户可以通过网络向互联网公司的服务器发送请求信息以请求相应的业务服务。

现有的服务器在获取到用户发送的请求信息时，通常会通过负载均衡技术将请求信息发送至后端服务器，由后端服务器提供相应的资源给该用户，从而实现为用户提供业务服务。

但是，目前有些业务所请求的资源是有状态的，现有技术为了实现将请求有状态资源的请求信息正确分发至后端服务器，需要在公共存储区域进行大量读写，并且需要使用全局加锁处理技术，这使得设备运行效率低下，且增加了开发难度。

发明内容

本申请的目的包括，例如，提供了一种请求信息的分发方法、装置、存储介质和电子设备，其能够实现将请求有状态资源的请求信息正确分发至服务器，且避免在公共存储区域进行大量读写，以及避免使用全局加锁处理技术，提高了设备运行效率，减小了开发难度。

本申请的实施例可以这样实现：

第一方面，实施例提供一种请求信息的分发方法，包括：获取客户端发送的请求信息中的请求资源字段；所述请求资源字段表征所述请求信息所请求的有状态资源；从至少一个服务器中确定出管理所述有状态资源的服务器；将所述请求信息发送至所述服务器。

在可选的实施方式中，从至少一个服务器中确定出管理所述有状态资源的服务器的步骤包括：根据所述请求资源字段以及预设的关系表确定出管理所述有状态资源的服务器；所述关系表包括多个服务器与多个有状态资源的对应关系。

在可选的实施方式中，根据所述请求资源字段以及预设的关系表确定出管理所述有状态资源的服务器的步骤包括：根据预设规则确定与所述请求资源字段对应的分发ID；其中，相同的请求资源字段对应相同的分发ID；根据所述分发ID以及预先维护的对应关系表确定出管理所述有状态资源的服务器；所述对应关系表包括多个服务器与多个有状态资源的对应关系。

在可选的实施方式中，所述方法还包括：在获取到待处理分发ID时，根据所述待处理分发ID对应的有状态资源在所述对应关系表中记录所述待处理分发ID与目标服务器的对应关系，并记录所述待处理分发ID与目标服务器的对应关系的记录时间；所述目标服务器管理所述待处理分发ID对应的有状态资源；当所述记录时间与当前时间之间的时间间隔超过预设时长时，在所述对应关系表中删除所述待处理分发ID与目标服务器的对应关系。

在可选的实施方式中，在获取到所述分发ID后，根据如下公式确定出管理所述有状态资源的服务器：K＝ID％N；其中，N为所述至少一个服务器的个数，管理所述有状态资源的服务器为所述至少一个服务器中的第K个服务器，ID为所述分发ID，％表示取模运算。

在可选的实施方式中，根据预设规则计算所述请求资源字段，得到分发ID的步骤包括：计算所述请求资源字段的哈希值，并将所述哈希值作为所述分发ID。

在可选的实施方式中，所述方法还包括：将所述至少一个服务器管理的有状态资源的数据均存储至公共存储空间。

第二方面，实施例提供一种请求信息的分发装置，包括：获取模块，用于获取客户端发送的请求信息中的请求资源字段；所述请求资源字段表征所述请求信息所请求的有状态资源；确定模块，用于从至少一个服务器中确定出管理所述有状态资源的服务器；发送模块，用于将所述请求信息发送至所述服务器。

在可选的实施方式中，所述确定模块用于根据所述请求资源字段以及预设的关系表确定出管理所述有状态资源的服务器；所述关系表包括多个服务器与多个有状态资源的对应关系。

在可选的实施方式中，所述确定模块用于根据预设规则确定与所述请求资源字段对应的分发ID；其中，相同的请求资源字段对应相同的分发ID；所述确定模块还用于根据所述分发ID以及预先维护的对应关系表确定出管理所述有状态资源的服务器；所述对应关系表包括多个服务器与多个有状态资源的对应关系。

在可选的实施方式中，所述确定模块用于在获取到待处理分发ID时，根据所述待处理分发ID对应的有状态资源在所述对应关系表中记录所述待处理分发ID与目标服务器的对应关系，并记录所述待处理分发ID与目标服务器的对应关系的记录时间；所述目标服务器管理所述待处理分发ID对应的有状态资源；所述确定模块还用于当所述记录时间与当前时间之间的时间间隔超过预设时长时，在所述对应关系表中删除所述待处理分发ID与目标服务器的对应关系。

在可选的实施方式中，在获取到所述分发ID后，所述确定模块用于根据如下公式确定出管理所述有状态资源的服务器：K＝ID％N；其中，N为所述至少一个服务器的个数，管理所述有状态资源的服务器为所述至少一个服务器中的第K个服务器，ID为所述分发ID，％表示取模运算。

在可选的实施方式中，所述确定模块用于计算所述请求资源字段的哈希值，并将所述哈希值作为所述分发ID。

在可选的实施方式中，所述发送模块用于将所述至少一个服务器管理的有状态资源的数据均存储至公共存储空间。

第三方面，实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如前述实施方式中任一项所述的请求信息的分发方法。

第四方面，实施例提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当所述电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述处理器执行所述机器可读指令，以执行如前述实施方式中任一项所述的请求信息的分发方法。

本申请实施例的有益效果包括，例如：由于所获取的请求资源字段表征该请求信息所请求的有状态资源，故而根据该请求资源字段可以从至少一个服务器中确定出管理该有状态资源的服务器，并将该请求信息发送至同一管理该有状态资源的服务器，进而实现了将请求信息正确分发至服务器，避免在公共存储区域进行大量读写，以及避免使用全局加锁处理技术，提高了设备运行效率，减小了开发难度。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例所提供的电子设备的一种结构框图；

图2为本申请实施例所提供的电子设备的应用场景示意图；

图3为本申请实施例提供的请求信息的分发方法的一种流程图；

图4为本申请实施例提供的请求信息的分发方法的另一种流程图；

图5为本申请实施例提供的请求信息的分发方法的另一种流程图；

图6为本申请实施例提供的请求信息的分发方法的另一种流程图；

图7为本申请实施例提供的请求信息的分发方法的另一种流程图；

图8为本申请实施例提供的请求信息的分发装置的一种功能模块图。

图标：100-电子设备；110-存储器；120-处理器；130-总线；140-通信接口；200-服务器；300-客户端；400-请求信息的分发装置；410-获取模块；420-确定模块；430-发送模块。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

此外，若出现术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

需要说明的是，在不冲突的情况下，本申请的实施例中的特征可以相互结合。

在实现本申请实施例的技术方案的过程中，本申请发明人发现：

客户端(即用户)可以向服务器发送请求信息或任务信息(任务信息是请求信息的子集)以请求相应的资源，使用相应的业务服务，这些请求信息所请求的资源通常可以分为无状态资源和有状态资源。对于请求无状态资源的请求信息，这些请求信息在对同一个无状态资源进行请求时，不同请求信息之间并无状态的关联性，对于这些请求无状态资源的请求信息，现有的服务器可以通过负载均衡技术将这些信息分发至后端服务器，并实现服务的快速伸缩，比如网站的负载均衡、TCP/UDP服务端的负载均衡。

对于请求有状态资源的请求信息，这些请求信息在对同一个有状态资源(也可以理解为被操作对象)进行请求时，不同请求信息之间存在状态的关联性。例如，设备A发送心跳包至服务器，服务器上的资源A与设备A对应，业务/任务A会根据心跳的间隔时间产生不同的状态，该状态反映在资源A(该资源A即为有状态资源)上。如当心跳间隔超过3秒时，资源A的状态为欠佳；心跳间隔超过10秒时，资源A的状态为离线，故而请求信息在请求资源A时，由于资源A在不同时刻的状态不同，故而请求信息在不同时刻，其包括的信息会出现不同。又如，银行账户、积分一类的交易(特别是非实体卡)也是典型的有状态资源，进行额度加减时，不可出现并发(如多部手机同时支付)，比如两笔支出必须先后出现，不能同时在原有额度上减去后更新到数据库。

此外，请求有状态资源的请求信息还可以是包括有用于支付使用的URL数据的HTTP请求，客户端在向服务器发送请求同一资源的不同HTTP请求时，这些HTTP请求中的数据可能会出现非关键信息变动，若此时依旧将这些请求当做无状态请求信息处理，则可能被转发到不同的后端服务器上，不能实现将请求同一资源的不同请求信息发送至同一管理该资源的后端服务器上的目的。

目前的技术可以将请求信息均匀的或按比例分发到后端服务器，后端服务器上也常常会使用缓存技术将被请求的资源进行缓存，以避免频繁读写公共存储区域来操作相应的资源。但是，目前技术有两个局限：

1.请求信息到达后端服务器是随机的，由于请求信息到达后端服务器的随机性，任一资源都有可能被任一后端服务器缓存，并且需要多个服务器与公共存储进行数据同步；

2.当被请求资源是有状态时，即这一次请求(对资源的操作)与上一次请求的结果有关时，由于可能多个后端服务器都会访问这个资源，因此可能需要放弃缓存方案，每一次都访问公共存储，并对主存储上的资源进行加锁以避免冲突；或者采用更复杂的方案来保证每个服务端读写的资源都是最新的状态。

如前所述，现有的服务器为了将这些请求有状态资源的请求信息发送到正确的后端服务器上(即为了解决上述问题，实现将请求同一有状态资源的不同请求信息发送至同一管理该有状态资源的后端服务器上的目的)，需要实时地将所有后端服务器管理的有状态资源的数据存储到一个公共存储区域，这会增大服务器的数据访问量(即需要在公共存储区域进行大量读写)，影响设备的运行效率，并且由于请求信息的访问并发性，还需要采用全局加锁处理技术以避免不同并发的请求信息使用到脏数据，这增加了开发的难度。

因此，如何实现将请求同一有状态资源的不同请求信息发送至同一管理该有状态资源的后端服务器成为目前亟待解决的技术问题。

为了改善上述缺陷，本申请实施例提出一种请求信息的分发方法、装置、存储介质和电子设备，其能够实现将请求有状态资源的请求信息正确分发至服务器，且避免在公共存储区域进行大量读写，以及避免使用全局加锁处理技术，提高了设备运行效率，减小了开发难度。需要说明的是，以上现有技术中的方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本申请实施例针对上述问题所提出的解决方案，都应该是发明人在本申请过程中对本申请做出的贡献。

请参照图1，为本申请实施例所提供的电子设备100的一种结构框图。该电子设备100可以包括存储器110、处理器120、总线130和通信接口140，该存储器110、处理器120和通信接口140相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条总线130或信号线实现电性连接。处理器120可以处理与请求信息的分发有关的信息和/或数据，以执行本申请中描述的一个或多个功能。例如，处理器120可以获取客户端发送的请求信息中的请求资源字段，并根据上述数据进行请求信息的分发，进而实现本申请提供的请求信息的分发方法。

存储器110可以是但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-Only Memory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。

处理器120可以是一种集成电路芯片，具有信号处理能力。该处理器120可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(NetworkProcessor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

可以理解，图1所示的结构仅为示意，该电子设备100还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。图1中所示的各组件可以采用硬件、软件或其组合实现。在实际应用中，该电子设备100可以是服务器、负载均衡设备、交换机等电子设备，因此本申请实施例对电子设备100的种类不做限制。

在图1的基础上，本申请实施例还提供一种电子设备100的应用场景，请参照图2，电子设备100可以与至少一个服务器200通信连接，并且该电子设备100还可以与至少一个客户端300通信连接。该电子设备100可以通过网络获取客户端300发送的请求信息，并将获取的请求信息发送至服务器200以便服务器200提供相应的资源给该用户，从而实现为用户提供计算、存储、查询等业务服务。

在一些可能的实施方式中，假设该电子设备100为负载均衡设备，该负载均衡设备可以与多个后端服务器通信连接(该后端服务器可以理解为上述的服务器200)，这些后端服务器的存储介质中可以存储有多个有状态资源和多个无状态资源，并且，在这些后端服务器中还设置有一公共存储区域，该公共存储区域中也可以存储有多个有状态资源和多个无状态资源。当电子设备100通过网络获取到客户端300发送的请求有状态资源的请求信息时，其可以根据该请求信息中的请求资源字段确定该请求信息所请求的有状态资源，然后确定出管理该有状态资源的服务器，最后将该请求信息发送至该服务器，进而实现将请求有状态资源的请求信息正确分发至服务器的目的。其中，可以理解的是，当客户端300发送的请求信息所请求的有状态资源位于公共存储区域时，负载均衡设备可以先将该请求信息发送至任一后端服务器，然后由该后端服务器从公共存储区域中获取到该请求信息请求的有状态资源，进而实现将请求有状态资源的请求信息正确分发至服务器的目的。

可以理解的是，在实际应用中，该客户端300可以是服务器、手机、平板电脑、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、手持计算机、上网本、个人数字助理(personal digital assistant，PDA)、可穿戴电子设备、虚拟现实设备等设备，本申请对此不做限定。

为了便于理解，本申请以下实施例将以图1所示的电子设备100以及图2所示的应用环境为例，结合附图，对本申请实施例提供的请求信息的分发方法进行具体阐述。

请参照图3，图3示出了本申请实施例提供的请求信息的分发方法的一种流程图。该请求信息的分发方法可以应用于上述的电子设备100，该请求信息的分发方法可以包括以下步骤：

S100，获取客户端发送的请求信息中的请求资源字段；请求资源字段表征请求信息所请求的有状态资源。

在一些可能的实施例中，上述的请求信息可以包括但不限于：B/S架构(Browser/Server，浏览器和服务器结构)或C/S架构(Client/Server，客户端和服务器结构)的客户端请求，例如，HTTP(超文本传输协议，Hyper Text Transfer Protocol)请求/HTTPS(超文本传输安全协议，Hyper Text Transfer Protocol over SecureSocket Layer)请求、TCP(传输控制协议，Transmission Control Protocol)请求、UDP(用户数据报协议，UserDatagram Protocol)请求等请求信息。另外，上述的请求信息还可以是中间件，例如，消息队列，REDIS中的队列等。

以HTTP请求信息为例，例如HTTP请求信息的QueryString中可包含device_id字段用于表征所请求的有状态资源，因此可以获取HTTP请求信息中的device_id字段作为请求资源字段。QueryString只作为例子的一个请求有状态资源的请求信息的来源，类似的还可以有url和body的数据。

可以理解的是，由于客户端在发送请求信息时，为了获取到所请求的有状态资源，其总会在该请求信息中设置直接或间接的请求资源字段，因此对于客户端发送的不同种类的请求信息，总能获取到该请求信息中的请求资源字段。

S110，从至少一个服务器中确定出管理有状态资源的服务器。

在一些可能的实施例中，电子设备100可以与至少一个服务器通信连接(参照图2)，并且该至少一个服务器可以管理有多个资源，包括有状态资源和无状态资源。在获取到请求资源字段时，电子设备可以根据该请求资源字段所请求的有状态资源从至少一个服务器中确定出管理该有状态资源的服务器。

继续以HTTP请求信息为例，假设该请求信息的device_id字段表征请求资源A，并且电子设备100与服务器1、服务器2、服务器3通信连接，其中，服务器1管理有资源A、资源B，服务器2管理有资源C，服务器3管理有资源D，则电子设备100可以确定出服务器1位管理资源A的服务器。

应理解，由于所获取的请求资源字段表征该请求信息所请求的有状态资源，故而根据该请求资源字段可以实现从至少一个服务器中确定出管理该有状态资源的服务器。

S120，将请求信息发送至服务器。

在确定出管理该有状态资源的服务器后，电子设备100可以将获取的请求信息发送至该服务器，以便该服务器将相应的有状态资源反馈给客户端，从而实现为用户提供计算、存储、查询等业务服务。

应理解，使用现有的负载均衡技术来进行后端服务器的扩容，所有的请求压力都将集中在公共存储区域。而在本申请中，由于所获取的请求资源字段表征该请求信息所请求的有状态资源，故而根据该请求资源字段可以从至少一个服务器中确定出管理该有状态资源的服务器，并将该请求信息发送至同一管理该有状态资源的服务器，进而实现了将请求信息正确分发至服务器(即实现将请求同一有状态资源的不同请求信息发送至同一管理该有状态资源的后端服务器)，以便该服务器将相应的有状态资源反馈给客户端，避免在公共存储区域进行大量读写，以及避免使用全局加锁处理技术，提高了设备运行效率，减小了开发难度。

还可以理解，本申请将对同一有状态资源的请求分发至同一后端服务器，在同一后端服务器上对有状态资源进行缓存和管理，可以避免在多个后端服务器都需要操作该有状态资源而导致的缓存低效或失效、资源互斥访问的复杂性等问题；该后端服务器只需在该服务器范围内管理好该有状态资源的互斥访问即可，能够大大降低公共存储区域的压力，其它后端服务器也不必再管理该有状态资源，即每台后端服务器所管理的有状态资源没有交集，避免了交叉管理和交叉管理带来的开发复杂性，从而提高了整个系统效率。因此，将对同一资源的请求分发至同一后端服务器是关键的一步，是本发明所解决的核心问题。

进一步的，在图3的基础上，下面给出一种完整方案可能的实现方式，具体请参照图4，图4示出了本申请实施例提供的请求信息的分发方法的另一种流程图。需要说明的是，本申请实施例提供的请求信息的分发方法并不以图4以及以下的具体顺序为限制，应当理解，在其它实施例中，本申请实施例提供的请求信息的分发方法其中部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。下面将对图4所示的具体流程进行详细阐述。

对于如何从至少一个服务器中确定出管理有状态资源的服务器，S110可以包括：

S110A，根据请求资源字段以及预设的关系表确定出管理有状态资源的服务器；关系表包括多个服务器与多个有状态资源的对应关系。

上述的关系表可以包括多个服务器与多个有状态资源的对应关系，而请求资源字段表征请求信息所请求的有状态资源(即请求资源字段可以与请求信息所请求的有状态资源对应)，因此可以在多个有状态资源中确定出请求资源字段所对应的有状态资源，然后根据该有状态资源与服务器的对应关系，确定出与该有状态资源对应的服务器(即管理该有状态资源的服务器)。

在一些可能的实施例中，上述的关系表可以如下表1所示，该表中记录了三个服务器，分别为S1-S3；六个有状态资源，分别为R1-R6。

表1

有状态资源	服务器
		R1、R2	S1
R3	S2
		R4、R5、R6	S3

其中，上述的关系表的形式还可以如下表2所示，可以理解，本申请对于关系表的具体形式未作限定。

表2

有状态资源	服务器
		R1	S1
R2	S1
		R3	S2
R4	S3
		R5	S3
R6	S3

假设请求资源字段对应的有状态资源为R3，则电子设备100可以根据请求资源字段对应的有状态资源为R3以及上述表1确定出R3对应的服务器为S2，则可以确定出管理有状态资源R3的服务器为S2。可以理解的是，在实际应用中请求资源字段通常为字符串形式或是数值形式，其表征请求信息所请求的有状态资源(即请求资源字段与其对应的有状态资源的表示关系)通常是预先设定好的，例如，可以通过查表的方式查找出请求资源字段对应的有状态资源，也可以根据预设公式确定出请求资源字段对应的有状态资源。

应理解，由于请求资源字段与其对应的有状态资源的表示关系有许多具体的体现形式，因此，本申请对于如何根据所述请求资源字段以及预设的关系表确定出管理所述有状态资源的服务器的具体方式不做限定，在实际应用中可以根据实际需求设置具体的实现方式。

进一步的，在图4的基础上，对于如何根据请求资源字段以及预设的关系表确定出管理有状态资源的服务器，请参照图5，S110A可以包括：

S110A-1，根据预设规则确定与请求资源字段对应的分发ID；其中，相同的请求资源字段对应相同的分发ID。

可以理解的是，由于相同的请求资源字段对应相同的分发ID(Identitydocument，标识)，因此，在根据预设规则确定出的与请求资源字段对应的分发ID时，相同的请求资源字段在根据预设规则确定对应的分发ID时，所确定出的分发ID相同；不同的请求资源字段在根据预设规则确定对应的分发ID时，所确定出的分发ID不同。例如，当预设规则为预设公式时，对于相同的请求资源字段，经过该预设公式计算出的分发ID相同；对于不同的请求资源字段，经过该预设公式计算出的分发ID不同。

还可以理解的是，上述的不同的请求资源字段可以对应不同的分发ID，并且在一些预设规则中(例如哈希算法)，不同的请求资源字段可能对应不同的分发ID，由于不同的请求资源字段可能对应不同的分发ID，因此，在根据预设规则确定出的与请求资源字段对应的分发ID时，不同的请求资源字段在根据预设规则确定对应的分发ID时，所确定出的分发可能ID不同。例如，当预设规则为预设公式时，对于不同的请求资源字段，经过该预设公式计算出的分发ID可能不同。

换句话说，上述的预设规则的特点是：对于相同的请求资源字段，经过该预设规则作用后，确定出的对应的分发ID相同；对于不同的请求资源字段，经过该预设规则作用后，确定出的对应的分发ID可能不同。

还需要补充的是，上述的分发ID除了数值形式，还可以是字符串形式、二进制串形式等数据形式。

在一些可能的实施例中，对于如何根据预设规则确定与请求资源字段对应的分发ID，可以：计算请求资源字段的哈希值，并将哈希值作为分发ID。

应理解，由于哈希运算满足上述的预设规则的特点，故而通过计算请求资源字段的哈希值，并将哈希值作为分发ID的形式可以实现分发ID的计算。以HTTP请求信息为例，该请求资源字段即为HTTP请求信息的QueryString中所包含device_id字段，且该device_id字段为字符串，故而可以计算出该字符串的哈希值，然后将该哈希值作为分发ID。

在其他可能的实施例中，当请求资源字段为字符串时，对于如何根据预设规则确定与请求资源字段对应的分发ID，还可以：将请求资源字段中的各个字符之和作为分发ID，换句话说，对于如何根据预设规则确定与请求资源字段对应的分发ID，既可以采用计算哈希值的方法确定分发ID，也可以采用其他满足上述的预设规则的方法确定分发ID，本申请对此不做限定。

S110A-2，根据分发ID以及预先维护的对应关系表确定出管理有状态资源的服务器；对应关系表包括多个服务器与多个有状态资源的对应关系。

在一些可能的实施例中，上述的对应关系表可以如下表3所示，该表中记录了三个服务器，分别为S1-S3；六个分发ID，分别为id1-id6；六个有状态资源，分别为R1-R6。

表3

有状态资源	分发ID	管理相应资源的服务器
			R1、R2	id1、id2	S1
R3	id3	S2
			R4、R5、R6	id4、id5、id6	S3

假设分发ID为id3，则电子设备100可以根据id3以及上述表3确定出管理有状态资源的服务器为S2。

可以理解的是，由于分发ID对应请求资源字段，请求资源字段对应有状态资源，且相同的请求资源字段对应相同的分发ID，因此，分发ID表征请求信息所请求的有状态资源。在根据分发ID以及预先维护的对应关系表确定出管理有状态资源的服务器时，其可以理解为，先根据分发ID确定出请求信息所请求的有状态资源，然后根据该有状态资源确定出管理该有状态资源的服务器。

进而还可以理解，上述的对应关系表，在实际应用中可以获取每个服务器以及每个服务器管理的有状态资源，记录每个服务器与每个服务器管理的有状态资源的对应关系，然后根据分发id与对应有状态资源的关系记录分发id与服务器的对应关系。假设服务器S1管理的有状态资源为R1、R2，R1、R2分别对应的分发id为id1、id2，则可以根据上述关系记录S1与id1和id2的对应关系，进而实现根据分发ID以及预先维护的对应关系表确定出管理有状态资源的服务器。其中，上述的对应关系表可以理解为前述S110A中的预设的关系表。

在一些可能的实施例中，在图5的基础上，对于如何维护对应关系表，请参照图6，方法还可以包括：

S110A-4，在获取到待处理分发ID时，根据待处理分发ID对应的有状态资源在对应关系表中记录待处理分发ID与目标服务器的对应关系，并记录待处理分发ID与目标服务器的对应关系的记录时间；目标服务器管理待处理分发ID对应的资源。

S110A-5，当记录时间与当前时间之间的时间间隔超过预设时长时，在对应关系表中删除待处理分发ID与目标服务器的对应关系。

请参照表4，当电子设备100获取到待处理分发ID“id1”时(“id1”与有状态资源R1对应，R1由服务器S1管理)，可以在表4中记录“id1”与S1的对应关系，并记录此时的记录时间为1:10:3。

表4

假设预设时长为60s，且当前时间为1:12:10，则记录时间与当前时间之间的时间间隔超过预设时长，电子设备100可以在表4中将id1删去，以在对应关系表中删除待处理分发ID与目标服务器的对应关系。

在一些可能的实施例中，在图6的基础上，请参照图7，在S110A-1之后，对于如何确定出管理有状态资源的服务器，方法还可以包括：

S110A-3，根据如下公式确定出管理有状态资源的服务器：K＝ID％N；其中，N为至少一个服务器的个数，管理有状态资源的服务器为至少一个服务器中的第K个服务器，ID为分发ID，％表示取模运算。

请参照下表5，假设N为4，即上述的至少一个服务器的个数为4个，当ID％N＝1时，则确定服务器2为管理有状态资源的服务器。

表5

N	服务器	管理的有状态资源
			0	服务器1	R1
1	服务器2	R2
			2	服务器3	R3
3	服务器4	R4

可以理解的是，在S110A-3中，电子设备可以预先维护一张N-服务器关系表，该表可以记录分发id在ID％N为0至N-1范围内对应的服务器，从而可以实现根据分发ID以及K＝ID％N确定出管理有状态资源的服务器。同样的，电子设备可以先记录每个ID％N数据与对应的有状态资源的关系，然后记录每个有状态资源与服务器的对应关系，从而建立上述的N-服务器关系表。

需要说明的是，S110A-3与S110A-4->S110A-5的关系是功能上的包含关系，即使用S110A-3替代S110A-2时，无需使用S110A-4->S110A-5提供的方法。可以使用S110A-3的数学方法确定资源与后端服务器的对应关系，也可以通过S110A-2使用S110A-4所维护的表进行查表得到资源与后端服务器的关系，本申请对此不做限制。

还需要说明的是，需要说明的是，对于S110A-4、S110A-5所维护的表，当有新的有状态资源(该有状态资源不在表中)被请求时，可以根据一定的策略来动态决定该有状态资源与哪一后端服务器对应，例如轮询策略，上一次把新的有状态资源分配给服务器A，则这一次把新的有状态资源分给服务器B，下一次把新的有状态资源分给服务器C，即对于新的有状态资源，可以按顺序依次分配给多个服务器；或者，根据后端服务器压力，选择一个相对最空闲的服务器来处理新的有状态资源的请求，如加权轮询、后端服务器连接数等。

在一些可能的实施例中，为了解决在服务器与电子设备断开连接等情况发生时，不能将请求信息进行正确发送的问题，请继续参照图7，方法还可以包括：

S130，将至少一个服务器管理的有状态资源的数据均存储至公共存储空间。

由于电子设备100将至少一个服务器管理的有状态资源的数据均存储至公共存储空间，当任一服务器因异常等情况与电子设备100断开连接时，电子设备100可以根据该公共存储空间中的有状态资源的数据将有状态资源重新分配至剩下的服务器(即实现将断开连接服务器所管理的有状态资源交给其他服务器进行管理)；或者当新增服务器时，电子设备100可以根据该公共存储空间中的有状态资源的数据将有状态资源分配至新增的服务器(即实现将有状态资源交给新增服务器进行管理)。实现了有状态资源的灵活分配，避免在服务器与电子设备断开连接等情况发生时，不能将请求信息进行正确发送。

应理解，本申请实现了将请求同一有状态资源的不同请求信息发送至同一管理该有状态资源的后端服务器，换句话说将对有状态资源的访问分散到各个服务器(也可以了理解为负载均衡节点)上后，可以大大降低主存储(即公共存储空间)的压力，各个服务器可以使用内存等高效的缓存来减少读写压力，提高业务并发能力。并且，电子设备可以仅在初始化有状态资源时访问主存储，同时也可以以较低的频率向主存储同步资源的变化，大量的只读访问只发生在各个服务器上，大大降低了主存储的压力。

还需要说明的是，对于多个请求信息而言，其请求的有状态资源是随机的，在大量有状态资源被请求的情况下，本申请所提供的方法还能够将请求信息均衡分发至服务器，实现均衡负载的效果。

为了执行上述实施例及各个可能的方式中的相应步骤，下面给出一种请求信息的分发装置的实现方式，请参阅图8，图8示出了本申请实施例提供的请求信息的分发装置的一种功能模块图。需要说明的是，本实施例所提供的请求信息的分发装置400，其基本原理及产生的技术效果和上述实施例相同，为简要描述，本实施例部分未提及之处，可参考上述的实施例中相应内容。该请求信息的分发装置400包括：获取模块410、确定模块420、发送模块430。

可选地，上述模块可以软件或固件(Firmware)的形式存储于存储器中或固化于本申请提供的电子设备100的操作系统(Operating System，OS)中，并可由电子设备100中的处理器执行。同时，执行上述模块所需的数据、程序的代码等可以存储在存储器中。

获取模块410可以用于获取客户端发送的请求信息中的请求资源字段；请求资源字段表征请求信息所请求的有状态资源。

可以理解的是，获取模块410可以用于支持电子设备100执行上述S100等，和/或用于本文所描述的技术的其他过程。

确定模块420可以用于从至少一个服务器中确定出管理有状态资源的服务器。

可以理解的是，确定模块420可以用于支持电子设备100执行上述S110等，和/或用于本文所描述的技术的其他过程。

发送模块430可以用于将请求信息发送至服务器。

可以理解的是，发送模块430可以用于支持电子设备100执行上述S120等，和/或用于本文所描述的技术的其他过程。

对于如何从至少一个服务器中确定出管理有状态资源的服务器，在一些可能的实施例中，确定模块420可以用于根据请求资源字段以及预设的关系表确定出管理有状态资源的服务器；关系表包括多个服务器与多个有状态资源的对应关系。

可以理解的是，确定模块420可以用于支持电子设备100执行上述S110A等，和/或用于本文所描述的技术的其他过程。

对于如何根据请求资源字段以及预设的关系表确定出管理有状态资源的服务器，确定模块420可以用于根据预设规则确定与请求资源字段对应的分发ID；其中，不同的请求资源字段可能对应不同的分发ID，相同的请求资源字段对应相同的分发ID；以及可以用于根据分发ID以及预先维护的对应关系表确定出管理有状态资源的服务器；对应关系表包括多个服务器与多个有状态资源的对应关系。

可以理解的是，确定模块420可以用于支持电子设备100执行上述S110A-1、S110A-2等，和/或用于本文所描述的技术的其他过程。

对于如何维护对应关系表，确定模块420可以用于在获取到待处理分发ID时，根据待处理分发ID对应的有状态资源在对应关系表中记录待处理分发ID与目标服务器的对应关系，并记录待处理分发ID与目标服务器的对应关系的记录时间；目标服务器管理待处理分发ID对应的有状态资源；以及用于当记录时间与当前时间之间的时间间隔超过预设时长时，在对应关系表中删除待处理分发ID与目标服务器的对应关系。

可以理解的是，确定模块420可以用于支持电子设备100执行上述S110A-4、S110A-5等，和/或用于本文所描述的技术的其他过程。

在S110A-1之后，对于如何确定出管理资源的服务器，确定模块420可以用于根据如下公式确定出管理有状态资源的服务器：K＝ID％N；其中，N为至少一个服务器的个数，管理有状态资源的服务器为至少一个服务器中的第K个服务器，ID为分发ID，％表示取模运算。

为了解决在服务器与电子设备断开连接等情况发生时，不能将请求信息进行正确发送的问题，发送模块430可以用于将至少一个服务器管理的有状态资源的数据均存储至公共存储空间。

可以理解的是，发送模块430可以用于支持电子设备100执行上述S130等，和/或用于本文所描述的技术的其他过程。

基于上述方法实施例，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述请求信息的分发方法的步骤。

具体地，该存储介质可以为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述请求信息的分发方法，从而解决现有的设备运行效率低下、开发难度大的问题，实现将请求有状态资源的请求信息正确分发至服务器，且避免在公共存储区域进行大量读写，以及避免使用全局加锁处理技术，提高了设备运行效率，减小了开发难度。

综上所述，本申请实施例提供了一种请求信息的分发方法、装置、存储介质和电子设备，该方法包括：获取客户端发送的请求信息中的请求资源字段；请求资源字段表征请求信息所请求的有状态资源；从至少一个服务器中确定出管理有状态资源的服务器；将请求信息发送至服务器。由于所获取的请求资源字段表征该请求信息所请求的有状态资源，故而根据该请求资源字段可以从至少一个服务器中确定出管理该有状态资源的服务器，并将该请求信息发送至同一管理该有状态资源的服务器，进而实现了将请求信息正确分发至服务器，避免在公共存储区域进行大量读写，以及避免使用全局加锁处理技术，提高了设备运行效率，减小了开发难度。

现有技术下的负载均衡会将同一资源的请求发送至不同的服务器，使得这些资源的缓存副本可能出现在多台服务器上，而使用本申请所述方法，可以将同一资源的请求信息发送至同一管理该资源的服务器上，同一资源的缓存只出现在同一服务器上。因此本申请对于无状态资源的请求分发也有提效作用。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (12)

1.一种请求信息的分发方法，其特征在于，包括：

获取客户端发送的请求信息中的请求资源字段；所述请求资源字段表征所述请求信息所请求的有状态资源；

从至少一个服务器中确定出管理所述有状态资源的服务器；

将所述请求信息发送至所述服务器。

2.根据权利要求1所述的方法，其特征在于，从至少一个服务器中确定出管理所述有状态资源的服务器的步骤包括：

根据所述请求资源字段以及预设的关系表确定出管理所述有状态资源的服务器；所述关系表包括多个服务器与多个有状态资源的对应关系。

3.根据权利要求2所述的方法，其特征在于，根据所述请求资源字段以及预设的关系表确定出管理所述有状态资源的服务器的步骤包括：

根据预设规则确定与所述请求资源字段对应的分发标识ID；其中，相同的请求资源字段对应相同的分发ID；

根据所述分发ID以及预先维护的对应关系表确定出管理所述有状态资源的服务器；所述对应关系表包括多个服务器与多个有状态资源的对应关系。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

在获取到待处理分发ID时，根据所述待处理分发ID对应的有状态资源在所述对应关系表中记录所述待处理分发ID与目标服务器的对应关系，并记录所述待处理分发ID与目标服务器的对应关系的记录时间；所述目标服务器管理所述待处理分发ID对应的有状态资源；

当所述记录时间与当前时间之间的时间间隔超过预设时长时，在所述对应关系表中删除所述待处理分发ID与目标服务器的对应关系。

5.根据权利要求3所述的方法，其特征在于，在获取到所述分发ID后，根据如下公式确定出管理所述有状态资源的服务器：

K＝ID％N；

其中，N为所述至少一个服务器的个数，管理所述有状态资源的服务器为所述至少一个服务器中的第K个服务器，ID为所述分发ID，％表示取模运算。

6.根据权利要求3所述的方法，其特征在于，根据预设规则计算所述请求资源字段，得到分发ID的步骤包括：

计算所述请求资源字段的哈希值，并将所述哈希值作为所述分发ID。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

将所述至少一个服务器管理的有状态资源的数据均存储至公共存储空间。

8.一种请求信息的分发装置，其特征在于，包括：

获取模块，用于获取客户端发送的请求信息中的请求资源字段；所述请求资源字段表征所述请求信息所请求的有状态资源；

确定模块，用于从至少一个服务器中确定出管理所述有状态资源的服务器；

发送模块，用于将所述请求信息发送至所述服务器。

9.根据权利要求8所述的装置，其特征在于，所述确定模块用于根据所述请求资源字段以及预设的关系表确定出管理所述有状态资源的服务器；所述关系表包括多个服务器与多个有状态资源的对应关系。

10.根据权利要求9所述的装置，其特征在于，所述确定模块用于根据预设规则确定与所述请求资源字段对应的分发ID；其中，相同的请求资源字段对应相同的分发ID；

所述确定模块还用于根据所述分发ID以及预先维护的对应关系表确定出管理所述有状态资源的服务器；所述对应关系表包括多个服务器与多个有状态资源的对应关系。

11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-7中任一项所述的请求信息的分发方法。

12.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当所述电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述处理器执行所述机器可读指令，以执行如权利要求1-7中任一项所述的请求信息的分发方法。

Images