CN107861825A - 请求处理/状态码查询方法及装置、下/上游节点、介质 - Google Patents

Abstract

本公开提供请求处理方法、下游节点、上游节点、状态码查询方法、计算机可读介质、请求处理装置和状态码查询装置。请求处理方法是用在包含上游节点和下游节点的系统中在下游节点处执行的请求处理方法，包括如下操作：从所述上游节点接收请求；执行接收的所述请求，并生成请求状态记录，所述请求状态记录包括是否成功的标识，所述标识表示所述请求执行成功或者失败；在根据所述请求状态记录中的所述标识而确认为所述请求失败的情况下，将该失败请求插入到用于记录失败的请求的失败重试队列；和对插入到所述失败重试队列中的失败请求进行重试。

Description

请求处理/状态码查询方法及装置、下/上游节点、介质

技术领域

本公开涉及互联网技术领域，更具体地，涉及请求处理方法、下游节点、上游节点、状态码查询方法、计算机可读介质、请求处理装置和状态码查询装置。

背景技术

近年来，随着网络技术的发展和在各个领域应用的增加，网络信息爆炸式增长，越来越多的服务器面临高并发请求的问题。存在如下的场景：在互联网高并发请求的请求执行过程中，上游节点可能并不需要知道下游节点的执行结果，而只需要根据请求ID去查询该请求的最终执行状态。

所谓执行结果，用于记录每个节点执行成功或者失败的结果。该结果由请求处理方(接收到请求的下游节点)记录。所谓请求执行状态，用于跟踪每个请求执行到哪个环节，该系统中每层节点对应一个状态，表明一个请求执行到了哪一个节点，该状态由请求处理方(接收到请求的下游节点)记录。

在现有的请求处理中，上游节点必须以同步或异步的方式来等待下游节点返回请求响应数据。为了实现数据的请求和响应，在现有技术中，例如利用如下技术。其一，利用BSD Socket的编程接口配合select、epoll等多路并发机制实现数据请求和响应。其二，利用流行的网络库来实现相应请求。

若将现有技术的运用到上述场景中，则在上游节点调用下游节点的接口发起请求的过程中，同步的等待下游节点返回结果往往会占用了整个请求过程中很大一部分的时间，尤其是在高并发的系统中，对处理速度有着极高要求的情况下，这种等待会极大的影响整个系统的处理速度。

在实现本公开过程中，发明人发现现有技术中至少存在如下问题。其一，如果中间某个节点出错，不能及时定位到出错节点。其二，每次请求必须等待下游响应数据，网络耗时较大，影响处理速度。

公开内容

有鉴于此，本公开的一个方面提供一种请求处理方法，在包含上游节点和下游节点的系统中在下游节点处执行，该方法包括如下操作：从上游节点接收请求；执行接收的请求，并生成请求状态记录，请求状态记录包括是否成功的标识，标识表示请求执行成功或者失败；在根据请求状态记录中的标识而确认为请求失败的情况下，将该失败请求插入到用于记录失败的请求的失败重试队列；和对插入到失败重试队列中的失败请求进行重试。

根据本公开的实施例，每一个请求被分配有一个在系统中唯一标识该请求的全局请求标识码即全局请求ID，在请求状态记录中还包括全局请求ID和状态码，状态码用于跟踪每个请求执行到哪一层的下游节点。

根据本公开的实施例，全局请求ID是通用唯一识别码即UUID或数据库自增ID。

根据本公开的实施例，在生成请求状态记录时，采用分库分表方式将请求状态记录写到数据库。

根据本公开的实施例，进行重试包括：对失败重试队列进行轮询，以对请求进行重试。

根据本公开的实施例，在重试给定次数后仍不能成功的情况下，放弃重试。

本公开的另一方面提供了一种下游节点，是包含上游节点和下游节点的系统中的下游节点，包括：请求接收模块，用于从上游节点接收请求；请求状态记录生成模块，用于执行接收的请求，并生成请求状态记录，请求状态记录包括是否成功的标识，其中标识表示请求执行成功或者失败；失败请求插入模块，用于在根据请求状态记录中的标识而确认为请求失败的情况下，将该失败请求插入到用于记录失败的请求的失败重试队列；和重试模块，用于对插入到失败重试队列中的失败请求进行重试。

本公开的另一方面提供了一种状态码查询方法，在包含上游节点和下游节点的系统中在上游节点处执行，该方法包括如下操作：向下游节点发出请求，对每一个请求分配一个在系统中唯一标识该请求的全局请求ID；根据全局请求ID查询状态码，全局请求ID和状态码包含于在下游节点处生成的请求状态记录中，状态码用于跟踪每个请求执行到哪一层的下游节点。

本公开的另一方面提供了一种上游节点，是包含上游节点和下游节点的系统中的上游节点，包括：请求发送模块，用于向下游节点发出请求，对每一个请求分配一个在系统中唯一标识该请求的全局请求ID；状态码查询模块，根据全局请求ID来查询状态码，全局请求ID和状态码包含于在下游节点处生成的请求状态记录中，状态码用于跟踪每个请求执行到哪一层的下游节点。

本公开的另一方面提供了一种计算机可读介质，其上存储有可执行指令，该指令被处理器执行时根据上述任一项记载的方法。

本公开的另一方面提供了一种请求处理装置，其包括：一个或多个处理器；存储装置，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行上述的请求处理方法。

本公开的另一方面提供了一种状态码查询装置，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行上述的状态码查询方法。

根据本公开的实施例，可以至少部分地解决本公开的技术问题，因此可以达成以下效果：能在高并发系统中加快处理速度，极大的提高了系统的吞吐量，并能快速定位到出错节点，快速跟踪请求失败的环节和失败原因，便于排查问题。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出本公开实施例的系统架构图。

图2示意性示出本公开实施例的请求处理方法的流程图。

图3示意性示出本公开实施例的状态码查询方法的流程图。

图4示意性示出本公开实施例的分库分表架构。

图5示意性示出现有技术中的系统架构图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。这里使用的词语“一”、“一个(种)”和“该”等也应包括“多个”、“多种”的意思，除非上下文另外明确指出。此外，在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在现有请求处理中，例如如图5所示那样，在由上游节点A、下游节点B和下游节点C构成的系统中，上游节点必须以同步或异步的方式来等待下游节点返回请求响应数据。

因此若将图5的架构运用在“互联网高并发请求的请求执行过程中，上游节点可能并不需要知道下游节点的执行结果，而只需要根据请求ID去查询该请求的最终执行状态”这样的场景中，就会出现如下的问题。

其一，如果中间某个节点出错，不能及时定位到出错节点。

其二，每次请求必须等待下游响应数据，网络耗时较大，影响处理速度。

本公开的实施例提供一种请求处理方法和系统、以及计算机可读介质。在该方法中，上游节点可能并不需要知道下游节点的执行结果，而只需要根据请求ID去查询该请求的最终执行状态。

图1示意性示出本公开实施例的系统架构图。

如图1所示那样，在本公开实施例的系统架构中，上游节点向下游节点发出请求，由下游节点执行请求，上游节点不等待来自下游节点的响应，根据需要查询请求状态记录R，获得请求的执行状态，下游节点将失败的请求插入到失败重试队列L中，并进行轮询，在超过给定重试次数以后，放弃重试。

在本说明书中，“上游”和“下游”是相对的概念，例如下游节点B相对于上游节点A处于下游，但相对于下游节点C则可视作上游节点。更具体地，对于同一请求而言，请求发出方是“上游节点”，而请求执行方是“下游节点”。同样地，一个节点既可以是某一节点的“下游节点”，也可以是另一节点的“上游节点”。也即，一个请求可以逐级发送到不同节点，每一节点可以至少部分地执行该请求。于是，可以存在分级的系统架构。

在图1中示出了三层且各层节点为一个的示例，但本公开并不限于此，在实际的应用场景中，层的数目以及各层的节点的数量都可以为多个。

图2示意性示出本公开实施例的请求处理方法的流程图。

在操作S1中，从上游节点向下游节点发出请求，系统对每一个请求分配一个全局请求标识码(ID)，能根据该ID来对请求进行追踪。该全局请求ID表征在系统中唯一标识该请求。

全局请求ID要保证每次生成的ID不能重复，实现ID生成器的办法有很多，说明书中列举了常见的几种方法。

(1)UUID(Universally Unique Identifier，通用唯一识别码)生成器。算法的核心思想是结合机器的网卡、当地时间、一个随机数来生成UUID。该方法的优势是本地生成ID，不需要进行远程调用，时延低，扩展性好，基本可以认为没有性能上限。但是UUID过长，往往用字符串表示，作为主键建立索引查询效率低。

(2)基于数据库事务操作的方法。每次请求向数据库读取一个ID，读取完毕将数据库ID加1，该过程需要事务来保证不产生脏数据。因为事务操作比较耗资源，每次可以读取一段ID区间，缓存在本地，从而降低数据库的操作次数，提升性能。

在操作S2中，在接收请求的下游节点执行请求，并生成请求状态记录R。

该请求状态记录R在下游节点对请求进行执行的过程中生成，在该请求状态记录R中，记录了全局请求ID、状态码和是否成功标识。这里需要指出的是，对于请求的执行，不仅可以包括节点自身执行请求中所指示的至少部分操作，而且还可以包括向更下游的节点转发请求。

该状态码表示请求的执行状态，每一层节点对应一个状态码，该是否成功标识表示执行结果。

根据全局请求ID找到相应的请求状态记录R，就能知道一次请求的具体的执行状态，并能知道该请求是否被执行成功。

对于高并发的系统，需要存储和查询的流水数据量十分巨大，对数据库的读写性能要求很高，可以采用分库分表的方式提高性能。可以将每条记录先存在小文件中，然后开启专门的进程将数据写入到数据库中。

关于分库分表的具体架构，例如如图4所示那样。来自节点的数据按照箭头的方向，经过汇总而写到分库分表流水数据库中。

在操作S3中，根据请求状态记录R来判断请求是否成功。具体地，在接收请求的下游节点(处理请求的节点)中，根据记录中的是否成功标识来判断请求是否被成功执行。

若在操作S3中判断为请求成功“是”，则结束流程。

若在操作S3中判断为请求不成功“否”，则前进到操作S4。

在操作S4中，接收请求的下游节点(处理请求的节点)将失败的请求插入到失败重试队列L。

该失败重试队列L是缓存队列，用来记录失败的请求。

在操作S5中，每个下游节点开启一个定时器，对失败重试队列L进行轮询，定期扫描该失败重试队列L，对请求进行重试。

在操作S6中，判断重试次数是否达到给定次数。

若在操作S6中判断为重试未达到给定次数“否”，则回到操作S5，重复扫描该失败重试队列L，对请求进行重试。

若在操作S6中判断为重试达到给定次数“是”，则前进到操作S7。

在操作S7中，将失败原因写入流水，放弃重试。

根据本公开的请求处理方法，极大的提高了系统的吞吐量。

图3示意性示出本公开实施例的状态码查询方法的流程图。

在“互联网高并发请求的请求执行过程中，上游节点可能并不需要知道下游节点的执行结果，而只需要根据请求ID去查询该请求的最终执行状态”这样的场景中，按照图3所示的流程图执行操作。其中，与图2中标号相同的操作表示相同的操作，省略详细的说明。

在操作S1中，系统对每一个请求分配一个全局请求ID。在操作S2中，在接收请求的下游节点执行请求，并生成请求状态记录R。

在操作S8中，上游节点通过根据全局请求ID来查询相应的请求状态记录R，从而查询状态码。

由于不需要等待下游响应数据，根据全局请求ID就能查询到状态码，因此处理速度快。

由于在请求状态记录R中记录了每次请求的流水，因此根据全局请求ID即可方便地查询请求状态，可以快速跟踪请求失败的环节和失败原因，便于排查问题。

另外，本公开还能由包含执行上述请求处理方法或上述状态码查询方法的模块的装置来实现。

根据该装置，能实现与上述请求处理方法或上述状态码查询方法相同的功能效果。

另外，本公开还能通过用所含的处理器执行上述请求处理方法或上述状态码查询方法的装置来实现。

根据该装置，能实现与上述请求处理方法或上述状态码查询方法相同的功能效果。

另外，本公开还能由计算机可读介质实现，该计算机可读介质存储指令，该指令被处理器执行时使处理器作为执行上述请求处理方法或上述状态码查询方法的模块发挥功能。

根据该计算机可读介质，能实现与上述请求处理方法相同的功能效果。

需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (12)

1.一种请求处理方法，在包含上游节点和下游节点的系统中在下游节点处执行，该请求处理方法包括如下操作：

从所述上游节点接收请求；

执行接收的所述请求，并生成请求状态记录，所述请求状态记录包括是否成功的标识，所述标识表示所述请求执行成功或者失败；

在根据所述请求状态记录中的所述标识而确认为所述请求失败的情况下，将该失败请求插入到用于记录失败的请求的失败重试队列；和

对插入到所述失败重试队列中的失败请求进行重试。

2.根据权利要求1所述的请求处理方法，其中，

每一个所述请求被分配有一个在所述系统中唯一标识该请求的全局请求标识码即全局请求ID，

在所述请求状态记录中还包括所述全局请求ID和状态码，

所述状态码用于跟踪每个所述请求执行到哪一层的所述下游节点。

3.根据权利要求2所述的请求处理方法，其中，

所述全局请求ID是通用唯一识别码即UUID或数据库自增ID。

4.根据权利要求1或2所述的请求处理方法，其中，

在生成所述请求状态记录时，采用分库分表方式将所述请求状态记录写到数据库。

5.根据权利要求1所述的请求处理方法，其中，

进行重试包括：对所述失败重试队列进行轮询，以对请求进行重试。

6.根据权利要求1所述的请求处理方法，其中，

在重试给定次数后仍不能成功的情况下，放弃重试。

7.一种下游节点，是包含上游节点和下游节点的系统中的下游节点，包括：

请求接收模块，用于从所述上游节点接收请求；

请求状态记录生成模块，用于执行接收的所述请求，并生成请求状态记录，所述请求状态记录包括是否成功的标识，其中所述标识表示所述请求执行成功或者失败；

失败请求插入模块，用于在根据所述请求状态记录中的所述标识而确认为所述请求失败的情况下，将该失败请求插入到用于记录失败的请求的失败重试队列；和

重试模块，用于对插入到所述失败重试队列中的失败请求进行重试。

8.一种状态码查询方法，在包含上游节点和下游节点的系统中在上游节点处执行，该方法包括如下操作：

向所述下游节点发出请求，对每一个所述请求分配一个在所述系统中唯一标识该请求的全局请求ID；

根据所述全局请求ID查询所述状态码，所述全局请求ID和所述状态码包含于在所述下游节点处生成的请求状态记录中，所述状态码用于跟踪每个所述请求执行到哪一层的所述下游节点。

9.一种上游节点，是包含上游节点和下游节点的系统中的上游节点，包括：

请求发送模块，用于向所述下游节点发出请求，对每一个所述请求分配一个在所述系统中唯一标识该请求的全局请求ID；

状态码查询模块，根据所述全局请求ID来查询状态码，所述全局请求ID和所述状态码包含于在所述下游节点处生成的请求状态记录中，所述状态码用于跟踪每个所述请求执行到哪一层的所述下游节点。

10.一种计算机可读介质，其上存储有可执行指令，该指令被处理器执行时根据权利要求1-6和8中任一项所述的方法。

11.一种请求处理装置，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行权利要求1～6中任一项所述的请求处理方法。

12.一种状态码查询装置，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行权利要求8所述的状态码查询方法。