CN117176800A - Reverse proxy request processing method and device, electronic equipment and storage medium - Google Patents
Reverse proxy request processing method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN117176800A CN117176800A CN202311237327.6A CN202311237327A CN117176800A CN 117176800 A CN117176800 A CN 117176800A CN 202311237327 A CN202311237327 A CN 202311237327A CN 117176800 A CN117176800 A CN 117176800A
- Authority
- CN
- China
- Prior art keywords
- request
- reverse proxy
- coroutine
- target
- result
- 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.)
- Pending
Links
- 230000002441 reversible effect Effects 0.000 title claims abstract description 269
- 238000003672 processing method Methods 0.000 title claims abstract description 12
- 238000000034 method Methods 0.000 claims abstract description 91
- 230000008569 process Effects 0.000 claims abstract description 46
- 230000002618 waking effect Effects 0.000 claims abstract description 23
- 238000012545 processing Methods 0.000 claims description 57
- 230000000903 blocking effect Effects 0.000 claims description 7
- 238000004590 computer program Methods 0.000 claims description 5
- 239000002699 waste material Substances 0.000 description 11
- 238000010586 diagram Methods 0.000 description 10
- 238000011144 upstream manufacturing Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 5
- 238000013507 mapping Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 3
- 238000012958 reprocessing Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
Landscapes
- Computer And Data Communications (AREA)
Abstract
The application provides a reverse proxy request processing method, a device, electronic equipment and a storage medium, wherein the method comprises the following steps: storing the received reverse proxy request to a pre-generated message queue; creating a target coroutine to enable the target coroutine to acquire a reverse proxy request from a message queue and process the reverse proxy request; updating the state of the target coroutine to wait; after receiving the request result corresponding to the reverse proxy request, waking up the target coroutine, so that the target coroutine sends the request result to the corresponding requester. When a request enters a proxy service, a target protocol Cheng Quchu is created to handle the request, and the current target protocol is blocked until the request result is obtained, the target protocol is awakened, and the target protocol returns the request result to the requesting party. The method and the device realize that the request result is acquired in one request period in the reverse proxy service scene, and improve the effectiveness and efficiency of the acquired result.
Description
Technical Field
The present application relates to the field of data processing, and in particular, to a method and apparatus for processing a reverse proxy request, an electronic device, and a storage medium.
Background
Reverse proxy refers to a process in which a proxy server obtains resources from one or more groups of backend servers associated with the proxy server according to a request of an upstream client, and then returns the resources to the upstream, and the upstream client only knows the IP address of the proxy server, but cannot learn the server cluster behind the proxy server. The existing reverse proxy scheme relies on an upstream asynchronous retry mechanism, namely after an upstream client sends a resource request, the resource received by a proxy server needs to be obtained by sending the request again at intervals, so that the efficiency is low and the effectiveness is poor.
Disclosure of Invention
The embodiment of the application aims at a reverse proxy request processing method, a device, electronic equipment and a storage medium, when a request enters proxy service, a target protocol Cheng Quchu is created to manage the request, a current target protocol is blocked until a request result is obtained, the target protocol is awakened, and the target protocol returns the request result to a requester. The method and the device realize that the request result is acquired in one request period in the reverse proxy service scene, and improve the effectiveness and efficiency of the acquired result.
In a first aspect, an embodiment of the present application provides a method for processing a reverse proxy request, including: storing the received reverse proxy request to a pre-generated message queue; creating a target coroutine to enable the target coroutine to acquire a reverse proxy request from a message queue and process the reverse proxy request; updating the state of the target coroutine to wait; after receiving the request result corresponding to the reverse proxy request, waking up the target coroutine, so that the target coroutine sends the request result to the corresponding requester.
In the implementation process, when the request enters the proxy service, the target protocol Cheng Quchu is created to process the request, and blocks the current target protocol until the request result is obtained, wakes up the target protocol, and returns the request result to the requester. The method and the device realize that the request result is acquired in one request period in the reverse proxy service scene, and improve the effectiveness and efficiency of the reverse proxy request processing.
Optionally, in an embodiment of the present application, after receiving a request result corresponding to a reverse proxy request, waking up a target coroutine includes: receiving a request result sent by a front-end service; the request result is generated after the front-end service pulls and processes the reverse proxy request in the message queue; storing the request result to a ready set queue; and waking up the target coroutine, and acquiring a request result corresponding to the reverse proxy request from the ready set queue through the target coroutine.
In the implementation process, the target coroutine acquires the request result corresponding to the reverse proxy request from the ready set queue, and returns the request result to the corresponding requester, so that the requester can acquire the request result after one request, and the operation efficiency is improved.
Optionally, in the embodiment of the present application, waking up a target coroutine, and obtaining, by the target coroutine, a request result corresponding to a reverse proxy request from a ready set queue, including: obtaining a result identifier of a request result in a ready set queue; waking up all the coroutines to be determined by an inter-instance broadcasting method, and determining a target coroutine from the coroutines to be determined based on a result identifier; the cooperative distance to be determined is the cooperative distance corresponding to each reverse proxy request in the multiple reverse proxy requests; and acquiring a request result corresponding to the reverse proxy request from the ready set queue through the target coroutine.
In the implementation process, the reverse proxy service program can accept a plurality of reverse proxy requests sent by a plurality of clients, and corresponding reverse proxy service programs are not required to be set for each client or each three-party platform respectively, so that the service performance is improved, and the resource waste is reduced. And the request result are corresponding by setting the request identifier and the result identifier, so that the request processing efficiency and the request processing accuracy are improved.
Optionally, in an embodiment of the present application, waking up all the to-be-determined coroutines by an inter-instance broadcasting method, and determining, from the to-be-determined coroutines, a target coroutine based on a result identifier, including: communicating with all the coroutines to be determined through an inter-instance broadcasting method, and matching the request identification of the reverse proxy request corresponding to each coroutine to be determined with the result identification; the request mark of the reverse proxy request is preset; and if the request identifier is matched with the result identifier, determining the to-be-determined coroutine as the target coroutine.
In the implementation process, the request identifier of one reverse proxy request and the result identifier of the request result corresponding to the reverse proxy request have a unique mapping relationship, and the reverse proxy request processed correspondingly by the coroutine is associated with the request result according to the result identifier, so that the reverse proxy service program can accept a plurality of reverse proxy requests sent by a plurality of clients, the service performance is improved, and the resource waste is reduced.
Optionally, in an embodiment of the present application, creating the target coroutine includes: acquiring a request identifier from a reverse proxy request; inquiring a preset database based on the request identification; if the database comprises the request identifier, acquiring a request state field of the reverse proxy request, and processing the reverse proxy request based on the request state field; the request state field is used for representing the processing state of the reverse proxy request; if the database does not include the request identification, a target coroutine is created.
In the implementation process, the preset database is queried based on the request identification, and further processing is performed according to the query result, so that the situation of resource waste caused by reprocessing the reverse proxy request with the acquired result is improved.
Optionally, in an embodiment of the present application, processing the reverse proxy request based on the request status field includes: judging whether the reverse proxy request acquires a corresponding request result or not based on the request state field; if the corresponding request result is acquired, confirming whether the reverse proxy request needs retry or not, updating the request state field to an initial state under the condition that the retry is needed, and creating a target coroutine; the initial state is used for representing that the processing state of the reverse proxy request is that the corresponding request result is not acquired; under the condition that retry is not needed, the request result is sent to the corresponding requester; if the corresponding request result is not acquired, a target coroutine is created.
In the implementation process, according to the request status field, whether the reverse proxy request obtains the corresponding request result can be judged, and further corresponding processing is performed according to the condition that each request obtains the request result, so that the processing controllability of the data request is improved, and the condition that the reverse proxy request with the obtained result is reprocessed to cause resource waste is improved. And the request state field can be updated according to the processing state of the request, so that the processing state of each reverse proxy request can be conveniently obtained, and the management capability of the reverse proxy request is improved.
Optionally, in an embodiment of the present application, storing the received reverse proxy request in a pre-generated message queue includes: acquiring reverse proxy requests initiated by a plurality of requesters, and adding corresponding request identifiers for each reverse proxy request; and storing the received reverse proxy request to the tail of the message queue so that the front-end service pulls the reverse proxy request from the head of the message queue in batches and processes the reverse proxy request.
In the implementation process, a corresponding request identifier is added for each reverse proxy request, so that the reverse proxy service program can receive and distinguish the reverse proxy requests sent by a plurality of requesters, and resources are saved. The front-end service pulls the reverse proxy request from the first queue of the message queue in batches, so that the efficiency of request processing is improved.
In a second aspect, an embodiment of the present application further provides a reverse proxy request processing apparatus, including: the receiving request module is used for storing the received reverse proxy request to a pre-generated message queue; the creating coroutine module is used for creating a target coroutine so that the target coroutine obtains a reverse proxy request from the message queue and processes the reverse proxy request; the blocking coroutine module is used for updating the state of the target coroutine to wait; and the wake-up coroutine module wakes up the target coroutine after receiving a request result corresponding to the reverse proxy request, so that the target coroutine transmits the request result to a corresponding requester.
In a third aspect, an embodiment of the present application further provides an electronic device, including: a processor and a memory storing machine-readable instructions executable by the processor to perform the method as described above when executed by the processor.
In a fourth aspect, embodiments of the present application also provide a computer readable storage medium having stored thereon a computer program which, when executed by a processor, performs the method described above.
When the request enters the proxy service, the target protocol Cheng Quchu is created to process the request, the current target protocol is blocked until the request result is obtained, the target protocol is awakened, and the request result is returned to the requester by the target protocol. The method and the device realize that the request result is acquired in one request period in the reverse proxy service scene, and improve the effectiveness and efficiency of the acquired result.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and should not be considered as limiting the scope, and other related drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a prior art reverse proxy request processing method;
FIG. 2 is a flowchart of a reverse proxy request processing method according to an embodiment of the present application;
FIG. 3 is a schematic diagram of a technical architecture provided in an embodiment of the present application;
FIG. 4 is a flow chart of a request processing provided in an embodiment of the present application;
FIG. 5 is a schematic diagram of a reverse proxy request processing apparatus according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
Embodiments of the technical scheme of the present application will be described in detail below with reference to the accompanying drawings. The following examples are only for more clearly illustrating the technical aspects of the present application, and thus are merely examples, and are not intended to limit the scope of the present application.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.
In the description of embodiments of the present application, the technical terms "first," "second," and the like are used merely to distinguish between different objects and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated, a particular order or a primary or secondary relationship. In the description of the embodiments of the present application, the meaning of "plurality" is two or more unless otherwise specifically defined.
In the reverse proxy service scenario, the upstream client only knows the IP address of the proxy server, but does not know the existence of the server cluster behind the proxy server, i.e. the last-week client does not need to directly communicate with the back-end server, so that the security of data is ensured to a certain extent.
Please refer to the prior art reverse proxy request processing method shown in fig. 1.
In some industries or areas, such as the internet banking industry, requesting a third party data source by a third party service provider's bank may present a potential security compliance risk. To ensure compliance, data acquisition may be performed through a reverse proxy service. The reverse proxy can be composed of two parts, wherein one part is a proxy service deployed in a three-party service provider to receive a data request of an upstream client; the other part is a front-end service deployed in the row to interface with the off-row number platform to acquire a data source.
When a requester needs to request a three-party data source, a proxy server is requested first, then the proxy server performs network interaction with a front-end service in a row to obtain a data result, and the data result is returned to the proxy server. After the requester sends a request for a certain time interval, the requester asynchronously inquires the request state from the proxy server again, and if the proxy server already acquires the data result, the requester also acquires the data result through the asynchronous request; if the proxy server has not yet obtained the data result, the requestor needs to obtain the request result again through the asynchronous query after a certain time interval.
That is, in the process of acquiring data by using the reverse proxy service in the prior art, a requester needs to send at least two requests to acquire a data result, that is, the data result cannot be acquired in one request, so that the efficiency of the data request is lower and the effectiveness is poor.
When a request enters proxy service, a target protocol Cheng Quchu is created to manage the request, and the current target protocol is blocked until a request result is obtained, the target protocol is awakened, and the request result is returned to a requester by the target protocol. The method and the device realize that the request result is acquired in one request period in the reverse proxy service scene, and improve the effectiveness and efficiency of the acquired result.
Fig. 2 is a schematic flow chart of a reverse proxy request processing method according to an embodiment of the present application. The reverse proxy request processing method provided by the embodiment of the application can be applied to a reverse proxy service program, the reverse proxy service program can be deployed in electronic equipment, and the electronic equipment can comprise a terminal and a server; the terminal can be a smart phone, a tablet computer, a personal digital assistant (Personal Digital Assitant, PDA) and the like; the server may be a reverse proxy server, an application server, or a Web server. The reverse proxy request processing method may include:
Step S110: the received reverse proxy request is stored to a pre-generated message queue.
Step S120: and creating a target coroutine, so that the target coroutine obtains the reverse proxy request from the message queue and processes the reverse proxy request.
Step S130: updating the state of the target coroutine to wait.
Step S140: after receiving the request result corresponding to the reverse proxy request, waking up the target coroutine, so that the target coroutine sends the request result to the corresponding requester.
In step S110, the reverse proxy request may be a request for acquiring data transmitted by the data requester, and the reverse proxy server stores the reverse proxy request to a pre-generated message queue after receiving the reverse proxy request. The message queue may be Redis, kafka or RabbitMQ, etc.
In step S120, after receiving the reverse proxy request and storing the reverse proxy request in the message queue, a target coroutine is created, which is used to obtain the reverse proxy request from the message queue and process the reverse proxy request.
Coroutine is also a program component, and is a lightweight thread in user mode, unlike threads and processes, which require context switching on the system kernel, which is determined by the developer. The advantage of co-threading is that they can be implemented concurrently in a single thread, and that their creation and destruction costs are much lower than threads.
In step S130, after the target coroutine is created, under the condition that the request result corresponding to the reverse proxy request is not received, the state of the target coroutine is updated to wait, that is, the coroutine initiates coroutine blocking operation in the executing process, after coroutine blocking, the reverse proxy request and the target coroutine processing the reverse proxy request become a "waiting" state, and "waiting" can be understood as waiting for program wakeup. It should be noted that, the coroutine in the waiting state does not occupy system resources such as CPU and network resources.
As an embodiment, the Wait method of the Cond structure in the Sync packet of Golang (go language) may be used as a tool for coroutine blocking, and the state of the target coroutine may be updated to Wait.
In step S140, after the reverse proxy service program obtains the request result corresponding to the reverse proxy request, the target coroutine is awakened, so that the target coroutine continues to process the reverse proxy request, and the request result is sent to the corresponding requester. It will be appreciated that other processing may be performed on the request result after waking up the target coroutine, for example, the received request result may be converted into a message format, or a status code of the returned message may be determined, to confirm whether the request result is received, or the like.
As an embodiment, the wake target coroutine step may be implemented by using the Broadcast method of the Cond structure in the Sync packet of Golang.
In the implementation process, when the request enters the proxy service, the target protocol Cheng Quchu is created to process the request, and blocks the current target protocol until the request result is obtained, wakes up the target protocol, and returns the request result to the requester. The method and the device realize that the request result is acquired in one request period in the reverse proxy service scene, and improve the effectiveness and efficiency of the acquired result.
Optionally, in an embodiment of the present application, after receiving a request result corresponding to a reverse proxy request, waking up a target coroutine includes: receiving a request result sent by a front-end service; the request result is generated after the front-end service pulls and processes the reverse proxy request in the message queue; storing the request result to a ready set queue; and waking up the target coroutine, and acquiring a request result corresponding to the reverse proxy request from the ready set queue through the target coroutine.
In the specific implementation process: after the reverse proxy request is stored in the message queue, the front-end service can pull the reverse proxy request in the message queue according to the preset period, and the pulling request can be pulled one by one or in batches. The front-end service can comprise a bank front-end processor, a dealer front-end processor or a telecommunication front-end processor, and the like, and the industry of the front-end service generally has higher safety of data interaction, and the front-end service has the function of carrying out data exchange with an in-line and out-line data platform and a three-party data source, so that external applications are prevented from directly accessing core services of the front-end service, such as various interfaces of a bank, and the like, and the safety of data interaction is improved.
After the front-end service pulls the reverse proxy request, the front-end service processes the reverse proxy request, obtains a request result according to the content of the reverse proxy request by a corresponding platform, and sends the obtained request result to the reverse proxy service program. The reverse proxy service program receives the request result sent by the front-end service and stores the request result into the ready set queue. The ready set queue may be a Redis message queue, a Kafka message queue, a RabbitMQ message queue, or the like.
The target coroutine is awakened, a request result corresponding to the reverse proxy request is obtained from the ready set queue through the target coroutine, and the request result is returned to the corresponding requester, so that the requester can obtain the request result in one request.
In the implementation process, after the request result sent by the front-end service is obtained and stored in the ready set queue, the target cooperative program is awakened, the request result corresponding to the reverse proxy request is obtained from the ready set queue, and the request result is returned to the corresponding requester, so that the requester can obtain the request result after one request, and the operation efficiency is improved.
Optionally, in the embodiment of the present application, waking up a target coroutine, and obtaining, by the target coroutine, a request result corresponding to a reverse proxy request from a ready set queue, including: obtaining a result identifier of a request result in a ready set queue; waking up all the coroutines to be determined by an inter-instance broadcasting method, and determining a target coroutine from the coroutines to be determined based on a result identifier; the cooperative distance to be determined is the cooperative distance corresponding to each reverse proxy request in the multiple reverse proxy requests; and acquiring a request result corresponding to the reverse proxy request from the ready set queue through the target coroutine.
In the specific implementation process: in the prior art, each tenant corresponds to a single-instance proxy service, and a corresponding reverse proxy service program is required to be set for each client or each three-party platform respectively. The method has the defects of low service performance, server resource waste and the like.
The reverse proxy service program in the embodiment of the application can accept a plurality of reverse proxy requests sent by a plurality of clients, and the plurality of reverse proxy requests can be used for requesting data of different three-party platforms. And the corresponding reverse proxy service program is not required to be set for each client or each three-party platform respectively, so that the service performance is improved, and the resource waste is reduced.
And setting a request identifier and a result identifier, wherein the request identifier and the request result identifier correspond to each other, specifically, for example, the result identifier of the request result in the ready set queue is obtained, and the result identifier is set according to the request identifier of the reverse proxy request corresponding to the request result. I.e. a request identifier of a reverse proxy request, and a result identifier of a request result corresponding to the reverse proxy request have a unique mapping relationship. Thus, the reverse proxy request processed by the coroutine can be associated with the request result according to the result identification of the request result in the ready set queue, so as to determine that the request result is the result corresponding to one request.
After the request result is obtained, all the coroutines to be determined are awakened through an inter-instance broadcasting method, wherein the coroutines to be determined are coroutines respectively corresponding to each reverse proxy request in a plurality of reverse proxy requests, namely, the coroutines corresponding to each reverse proxy request in the message queue are all used as coroutines to be determined.
The reverse proxy request corresponding to each to-be-determined coroutine has a request identifier, so that the target coroutine can be determined from the to-be-determined coroutines based on the result identifier and the request identifier, that is, the currently returned request result is the result corresponding to the request which is being processed by the target coroutine. After the target coroutine is determined, a request result corresponding to the reverse proxy request is obtained from the ready set queue through the target coroutine.
In the implementation process, the reverse proxy service program can accept a plurality of reverse proxy requests sent by a plurality of clients, and corresponding reverse proxy service programs are not required to be set for each client or each three-party platform respectively, so that the service performance is improved, and the resource waste is reduced. And the request result are corresponding by setting the request identifier and the result identifier, so that the request processing efficiency and the request processing accuracy are improved.
Please refer to fig. 3, which illustrates a schematic diagram of a technical architecture provided by an embodiment of the present application.
Optionally, in an embodiment of the present application, waking up all the to-be-determined coroutines by an inter-instance broadcasting method, and determining, from the to-be-determined coroutines, a target coroutine based on a result identifier, including: communicating with all the coroutines to be determined through an inter-instance broadcasting method, and matching the request identification of the reverse proxy request corresponding to each coroutine to be determined with the result identification; the request mark of the reverse proxy request is preset; and if the request identifier is matched with the result identifier, determining the to-be-determined coroutine as the target coroutine.
In the specific implementation process: the inter-instance broadcast method is a mechanism for transmitting information between programs or coroutines by communicating with all the coroutines to be determined. As an embodiment, pub/sub (subscription and publication) of Redis may be used as an inter-instance broadcaster. After communication, all the to-be-determined coroutines acquire the result identification of the request result returned by the front-end service.
Each to-be-determined coroutine matches the request identifier corresponding to the reverse proxy request processed by each to-be-determined coroutine with the result identifier of the request result returned by the front-end service, wherein the request identifier corresponding to the reverse proxy request can be preset, for example, after receiving the request sent by the requester, the corresponding request identifier can be set for different requests.
If the request identifier is matched with the result identifier, the to-be-determined coroutine is determined as the target coroutine, and in the above embodiment, the request identifier of a reverse proxy request and the result identifier of the request result corresponding to the reverse proxy request have a unique mapping relationship, and the matching can be understood as that the request identifier and the request result have a mapping relationship, or the request identifier and the request result are the same, and the like, and the matched coroutine to be determined is determined as the target coroutine.
In the implementation process, the request identifier of one reverse proxy request and the result identifier of the request result corresponding to the reverse proxy request have a unique mapping relationship, and the reverse proxy request processed correspondingly by the coroutine is associated with the request result according to the result identifier, so that the reverse proxy service program can accept a plurality of reverse proxy requests sent by a plurality of clients, the service performance is improved, and the resource waste is reduced.
Optionally, in an embodiment of the present application, creating the target coroutine includes: acquiring a request identifier from a reverse proxy request; inquiring a preset database based on the request identification; if the database comprises the request identifier, acquiring a request state field of the reverse proxy request, and processing the reverse proxy request based on the request state field; the request state field is used for representing the processing state of the reverse proxy request; if the database does not include the request identification, a target coroutine is created.
In the specific implementation process: acquiring a request identifier from a reverse proxy request; the request identification may be set upon initial receipt of the reverse proxy request. And inquiring and searching in a preset database based on the request identifier, if the database comprises the request identifier, the reverse proxy request is not received for the first time, a request state field of the reverse proxy request can be acquired, and the reverse proxy request is processed based on the request state field. The request state field is used for representing the processing state of the reverse proxy request, so that the resource waste caused by reprocessing the reverse proxy request with the acquired result is avoided.
If the database does not contain the request identification, the reverse proxy request is a new request, a target coroutine is created, and the reverse proxy request is processed through the target coroutine.
As an alternative embodiment, if the request identifier cannot be obtained from the reverse proxy request, that is, the reverse proxy request does not include the request identifier, it may also be stated that the reverse proxy request is a "new" request, a target coroutine may be created, and the reverse proxy request is processed through the target coroutine.
In the implementation process, the preset database is queried based on the request identification, and further processing is performed according to the query result, so that the situation of resource waste caused by reprocessing the reverse proxy request with the acquired result is improved.
Optionally, in an embodiment of the present application, processing the reverse proxy request based on the request status field includes: judging whether the reverse proxy request acquires a corresponding request result or not based on the request state field; if the corresponding request result is acquired, confirming whether the reverse proxy request needs retry or not, updating the request state field to an initial state under the condition that the retry is needed, and creating a target coroutine; the initial state is used for representing that the processing state of the reverse proxy request is that the corresponding request result is not acquired; under the condition that retry is not needed, the request result is sent to the corresponding requester; if the corresponding request result is not acquired, a target coroutine is created.
In the specific implementation process: based on the request status field, it is determined whether the reverse proxy request obtains a corresponding request result. As one embodiment, a reverse proxy request may be made as a persistent store through the mysql database, and entering the reverse proxy service program will save a database record in the database. The reverse proxy request includes a request state field that may have a variety of enumerated values, such as initial state, in-process or final state, etc. The initial state can represent that the reverse proxy request has entered a message queue, and the processing state is that the corresponding request result is not acquired; during the processing, the reverse proxy request can be characterized as being pulled by the front-end service, and the processing result is not returned temporarily; the final state may characterize that the reverse proxy request has acquired the corresponding request result.
It will be appreciated that the request status field may be changed according to the processing status of the request, for example, when the request enters the request queue, the request status field is in an initial state; the request status field may be updated from the initial state to in-process when the reverse proxy request is pulled by the pre-service, i.e., dequeued.
According to the request status field in the above embodiment, it may be determined whether the reverse proxy request obtains the corresponding request result. If the corresponding request result is acquired, and the request of the reverse proxy is confirmed to need to be retried, the request state field is updated to be in an initial state, and a target coroutine is created so as to retry the reverse proxy request. If the corresponding request result is acquired and the reverse proxy request is confirmed not to need retry, the request result is sent to the corresponding requester; if the corresponding request result is not acquired, a target coroutine is created.
In the implementation process, according to the request status field, whether the reverse proxy request obtains the corresponding request result can be judged, and further corresponding processing is performed according to the condition that each request obtains the request result, so that the processing controllability of the data request is improved, and the condition that the reverse proxy request with the obtained result is reprocessed to cause resource waste is improved. And the request state field can be changed according to the processing state of the request, so that the processing state of each reverse proxy request can be conveniently obtained, and the management capability of the reverse proxy request is improved.
Optionally, in an embodiment of the present application, storing the received reverse proxy request in a pre-generated message queue includes: acquiring reverse proxy requests initiated by a plurality of requesters, and adding corresponding request identifiers for each reverse proxy request; and storing the received reverse proxy request to the tail of the message queue so that the front-end service pulls the reverse proxy request from the head of the message queue in batches and processes the reverse proxy request.
In the specific implementation process: and acquiring reverse proxy requests initiated by a plurality of requesters through a reverse proxy service program, adding a corresponding request identifier for each reverse proxy request, wherein the request identifier is used for identifying the corresponding reverse proxy request.
And storing the received reverse proxy request to the tail of the message queue, and when the front-end service pulls the reverse proxy request, pulling the reverse proxy request from the first queue of the message queue in batches and processing the pulled requests one by one.
In the implementation process, a corresponding request identifier is added for each reverse proxy request, so that the reverse proxy service program can receive and distinguish the reverse proxy requests sent by a plurality of requesters, and resources are saved. The front-end service pulls the reverse proxy request from the first queue of the message queue in batches, so that the efficiency of request processing is improved.
Referring to fig. 4, a flowchart of a request processing provided by an embodiment of the present application is shown.
In an alternative embodiment, a reverse proxy request is obtained, and a corresponding requestor service configuration is obtained, based on whether the request queries for a request record, if there is no request record, a request record is created, the request is added to a message queue, and a coroutine is created to handle the request, and coroutine is blocked. If the request record exists, judging whether a return result is received, if the return result is not received, creating a coroutine to process the request, and blocking the coroutine; and if the return result is received, directly sending the return result to the requester.
The in-line pre-service performs batch pulling on the requests in the message queue, and the requests after pulling are removed from the message queue. And processing the request pulled by the front-end service degree in the row to obtain a pushing result, pushing the request result to the reverse proxy service program in batches, broadcasting and waking all the examples, and determining the target coroutine. The reverse proxy service program puts the received request result into a ready set queue, and the target cooperative program obtains the request result from the thread set queue and returns the request result to the requester. If the returned result is not inquired, the request is ended, and an error reporting result is returned to the requester.
Referring to fig. 5, a schematic structural diagram of a reverse proxy request processing apparatus according to an embodiment of the present application is shown; the embodiment of the application provides a reverse proxy request processing device 200, which comprises:
a receiving request module 210, configured to store the received reverse proxy request in a pre-generated message queue;
a create coroutine module 220, configured to create a target coroutine, so that the target coroutine obtains a reverse proxy request from the message queue, and processes the reverse proxy request;
a blocking coroutine module 230, configured to update a state of the target coroutine to wait;
The wake-up co-procedure module 240 is configured to wake up the target co-procedure after receiving the request result corresponding to the reverse proxy request, so that the target co-procedure sends the request result to the corresponding requester.
Optionally, in the embodiment of the present application, the reverse proxy request processing device wakes up the coroutine module 240, and is further configured to receive a request result sent by the front-end service; the request result is generated after the front-end service pulls and processes the reverse proxy request in the message queue; storing the request result to a ready set queue; and waking up the target coroutine, and acquiring a request result corresponding to the reverse proxy request from the ready set queue through the target coroutine.
Optionally, in the embodiment of the present application, the reverse proxy request processing device wakes up the coroutine module 240, and is further configured to obtain a result identifier of a request result in the ready set queue; waking up all the coroutines to be determined by an inter-instance broadcasting method, and determining a target coroutine from the coroutines to be determined based on a result identifier; the cooperative distance to be determined is the cooperative distance corresponding to each reverse proxy request in the multiple reverse proxy requests; and acquiring a request result corresponding to the reverse proxy request from the ready set queue through the target coroutine.
Optionally, in the embodiment of the present application, the reverse proxy request processing device wakes up the coroutine module 240, and is further configured to communicate with all coroutines to be determined through an inter-instance broadcasting method, and match a request identifier of a reverse proxy request corresponding to each coroutine to be determined with a result identifier; the request mark of the reverse proxy request is preset; and if the request identifier is matched with the result identifier, determining the to-be-determined coroutine as the target coroutine.
Optionally, in the embodiment of the present application, the reverse proxy request processing device creates a coroutine module 220, configured to obtain a request identifier from a reverse proxy request; inquiring a preset database based on the request identification; if the database comprises the request identifier, acquiring a request state field of the reverse proxy request, and processing the reverse proxy request based on the request state field; the request state field is used for representing the processing state of the reverse proxy request; if the database does not include the request identification, a target coroutine is created.
Optionally, in the embodiment of the present application, the reverse proxy request processing device creates a coroutine module 220, configured to determine, based on the request status field, whether the reverse proxy request obtains a corresponding request result; if the corresponding request result is acquired, confirming whether the reverse proxy request needs retry or not, updating the request state field to an initial state under the condition that the retry is needed, and creating a target coroutine; the initial state is used for representing that the processing state of the reverse proxy request is that the corresponding request result is not acquired; under the condition that retry is not needed, the request result is sent to the corresponding requester; if the corresponding request result is not acquired, a target coroutine is created.
Optionally, in the embodiment of the present application, the reverse proxy request processing device receives a request module 210, configured to obtain reverse proxy requests initiated by multiple requesters, and add a corresponding request identifier for each reverse proxy request; and storing the received reverse proxy request to the tail of the message queue so that the front-end service pulls the reverse proxy request from the head of the message queue in batches and processes the reverse proxy request.
It should be understood that, the apparatus corresponds to the reverse proxy request processing method embodiment described above, and is capable of executing the steps involved in the method embodiment described above, and specific functions of the apparatus may be referred to the description above, and detailed descriptions are omitted herein as appropriate to avoid redundancy. The device includes at least one software functional module that can be stored in memory in the form of software or firmware (firmware) or cured in an Operating System (OS) of the device.
Please refer to fig. 6, which illustrates a schematic structural diagram of an electronic device according to an embodiment of the present application. An electronic device 300 provided in an embodiment of the present application includes: a processor 310 and a memory 320, the memory 320 storing machine-readable instructions executable by the processor 310, which when executed by the processor 310 perform the method as described above.
The embodiment of the application also provides a storage medium, wherein a computer program is stored on the storage medium, and the computer program is executed by a processor to execute the method.
The storage medium may be implemented by any type of volatile or nonvolatile Memory device or combination thereof, such as static random access Memory (Static Random Access Memory, SRAM), electrically erasable Programmable Read-Only Memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), erasable Programmable Read-Only Memory (Erasable Programmable Read Only Memory, EPROM), programmable Read-Only Memory (PROM), read-Only Memory (ROM), magnetic Memory, flash Memory, magnetic disk, or optical disk.
In the embodiments of the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. The apparatus embodiments described above are merely illustrative, for example, of the flowcharts and block diagrams in the figures that illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In addition, the functional modules in the embodiments of the present application may be integrated together to form a single part, or each module may exist alone, or two or more modules may be integrated to form a single part.
The foregoing description is merely an optional implementation of the embodiment of the present application, but the scope of the embodiment of the present application is not limited thereto, and any person skilled in the art may easily think about changes or substitutions within the technical scope of the embodiment of the present application, and the changes or substitutions are covered by the scope of the embodiment of the present application.
Claims (10)
1. A reverse proxy request processing method, comprising:
storing the received reverse proxy request to a pre-generated message queue;
creating a target coroutine to enable the target coroutine to acquire the reverse proxy request from the message queue and process the reverse proxy request;
updating the state of the target coroutine to wait;
and after receiving a request result corresponding to the reverse proxy request, waking up the target coroutine so that the target coroutine sends the request result to a corresponding requester.
2. The method of claim 1, wherein waking the target coroutine after receiving a request result corresponding to the reverse proxy request comprises:
receiving the request result sent by the front-end service; the request result is generated after the front-end service pulls and processes the reverse proxy request in the message queue;
storing the request result to a ready set queue;
and waking up the target coroutine, and acquiring a request result corresponding to the reverse proxy request from the ready set queue through the target coroutine.
3. The method of claim 2, wherein the waking the target coroutine, by which the request result corresponding to the reverse proxy request is obtained from the ready set queue, comprises:
obtaining a result identifier of the request result in the ready set queue;
waking up all to-be-determined coroutines by an inter-instance broadcasting method, and determining the target coroutines from the to-be-determined coroutines based on the result identification; the coroutine to be determined is a coroutine corresponding to each reverse proxy request in a plurality of reverse proxy requests;
And acquiring a request result corresponding to the reverse proxy request from the ready set queue through the target coroutine.
4. The method of claim 3, wherein the waking up all co-ordinates to be determined by an inter-instance broadcast method, determining the target co-ordinates from the co-ordinates to be determined based on the result identification, comprises:
communicating with all the to-be-determined coroutines through the inter-instance broadcasting method, and matching the request identifier of the reverse proxy request corresponding to each to-be-determined coroutine with the result identifier; wherein, the request mark of the reverse proxy request is preset;
and if the request identifier is matched with the result identifier, determining the to-be-determined coroutine as the target coroutine.
5. The method of claim 1, wherein creating the target coroutine comprises:
acquiring a request identifier from the reverse proxy request;
inquiring a preset database based on the request identification;
if the database comprises the request identifier, acquiring a request state field of the reverse proxy request, and processing the reverse proxy request based on the request state field; the request state field is used for representing the processing state of the reverse proxy request;
And if the request identification is not included in the database, creating the target coroutine.
6. The method of claim 5, wherein said processing said reverse proxy request based on said request status field comprises:
judging whether the reverse proxy request acquires the corresponding request result or not based on the request state field;
if the corresponding request result is acquired, confirming whether the reverse proxy request needs to be retried, updating the request state field to an initial state under the condition that the retry is needed, and creating the target coroutine; the initial state is used for representing that the processing state of the reverse proxy request is that a corresponding request result is not acquired; sending the request result to the corresponding requester without retry;
and if the corresponding request result is not acquired, creating the target coroutine.
7. The method of any of claims 1-6, wherein storing the received reverse proxy request to a pre-generated message queue comprises:
acquiring the reverse proxy requests initiated by a plurality of requesters, and adding corresponding request identifiers for each reverse proxy request;
And storing the received reverse proxy request to the tail of the message queue so that a front-end service pulls the reverse proxy request from the head of the message queue in batches and processes the reverse proxy request.
8. A reverse proxy request processing apparatus, comprising:
the receiving request module is used for storing the received reverse proxy request to a pre-generated message queue;
the creating coroutine module is used for creating a target coroutine so that the target coroutine obtains the reverse proxy request from the message queue and processes the reverse proxy request;
the blocking coroutine module is used for updating the state of the target coroutine to wait;
and the wake-up coroutine module wakes up the target coroutine after receiving a request result corresponding to the reverse proxy request, so that the target coroutine sends the request result to a corresponding requester.
9. An electronic device, comprising: a processor and a memory storing machine-readable instructions executable by the processor to perform the method of any one of claims 1 to 7 when executed by the processor.
10. A computer-readable storage medium, characterized in that it has stored thereon a computer program which, when executed by a processor, performs the method according to any of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311237327.6A CN117176800A (en) | 2023-09-22 | 2023-09-22 | Reverse proxy request processing method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311237327.6A CN117176800A (en) | 2023-09-22 | 2023-09-22 | Reverse proxy request processing method and device, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117176800A true CN117176800A (en) | 2023-12-05 |
Family
ID=88929772
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311237327.6A Pending CN117176800A (en) | 2023-09-22 | 2023-09-22 | Reverse proxy request processing method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117176800A (en) |
-
2023
- 2023-09-22 CN CN202311237327.6A patent/CN117176800A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108460115B (en) | Message pushing method and device, computer equipment and storage medium | |
| US7693892B2 (en) | NFS server, NFS server control program and NFS server control method | |
| CN110968478B (en) | Log acquisition method, server and computer storage medium | |
| CN104601702B (en) | Cluster remote procedure calling (PRC) method and system | |
| CN113127564B (en) | Parameter synchronization method and device | |
| CN112559558A (en) | Serial number generation method and device, computing device and storage medium | |
| CN109451078B (en) | Transaction processing method and device under distributed architecture | |
| CN106034113A (en) | Data processing method and data processing device | |
| US11283611B2 (en) | Token management apparatus and non-transitory computer readable medium storing token management program | |
| CN109388651B (en) | Data processing method and device | |
| CN109327499B (en) | Service interface management method and device, storage medium and terminal | |
| CN101189581B (en) | Techniques for handling lock-related inconsistencies | |
| CN111835809B (en) | Work order message distribution method, work order message distribution device, server and storage medium | |
| CN117176800A (en) | Reverse proxy request processing method and device, electronic equipment and storage medium | |
| CN111242621A (en) | Transaction data storage method, device, equipment and storage medium | |
| CN111405015B (en) | Data processing method, device, equipment and storage medium | |
| CN114036195A (en) | Data request processing method, device, server and storage medium | |
| CN113687962A (en) | Request processing method, device, equipment and storage medium | |
| CN109309583B (en) | Information acquisition method and device based on distributed system, electronic equipment and medium | |
| CN110209474B (en) | Task processing method and device | |
| US20140280347A1 (en) | Managing Digital Files with Shared Locks | |
| US20020083209A1 (en) | Method and system for registering binary data | |
| CN112019452B (en) | Method, system and related device for processing service requirement | |
| CN110896391A (en) | Message processing method and device | |
| CN115481386B (en) | Batch configuration system for target application use permission |
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 |