CN104702647A - 信息请求方法和*** - Google Patents

Abstract

本发明公开了一种信息请求方法和***。该方法包括：第一服务器接收用户发送的用于获取信息的请求消息；第一服务器响应于请求消息判断用户是否具有获取信息的权限；若是用户具有获取信息的权限，则第一服务器向第二服务器请求获取信息；若第一服务器向第二服务器请求获取信息失败，则第一服务器向第三服务器请求补发信息；若第一服务器向第三服务器请求补发信息成功，则第一服务器将从第三服务器中接收到的信息转发给用户。本发明解决了由于现有的游戏道具的领取方法中对道具发放失败仅采用简单的回滚处理所造成的服务器负荷及数据库读写压力较大的技术问题。

Description

信息请求方法和***

技术领域

本发明涉及通信领域，具体而言，涉及一种信息请求方法和***。

背景技术

现有的在线游戏中，游戏道具是丰富游戏内容、提高用户体验的重要元素，其中，对游戏道具进行领取的过程通常涉及对多个数据库的访问以及多个服务器之间的通信。其中，一般而言，为方便游戏道具向用户分配的集中管理，游戏道具的领取页面通常设置在官网服务器上，而具体的游戏道具的发放方法是与游戏内容相关联的，因此该方法通常会设置在游戏服务器。具体而言，现有的游戏道具的领取方法通常可以采用如图1所示的流程，其中，该流程可以概括如下：

S102：用户向官网服务器发送领取道具的请求；

S104：官网服务器检查发送请求消息的用户的权限；

S106：若发送请求消息的用户具备领取权限，则官网服务器向游戏服务器发送道具发放请求，并跳到步骤S110；

S108：若发送请求消息的用户不具备领取权限，则向用户返回不具备权限的指示；

S110：若游戏服务器在接到该道具发放请求后，成功发送了对应的游戏道具，则向用户返回道具领取成功的指示；

S112：若游戏服务器在接到该道具发放请求后，未成功发送对应的游戏道具，则回滚用户的领取权限；S114：若未成功，并向用户返回道具领取失败的指示。

由此可知，在上述方案中，不论游戏道具发放成功与否，整个领取方法都将结束。而在道具发放失败的情形下，用户接收到道具领取失败的反馈后，通常会再次请求领取该游戏道具，从而官网服务器需要再次对这一请求消息进行回应，并再次执行检查该用户的权限的查询及处理操作。考虑到一款在线游戏具有较为庞大的用户基数的情形，上述方案将明显增加官网服务器的负荷以及存储有用户权限的数据库的访问压力，在另一方面，道具领取失败之后执行的回滚操作同样增大了数据库的读写压力，进而对该在线游戏的运营状态造成负面影响，以致于影响用户体验。针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种信息请求方法和***，以至少解决由于现有的游戏道具的领取方法中对道具发放失败仅采用简单的回滚处理所造成的服务器负荷及数据库读写压力较大的技术问题。

根据本发明实施例的一个方面，提供了一种信息请求方法，包括：第一服务器接收用户发送的用于获取信息的请求消息；上述第一服务器响应于上述请求消息判断上述用户是否具有获取上述信息的权限；若是上述用户具有获取上述信息的权限，则上述第一服务器向第二服务器请求获取上述信息；若上述第一服务器向上述第二服务器请求获取上述信息失败，则上述第一服务器向第三服务器请求补发上述信息；若上述第一服务器向上述第三服务器请求补发上述信息成功，则上述第一服务器将从上述第三服务器中接收到的上述信息转发给上述用户。

根据本发明实施例的另一方面，还提供了一种信息请求***，包括：接收单元，用于接收用户发送的用于获取信息的请求消息；第一判断单元，用于响应于上述请求消息判断上述用户是否具有获取上述信息的权限；第一请求单元，用于在上述用户具有获取上述信息的权限时，向上述第二服务器请求获取上述信息；第二请求单元，用于在上述第一服务器向上述第二服务器请求获取上述信息失败时，则上述第一服务器向上述第三服务器请求补发上述信息；转发单元，用于在上述第一服务器向上述第三服务器请求补发上述信息成功时，将从上述第三服务器中接收到的上述信息转发给上述用户。

在本发明实施例中，采用对第二服务器未成功发放的信息进行补发的设计，可以在一定程度上达到在第一服务器对于用户发送的请求消息的同一次回应中将用户请求的信息返回给用户的效果，进而避免了信息发放失败后的回滚操作，以及由于信息发放失败导致的用户对该请求消息的再次发送，并且免除了第一服务器的再次鉴权，从而实现了降低第一服务器的负荷以及回滚和鉴权操作所对应的数据库的访问压力的技术效果，解决了由于现有的游戏道具的领取方法中对道具发放失败仅采用简单的回滚处理所造成的服务器负荷及数据库读写压力较大的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据现有技术的一种信息请求***的示意图；

图2是根据本发明实施例的一种可选的信息请求方法的示意图；

图3是根据本发明实施例的另一种可选的信息请求方法的示意图；

图4是根据本发明实施例的又一种可选的信息请求方法的示意图；

图5是根据本发明实施例的又一种可选的信息请求方法的示意图；

图6是根据本发明实施例的一种信息请求***的交互图；

图7是根据本发明实施例的另一种信息请求***的示意图；

图8是根据本发明实施例的又一种信息请求***的示意图；

图9是根据本发明实施例的又一种信息请求***的示意图；

图10是根据本发明实施例的又一种信息请求***的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本发明实施例，提供了一种信息请求方法，如图2所示，该方法包括：

S202：第一服务器接收用户发送的用于获取信息的请求消息；

S204：第一服务器响应于请求消息判断用户是否具有获取信息的权限；

S206：若是用户具有获取信息的权限，则第一服务器向第二服务器请求获取信息；

S208：若第一服务器向第二服务器请求获取信息失败，则第一服务器向第三服务器请求补发信息；

S210：若第一服务器向第三服务器请求补发信息成功，则第一服务器将从第三服务器中接收到的信息转发给用户。

应当明确的是，本发明技术方案所要解决的问题之一是提供一种方法，来对用户发出的获取某一信息的请求进行回应，以在判断出该用户具备获取该信息的权限后，尽可能地促使服务器在本次对请求的回应过程中将该信息成功地返回给该用户，从而达到减少服务器对数据库的操作次数的效果，进而降低服务器和数据库的处理和访问压力。其中，在本发明的一些实施例中，上述信息可以是游戏道具的相关信息，比如道具ID，然而本发明对此不作限定。

根据本发明实施例提供的信息请求方法，在步骤S202中，可以利用第一服务器来接收用户发送的用于获取信息的请求。其中，该获取信息的请求可以为超文本传输协议http(Hypertext Transfer Protocol)请求，也可以为文件传输协议ftp（File TransferProtocol）请求，或者为符合其他可行的文本传输格式的请求等，本发明对此不作限定。更具体地，该请求可以体现为一个消息，例如，对于http请求而言，其所对应的消息可以由请求行、消息头和消息体组成。可选地，在本发明实施例中，步骤S202中所述的请求消息可以携带有能够为第一服务器所识别的与该消息所需获取的信息对应的标识项，例如对于作为该信息的游戏道具而言，该消息可以携带有该游戏道具的道具ID。

一般而言，在本发明实施例中，第一服务器可以是专用于对此类请求进行处理的服务器，例如官网服务器，然而应当理解，这并非是指该官网服务器或者说第一服务器不能用于执行其他业务。进一步地，本发明对于实施例中出现的第一、第二、第三服务器并不作限定。

根据本发明实施例提供的信息请求方法，在步骤S204中，第一服务器可以响应于用户发送的请求消息，判断该用户是否具有获取信息的权限，也即第一服务器对用户是否有足够的权限获取这一信息的鉴权操作。一般而言，在本发明实施例中，步骤S204的实现方式可以是与现有技术类似的鉴权方式，其中，最一般地，第一服务器可以访问存储有该信息对应的鉴权信息的数据库，并对用户发送的请求消息中是否携带有该鉴权信息进行判断，若是，则判断出通过鉴权，也即该用户具有获取信息的权限，若否，则判断出未通过鉴权，也即该用户不具有获取信息的权限。

进一步地，在本发明实施例中，若通过步骤S204判断出用户具有获取信息的权限，则可以进一步在步骤S206中，通过第一服务器向第二服务器请求获取该信息。在这一场景下，第一服务器向第二服务器发出的请求既可以为不同于前述的由用户发出的请求消息的能够被第二服务器所识别的一个新的请求，也可以是与用户发出的请求消息相同的请求，从而也可以视为是由第一服务器向第二服务器转发的请求。

其中，对于在线游戏的应用场景，该第二服务器即可以为游戏服务器，进而该游戏服务器或者说第二服务器可以根据接收到的该请求为用户配发该信息，比如发放该请求对应的游戏道具。在本发明实施例中，第二服务器对请求的信息的发放的具体实现方式可以有多种，其中，对于在线游戏而言，作为第二服务器的游戏服务器可以直接向游戏用户发放所需领取的游戏道具，或者说将该游戏道具的道具ID对应添加到该用户对应的数据记录，比如所有物属性中，然而在本发明的另一些实施例中，第二服务器所返回的该信息也可以不直接发送给用户，而是经由第一服务器进行转发，本发明对此不作限定，其对本发明技术方案的实施及其效果的兑现不会造成任何影响。

进一步地，在本发明实施例中，可以在第二服务器对第一服务器发出的请求进行回应后，对第二服务器是否成功地对所需的该信息进行发放进行判断。具体地，对于在线游戏的场景，作为第二服务器的游戏服务器在响应于请求并发放对应的游戏道具后，该游戏服务器自身即可以检测存储在该游戏服务器上或者是与该游戏服务器相连的第三方服务器上的数据库中，请求该游戏道具的用户是否已成功获取该道具。当然，这只是一种示例，在本发明实施例中，还可以有其他的方式对第二服务器是否成功发放该信息进行判断，例如，对于前述的第二服务器经由第一服务器将信息返回给用户的情形，也可以在第一服务器上对是否接收到和/或发送出该信息进行判断，并这一判断的结果作为对第二服务器是否成功发放该信息的判断结果。换而言之，考虑到第二服务器发放该信息的操作表现为第二服务器对第一服务器发出的请求所进行的回应，因此上述判断结果也可以表述为第一服务器向第二服务器请求获取信息是成功还是失败。

基于上述判断结果，根据本发明实施例提供的信息请求方法，在步骤S208中，若第一服务器想第二服务器请求获取信息失败，则第一服务器可以转而向第三服务器请求补发该信息。

区别于现有技术，在本发明实施例中，可以利用第三服务器或者说设置在第三服务器上的补发***来对未成功发放的信息进行补发，而非简单地对服务器及数据库进行回滚，并向用户返回获取信息失败的指示。其中，最一般地，该补发***可以与位于第二服务器上的信息的发放***对应，然而本发明对此不作限定，例如在本发明之后的实施例中所示的更为复杂的补发机制。

值得注意的是，该第三服务器仅用于表示进行上述补发***所在的服务器，其中，在本发明的一些实施例中，该补发***也可以直接设置在游戏服务器上，从而使得第三服务器与第二服务器形成为一体。

进而在步骤S210中，若第一服务器向第三服务器请求补发信息成功，则第一服务器可以将从第三服务器中接收到的信息转发给用户，其中，具体的转发方式可以有多种，例如图3所示的，步骤S210可以包括：

S302：第一服务器在第三服务器设置的第一补发时间上获取第三服务器发送的信息；

S304：第一服务器将从第三服务器中接收到的信息转发给用户。

在上述场景中，第一服务器可以作为请求对应的信息的中转，先通过步骤S302从第三服务器获取该信息，然后再将获取到的该信息发送给用户。这种实施方式的优势在于：1）用户与第一服务器的交互、第一服务器与第二服务器的交互、以及第一服务器与第三服务器的交互逻辑可以是解耦的，从而简化了信息请求***的维护；2）可以对向第二服务器请求信息是否成功与向第三服务器请求信息是否成功进行类似的判断，而该判断逻辑可以统一设置在第一服务器上，从而进一步地简化了信息请求***的维护。

当然，以上只是本发明可行的实施方式之一，并不意味着对本发明构成了任何限定，例如类似于前述实施方式中所述的第二服务器对该信息的发放，在本发明的一些实施例中，也可以直接由第三服务器向用户发送该信息，进而由第三服务器或者是用户来判断补发是否成功，等。

进一步地，在步骤S302中，可以在第三服务器设置的第一补发时间获取补发的该信息，通过这一设置，可以在出现信息发放失败之后的一段时间再进行上述补发操作，从而一定程度上避免了故障的再次出现。当然，一般而言，第一补发时间的滞后可以相对较短，以免由于较长的等待时间影响到用户体验。

更进一步地，如图4所示，作为一种可选的方式，在本发明实施例中，步骤S208可以包括：

S402：第三服务器设置第一补发时间，并在第一补发时间上向第一服务器发送信息；

S404：若第三服务器在第一补发时间上向第一服务器发送信息失败，则第三服务器判断当前补发信息的次数是否达到预定阈值；

S406：若第三服务器判断出当前补发信息的次数未达到预定阈值，则第三服务器设置第二补发时间，并在第二补发时间上向第一服务器发送信息。

在上述场景下，第三服务器可以在滞后一定时间的第一补发时间向第一服务器发送上述信息，并且可以在补发失败的情形下，在步骤S406中，在一个设置好的第二补发时间上再次进行补发，其中，如步骤S404所述，总体的补发次数可以限定在一个预定阈值内，以免无限制地延长用户对获取该信息的等待时间，并且避免由于***漏洞所造成的补发机制的滥用。其中，如图5所示，可选地，在本发明实施例中，若第三服务器判断出当前补发信息的次数未达到预定阈值，则步骤S208还可以包括：

S502：第三服务器停止向第一服务器补发信息，并向用于管理信息的管理设备发送告警信息。

更具体地，在本发明实施例中，第三服务器根据以下至少之一来设置第一补发时间和第二补发时间：信息对应的业务类型、第二服务器是否停止工作、第三服务器的运行负荷，从而第三服务器可以根据信息请求***的运行状态来合理地设置第一补发时间和第二补发时间，以避免造成过大的额外的运行负荷。

通过以上实施例可知，在本发明实施例中，采用对第二服务器未成功发放的信息进行补发的设计，可以在一定程度上达到在第一服务器对于用户发送的请求消息的同一次回应中将用户请求的信息返回给用户的效果，进而避免了信息发放失败后的回滚操作，以及由于信息发放失败导致的用户对该请求消息的再次发送，并且免除了第一服务器的再次鉴权，从而实现了降低第一服务器的负荷以及回滚和鉴权操作所对应的数据库的访问压力的技术效果，解决了由于现有的游戏道具的领取方法中对道具发放失败仅采用简单的回滚处理所造成的服务器负荷及数据库读写压力较大的技术问题。

下面将结合一个具体的实施例来对本发明技术方案进行描述。在该实施例中，上述信息请求方法可以应用于在线游戏的场景，其中，用户请求的信息可以包括用于指示游戏程序中的道具的信息，更具体地，可以包括以下至少之一：游戏业务名、角色ID、道具ID、道具数量。

如图6所示，在该实施例中，信息请求***可以包括：用户、作为第一服务器的官网服务器、作为第二服务器的游戏服务器以及设置在该第二服务器或第三服务器上的补发***。其中，该实施例中的信息请求方法的流程可以描述如下：

S602：用户向官网服务器发送领取道具的请求；

S604：官网服务器检查发送请求消息的用户的权限；

S606：若发送请求消息的用户具备领取权限，则官网服务器向游戏服务器发送道具发放请求，并跳到步骤S610；

S608：若发送请求消息的用户不具备领取权限，则向用户返回不具备权限的指示；

S610：若游戏服务器在接到该道具发放请求后，成功发送了对应的游戏道具，则向用户返回道具领取成功的指示；

S612：若游戏服务器在接到该道具发放请求后，未成功发送对应的游戏道具，则向补发***发起补发请求；

S614：若成功补发游戏道具，则向用户返回道具领取成功的指示；

S616：若补发次数达到或超过预定阈值仍未成功补发游戏道具，则向用户返回道具领取失败的指示。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端设备（可以是手机，计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。

实施例2

根据本发明实施例，还提供了一种用于实施上述信息请求方法的信息请求***，该***包括第一服务器、第二服务器和第三服务器，其中，如图7所示，该第一服务器包括：

1）接收单元702，用于接收用户发送的用于获取信息的请求消息；

2）第一判断单元704，用于响应于请求消息判断用户是否具有获取信息的权限；

3）第一请求单元706，用于在用户具有获取信息的权限时，向第二服务器请求获取信息；

4）第二请求单元708，用于在第一服务器向第二服务器请求获取信息失败时，则第一服务器向第三服务器请求补发信息；

5）转发单元710，用于在第一服务器向第三服务器请求补发信息成功时，将从第三服务器中接收到的信息转发给用户。

应当明确的是，本发明技术方案所要解决的问题之一是提供一种***，来对用户发出的获取某一信息的请求进行回应，以在判断出该用户具备获取该信息的权限后，尽可能地促使服务器在本次对请求的回应过程中将该信息成功地返回给该用户，从而达到减少服务器对数据库的操作次数的效果，进而降低服务器和数据库的处理和访问压力。其中，在本发明的一些实施例中，上述信息可以是游戏道具的相关信息，比如道具ID，然而本发明对此不作限定。

根据本发明实施例提供的信息请求***，在接收单元702中，可以利用第一服务器来接收用户发送的用于获取信息的请求。其中，该获取信息的请求可以为超文本传输协议http(Hypertext Transfer Protocol)请求，也可以为文件传输协议ftp（File TransferProtocol）请求，或者为符合其他可行的文本传输格式的请求等，本发明对此不作限定。更具体地，该请求可以体现为一个消息，例如，对于http请求而言，其所对应的消息可以由请求行、消息头和消息体组成。可选地，在本发明实施例中，接收单元702中所述的请求消息可以携带有能够为第一服务器所识别的与该消息所需获取的信息对应的标识项，例如对于作为该信息的游戏道具而言，该消息可以携带有该游戏道具的道具ID。

一般而言，在本发明实施例中，第一服务器可以是专用于对此类请求进行处理的服务器，例如官网服务器，然而应当理解，这并非是指该官网服务器或者说第一服务器不能用于执行其他业务。进一步地，本发明对于实施例中出现的第一、第二、第三服务器并不作限定。

根据本发明实施例提供的信息请求***，在第一判断单元704中，第一服务器可以响应于用户发送的请求消息，判断该用户是否具有获取信息的权限，也即第一服务器对用户是否有足够的权限获取这一信息的鉴权操作。一般而言，在本发明实施例中，第一判断单元704的实现方式可以是与现有技术类似的鉴权方式，其中，最一般地，第一服务器可以访问存储有该信息对应的鉴权信息的数据库，并对用户发送的请求消息中是否携带有该鉴权信息进行判断，若是，则判断出通过鉴权，也即该用户具有获取信息的权限，若否，则判断出未通过鉴权，也即该用户不具有获取信息的权限。

进一步地，在本发明实施例中，若通过第一判断单元704判断出用户具有获取信息的权限，则可以进一步在第一请求单元706中，通过第一服务器向第二服务器请求获取该信息。在这一场景下，第一服务器向第二服务器发出的请求既可以为不同于前述的由用户发出的请求消息的能够被第二服务器所识别的一个新的请求，也可以是与用户发出的请求消息相同的请求，从而也可以视为是由第一服务器向第二服务器转发的请求。

其中，对于在线游戏的应用场景，该第二服务器即可以为游戏服务器，进而该游戏服务器或者说第二服务器可以根据接收到的该请求为用户配发该信息，比如发放该请求对应的游戏道具。在本发明实施例中，第二服务器对请求的信息的发放的具体实现方式可以有多种，其中，对于在线游戏而言，作为第二服务器的游戏服务器可以直接向游戏用户发放所需领取的游戏道具，或者说将该游戏道具的道具ID对应添加到该用户对应的数据记录，比如所有物属性中，然而在本发明的另一些实施例中，第二服务器所返回的该信息也可以不直接发送给用户，而是经由第一服务器进行转发，本发明对此不作限定，其对本发明技术方案的实施及其效果的兑现不会造成任何影响。

进一步地，在本发明实施例中，可以在第二服务器对第一服务器发出的请求进行回应后，对第二服务器是否成功地对所需的该信息进行发放进行判断。具体地，对于在线游戏的场景，作为第二服务器的游戏服务器在响应于请求并发放对应的游戏道具后，该游戏服务器自身即可以检测存储在该游戏服务器上或者是与该游戏服务器相连的第三方服务器上的数据库中，请求该游戏道具的用户是否已成功获取该道具。当然，这只是一种示例，在本发明实施例中，还可以有其他的方式对第二服务器是否成功发放该信息进行判断，例如，对于前述的第二服务器经由第一服务器将信息返回给用户的情形，也可以在第一服务器上对是否接收到和/或发送出该信息进行判断，并这一判断的结果作为对第二服务器是否成功发放该信息的判断结果。换而言之，考虑到第二服务器发放该信息的操作表现为第二服务器对第一服务器发出的请求所进行的回应，因此上述判断结果也可以表述为第一服务器向第二服务器请求获取信息是成功还是失败。

基于上述判断结果，根据本发明实施例提供的信息请求***，在第二请求单元708中，若第一服务器想第二服务器请求获取信息失败，则第一服务器可以转而向第三服务器请求补发该信息。

区别于现有技术，在本发明实施例中，可以利用第三服务器或者说设置在第三服务器上的补发***来对未成功发放的信息进行补发，而非简单地对服务器及数据库进行回滚，并向用户返回获取信息失败的指示。其中，最一般地，该补发***可以与位于第二服务器上的信息的发放***对应，然而本发明对此不作限定，例如在本发明之后的实施例中所示的更为复杂的补发机制。

值得注意的是，该第三服务器仅用于表示进行上述补发***所在的服务器，其中，在本发明的一些实施例中，该补发***也可以直接设置在游戏服务器上，从而使得第三服务器与第二服务器形成为一体。

进而在转发单元710中，若第一服务器向第三服务器请求补发信息成功，则第一服务器可以将从第三服务器中接收到的信息转发给用户，其中，具体的转发方式可以有多种，例如图8所示的，转发单元710可以包括：

1）获取模块802，用于在第一服务器向第三服务器请求获取信息成功时，在第三服务器设置的第一补发时间上获取第三服务器发送的信息；

2）转发模块804，用于将从第三服务器中接收到的信息转发给用户。

在上述场景中，第一服务器可以作为请求对应的信息的中转，先通过获取模块802从第三服务器获取该信息，然后再将获取到的该信息发送给用户。这种实施方式的优势在于：1）用户与第一服务器的交互、第一服务器与第二服务器的交互、以及第一服务器与第三服务器的交互逻辑可以是解耦的，从而简化了信息请求***的维护；2）可以对向第二服务器请求信息是否成功与向第三服务器请求信息是否成功进行类似的判断，而该判断逻辑可以统一设置在第一服务器上，从而进一步地简化了信息请求***的维护。

当然，以上只是本发明可行的实施方式之一，并不意味着对本发明构成了任何限定，例如类似于前述实施方式中所述的第二服务器对该信息的发放，在本发明的一些实施例中，也可以直接由第三服务器向用户发送该信息，进而由第三服务器或者是用户来判断补发是否成功，等。

进一步地，在获取模块802中，可以在第三服务器设置的第一补发时间获取补发的该信息，通过这一设置，可以在出现信息发放失败之后的一段时间再进行上述补发操作，从而一定程度上避免了故障的再次出现。当然，一般而言，第一补发时间的滞后可以相对较短，以免由于较长的等待时间影响到用户体验。

更进一步地，如图9所示，作为一种可选的方式，在本发明实施例中，第三服务器可以包括：

1）发送单元902，用于设置第一补发时间，并在第一补发时间上向第一服务器发送信息；

2）第二判断单元904，在发送单元在第一补发时间上向第一服务器发送信息失败时，判断当前补发信息的次数是否达到预定阈值；其中，

发送单元902还用于在第三服务器判断出当前补发信息的次数未达到预定阈值时，设置第二补发时间，并在第二补发时间上向第一服务器发送信息。

在上述场景下，第三服务器可以在滞后一定时间的第一补发时间向第一服务器发送上述信息，并且可以在补发失败的情形下，在发送单元902中，在一个设置好的第二补发时间上再次进行补发，其中，如第二判断单元904中所述，总体的补发次数可以限定在一个预定阈值内，以免无限制地延长用户对获取该信息的等待时间，并且避免由于***漏洞所造成的补发机制的滥用。其中，如图10所示，可选地，在本发明实施例中，若第三服务器判断出当前补发信息的次数达到预定阈值，则第三服务器还可以包括：

1）告警单元1002，用于在第二判断单元904判断出当前补发信息的次数达到预定阈值时，停止向第一服务器补发信息，并向用于管理信息的管理设备发送告警信息。

更具体地，在本发明实施例中，发送单元902可以根据以下至少之一来设置第一补发时间和第二补发时间：信息对应的业务类型、第二服务器是否停止工作、第三服务器的运行负荷，从而第三服务器可以根据信息请求***的运行状态来合理地设置第一补发时间和第二补发时间，以避免造成过大的额外的运行负荷。

通过以上实施例可知，在本发明实施例中，采用对第二服务器未成功发放的信息进行补发的设计，可以在一定程度上达到在第一服务器对于用户发送的请求消息的同一次回应中将用户请求的信息返回给用户的效果，进而避免了信息发放失败后的回滚操作，以及由于信息发放失败导致的用户对该请求消息的再次发送，并且免除了第一服务器的再次鉴权，从而实现了降低第一服务器的负荷以及回滚和鉴权操作所对应的数据库的访问压力的技术效果，解决了由于现有的游戏道具的领取方法中对道具发放失败仅采用简单的回滚处理所造成的服务器负荷及数据库读写压力较大的问题。

下面将结合一个具体的实施例来对本发明技术方案进行描述。在该实施例中，上述信息请求***可以应用于在线游戏的场景，其中，用户请求的信息可以包括用于指示游戏程序中的道具的信息，更具体地，可以包括以下至少之一：游戏业务名、角色ID、道具ID、道具数量。

如图6所示，在该实施例中，信息请求***可以包括：用户、作为第一服务器的官网服务器、作为第二服务器的游戏服务器以及设置在该第二服务器或第三服务器上的补发***。其中，该实施例中的信息请求***的流程可以描述如下：

S602：用户向官网服务器发送领取道具的请求；

S604：官网服务器检查发送请求消息的用户的权限；

S606：若发送请求消息的用户具备领取权限，则官网服务器向游戏服务器发送道具发放请求，并跳到步骤S610；

S608：若发送请求消息的用户不具备领取权限，则向用户返回不具备权限的指示；

S610：若游戏服务器在接到该道具发放请求后，成功发送了对应的游戏道具，则向用户返回道具领取成功的指示；

S612：若游戏服务器在接到该道具发放请求后，未成功发送对应的游戏道具，则向补发***发起补发请求；

S614：若成功补发游戏道具，则向用户返回道具领取成功的指示；

S616：若补发次数达到或超过预定阈值仍未成功补发游戏道具，则向用户返回道具领取失败的指示。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的***，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可为个人计算机、服务器或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器（ROM，Read-OnlyMemory）、随机存取存储器（RAM，Random Access Memory）、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (14)

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

第一服务器接收用户发送的用于获取信息的请求消息；

所述第一服务器响应于所述请求消息判断所述用户是否具有获取所述信息的权限；

若是所述用户具有获取所述信息的权限，则所述第一服务器向第二服务器请求获取所述信息；

若所述第一服务器向所述第二服务器请求获取所述信息失败，则所述第一服务器向第三服务器请求补发所述信息；

若所述第一服务器向所述第三服务器请求补发所述信息成功，则所述第一服务器将从所述第三服务器中接收到的所述信息转发给所述用户。

2.根据权利要求1所述的方法，其特征在于，若所述第一服务器向所述第三服务器请求获取所述信息成功，则所述第一服务器将从所述第三服务器中接收到的所述信息转发给所述用户包括：

所述第一服务器在所述第三服务器设置的第一补发时间上获取所述第三服务器发送的所述信息；

所述第一服务器将从所述第三服务器中接收到的所述信息转发给所述用户。

3.根据权利要求1所述的方法，其特征在于，所述第一服务器向第三服务器请求补发所述信息包括：

所述第三服务器设置第一补发时间，并在所述第一补发时间上向所述第一服务器发送所述信息；

若所述第三服务器在所述第一补发时间上向所述第一服务器发送所述信息失败，则所述第三服务器判断当前补发所述信息的次数是否达到预定阈值；

若所述第三服务器判断出所述当前补发所述信息的次数未达到预定阈值，则所述第三服务器设置第二补发时间，并在所述第二补发时间上向所述第一服务器发送所述信息。

4.根据权利要求3所述的方法，其特征在于，若所述第三服务器判断出所述当前补发所述信息的次数未达到预定阈值，所述第一服务器向第三服务器请求补发所述信息包括：

所述第三服务器停止向所述第一服务器补发所述信息，并向用于管理所述信息的管理设备发送告警信息。

5.根据权利要求3所述的方法，其特征在于，所述第三服务器根据以下至少之一来设置所述第一补发时间和所述第二补发时间：

所述信息对应的业务类型；

所述第二服务器是否停止工作；

所述第三服务器的运行负荷。

6.根据权利要求1至5中任一项所述的方法，其特征在于，所述信息包括：用于指示游戏程序中的道具的信息。

7.根据权利要求6所述的方法，其特征在于，所述用于指示游戏程序中的道具的信息包括以下至少之一：游戏业务名、角色ID、道具ID、道具数量。

8.一种信息请求***，其特征在于，包括第一服务器、第二服务器和第三服务器，其中，所述第一服务器包括：

接收单元，用于接收用户发送的用于获取信息的请求消息；

第一判断单元，用于响应于所述请求消息判断所述用户是否具有获取所述信息的权限；

第一请求单元，用于在所述用户具有获取所述信息的权限时，向所述第二服务器请求获取所述信息；

第二请求单元，用于在所述第一服务器向所述第二服务器请求获取所述信息失败时，则所述第一服务器向所述第三服务器请求补发所述信息；

转发单元，用于在所述第一服务器向所述第三服务器请求补发所述信息成功时，将从所述第三服务器中接收到的所述信息转发给所述用户。

9.根据权利要求8所述的***，其特征在于，所述转发单元包括：

获取模块，用于在所述第一服务器向所述第三服务器请求获取所述信息成功时，在所述第三服务器设置的第一补发时间上获取所述第三服务器发送的所述信息；

转发模块，用于将从所述第三服务器中接收到的所述信息转发给所述用户。

10.根据权利要求8所述的***，其特征在于，所述第三服务器包括：

发送单元，用于设置第一补发时间，并在所述第一补发时间上向所述第一服务器发送所述信息；

第二判断单元，在所述发送单元在所述第一补发时间上向所述第一服务器发送所述信息失败时，判断当前补发所述信息的次数是否达到预定阈值；其中，

所述发送单元还用于在所述第三服务器判断出所述当前补发所述信息的次数未达到预定阈值时，设置第二补发时间，并在所述第二补发时间上向所述第一服务器发送所述信息。

11.根据权利要求10所述的***，其特征在于，所述第三服务器还包括：

告警单元，用于在所述第二判断单元判断出所述当前补发所述信息的次数达到所述预定阈值时，停止向所述第一服务器补发所述信息，并向用于管理所述信息的管理设备发送告警信息。

12.根据权利要求10所述的***，其特征在于，所述发送单元根据以下至少之一来设置所述第一补发时间和所述第二补发时间：

所述信息对应的业务类型；

所述第二服务器是否停止工作；

所述第三服务器的运行负荷。

13.根据权利要求8至12中任一项所述的***，其特征在于，所述信息包括：用于指示游戏程序中的道具的信息。

14.根据权利要求13所述的***，其特征在于，所述用于指示游戏程序中的道具的信息包括以下至少之一：游戏业务名、角色ID、道具ID、道具数量。