CN112653614A - Request processing method and device based on message middleware - Google Patents
Request processing method and device based on message middleware Download PDFInfo
- Publication number
- CN112653614A CN112653614A CN202011482834.2A CN202011482834A CN112653614A CN 112653614 A CN112653614 A CN 112653614A CN 202011482834 A CN202011482834 A CN 202011482834A CN 112653614 A CN112653614 A CN 112653614A
- Authority
- CN
- China
- Prior art keywords
- request
- message
- service
- request message
- client
- 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
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
- H04L51/18—Commands or executable codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/562—Brokering proxy services
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention discloses a request processing method and device based on message middleware, and relates to the technical field of computers. One specific implementation of the request processing method includes: inquiring whether business data related to the request message exists in a business database according to the request message sent by the client; if business data related to the request message exists in a business database, sending a response message to the client, wherein the response message carries the business data; otherwise, adding the request message into a message queue. By introducing the message middleware, the embodiment reduces the invalid overhead of polling the database by the server, saves network flow, and can avoid operation and maintenance pressure brought by polling the server by the client and resource waste caused by hanging of long polling connection requests by the server.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a request processing method and apparatus based on message middleware.
Background
With the development of information system frameworks such as the internet, distribution, componentization and the like, the interaction between the systems is more and more. When different systems interact, long polling or short polling is mostly adopted to process requests. In the short polling scenario, the server generally responds to the request immediately. In a long polling scenario, the service end polls the service database or a third party within a certain time (a set timeout time) so as to obtain service data in time. However, the above methods all cause an ineffective overhead of polling the database, and waste network traffic.
Disclosure of Invention
In view of this, embodiments of the present invention provide a request processing method and apparatus based on message middleware, which can solve the problem of invalid overhead of polling databases in the existing request processing manner.
To achieve the above object, according to an aspect of an embodiment of the present invention, a request processing method based on message middleware is provided.
The request processing method based on the message middleware comprises the following steps:
inquiring whether business data related to the request message exists in a business database according to the request message sent by the client;
if business data related to the request message exists in a business database, sending a response message to the client, wherein the response message carries the business data;
otherwise, adding the request message into a message queue.
Optionally, the request packet at least includes: a request data field and a public field; the request data field is used for indicating the request information of the request message of each request, and the public field is used for indicating the service framework control information.
Optionally, querying whether service data related to the request packet exists in a service database according to the request packet sent by the client includes:
acquiring request information from a request message sent by a client;
and inquiring whether the service data related to the request message exists in a service database according to the acquired request information.
Optionally, the request information at least includes: a channel code; adding the request message into a message queue comprises:
acquiring a channel code from the request information; the channel code is used for representing identification information of channels, and each channel is correspondingly provided with a message queue;
and adding the request message into a corresponding message queue according to the channel code.
Optionally, the public domain includes at least one or more of the following information: global tracking number, service code, service version number and message encryption information.
Optionally, the obtaining the request information from the request message sent by the client includes:
acquiring message encryption information from the public domain of the request message;
decrypting the request message according to the message encryption information;
and acquiring the request information from the request data field of the decrypted request message.
Optionally, the design parameters of the message queue include:
each channel is correspondingly provided with a message queue;
the channel code is a routing keyword;
the service data processing program is a producer;
the request processing program is a consumer;
a timeout time.
Optionally, after the step of adding the request packet to the message queue, the method further includes:
judging whether the service data is generated within a preset timeout period;
if yes, the service data is stored in the service database and a preset service table is updated; the service data is packaged according to a preset format and then sent to a message queue;
otherwise, returning an overtime message to the client, wherein the overtime message is used for indicating that the request message waits overtime.
Optionally, the service table includes one or more of the following information: service type, channel code, channel name, service data, processing status and processing result.
To achieve the above object, according to another aspect of the embodiments of the present invention, there is provided a request processing apparatus based on message middleware.
The request processing device based on the message middleware comprises the following components:
the query module is used for querying whether business data related to the request message exists in a business database according to the request message sent by the client;
a sending module, configured to send a response packet to the client if service data related to the request packet exists in a service database, where the response packet carries the service data;
and the message queue module is used for adding the request message into a message queue if the request message is not the message queue.
To achieve the above object, according to another aspect of the embodiments of the present invention, a server is provided.
The server of the embodiment of the invention comprises:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method as described above.
To achieve the above object, according to another aspect of an embodiment of the present invention, there is provided a computer-readable medium.
A computer-readable medium of an embodiment of the invention has stored thereon a computer program which, when executed by a processor, implements the method as described above.
One embodiment of the above invention has the following advantages or benefits:
in the embodiment of the invention, by introducing the message middleware, the invalid overhead of polling the database by the server is reduced, the network flow is saved, and the operation and maintenance pressure brought by polling the server by the client and the resource waste caused by hanging of long polling connection requests by the server can be avoided.
Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.
Drawings
The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:
fig. 1 is a flowchart illustrating a request processing method based on message middleware according to a first embodiment of the present invention;
FIG. 2 is a flowchart illustrating a request processing method based on message middleware according to a second embodiment of the present invention;
FIG. 3 is a block diagram of a request processing device based on message middleware according to an embodiment of the present invention;
FIG. 4 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;
FIG. 5 is a schematic block diagram of a computer system suitable for use with a client device or server that implements an embodiment of the invention.
Detailed Description
Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
Generally, in order to improve customer experience and meet the requirements of service quasi-real-time processing, a client may interact with a server in a short polling manner to obtain service data to be processed by the server. If the server side does not inquire the relevant data, the response is returned immediately. However, when a large number of clients concurrently request, on one hand, a large amount of network and computing resources are wasted due to small traffic, and on the other hand, stability and maintainability of the application server system are affected.
It can be understood that, in the case of short polling, because the traffic generated by the system is not large, a large number of clients do not poll the service data to be processed, and are in an idle state most of the time, the network and server resources are consumed, and the stability of the application system is also affected.
In addition, when the server processes the request, in order to reduce the pressure caused by frequent polling of the client, the server can adopt a long polling processing request. I.e. the request is suspended for a certain time, and if relevant service data is received or generated within the suspension time, a response is returned by means of inquiry. At this time, if there is service data, the result is not returned immediately, and if there is no service data, the result is not returned to the client immediately until the time is out. Thus, the number of requests from the client is greatly reduced. This means that network traffic is saved, after all, each time a request is sent, the upload traffic of the client and the download traffic of the server are occupied, and the dilemma that the server is always tired of receiving the request is solved. The same waste of resources results from long polling that suspends requests. If there are 100 client requests, the server will probably need to hang 100 threads, and will cause resource waste when continuously polling the database.
In order to solve the above problem, the service data can be obtained by using the service database and the message queue of the message middleware, and combining synchronous query and asynchronous reception when the service terminal processes the request. The implementation method can meet the requirement of service timeliness, saves the computing resources of the server, and can improve the processing capacity and service stability of the server.
Based on the above analysis, the embodiment of the present invention provides a request processing method based on a message middleware, which can introduce the message middleware at a server, indirectly respond to a request through a message queue, save computing resources of the server, and improve a concurrent request processing effect of the server. Fig. 1 is a flowchart illustrating a request processing method based on message middleware according to an embodiment of the present invention, and as shown in fig. 1, the request processing method includes steps S101 to S103 as follows.
Step S101: and inquiring whether business data related to the request message exists in a business database according to the request message sent by the client.
Before step S101, a server receives a communication request sent by a client, where the communication request carries a request packet, and the request packet at least includes: a request data field and a public field; the request data field is used for indicating the request information of the request message of each request, and the public field is used for indicating the service framework control information. Further, the public domain includes at least one or more of the following information: global tracking number, service code, service version number and message encryption information. The request message is exemplified as follows:
{
"data":{
"ChannelId":"03"
"CustId":""
"ProductId":""
"AccountNo":""
},
"com":{
"version":"1.0","globalReqNumber":"uuid",
"txCode":"queryBizInf",
"sysIsEncrypted":"0",
"sysEncryptType":""
}
}
it should be noted that the request packet is sent to the server by the client using an http/https Protocol, where the http (Hyper Text Transfer Protocol)/https (Hyper Text Transfer Protocol Secure) Protocol is a network Transfer Protocol. The client may send the request packet to the server through a GET method, where the GET method refers to submitting data through a URL (Uniform Resource Locator) at the client. The request message may be in JSON format and may be encoded and compiled by BASE64 in UTF-8 character set format. UTF-8 is a standard mechanism for converting wide character values to unicode byte streams. BASE64 encoding is an encoding scheme for transmitting 8-Bit byte codes.
In step S101, after receiving a request message sent by a client, a server may first obtain request information from the request message, where the request information may be understood as a specific parameter of each request. And then inquiring whether the service data related to the request message exists in a service database according to the acquired request information.
In order to query whether the service database has service data related to the request message, request information may be first obtained from a request message sent by a client. And then inquiring whether the service data related to the request message exists in a service database according to the acquired request information. Specifically, when obtaining the request message, the message encryption information may be obtained from the public domain of the request message first. And then, according to the message encryption information, decrypting the request message. And finally, acquiring the request information from the request data field of the decrypted request message.
Step S102: and if the service data related to the request message exists in the service database, sending a response message to the client, wherein the response message carries the service data.
In step S102, the response packet carries, in addition to the service data, a request data field, a public field, and the like. For example: channel code, global tracking number, service code, service version number, message encryption information and the like. The format example of the response message is as follows:
step S103: and if the service data related to the request message does not exist in the service database, adding the request message into a message queue.
In step S103, the request information refers to information related to a communication request of the client, and the request information at least includes: a channel code. When the request message is added into a message queue, a channel code can be obtained from the request message; the channel code is used for representing identification information of channels, and each channel is correspondingly provided with a message queue. And then adding the request message into a corresponding message queue according to the channel code.
It should be noted that, the design parameters of the message queue include:
1) each channel is correspondingly provided with a message queue, for example: the channels are Q001-Q010;
2) the channel code (ChannelId) is a routing key (RouteKey);
3) the business data processing program is a Producer (Producer);
4) the request handler is a Consumer (Consumer);
5) timeout time, for example: TTL is 30 s.
After step S103, in order to solve the problem of message backlog, the method further includes: judging whether the service data is generated within a preset timeout period; if yes, the service data is stored in the service database and a preset service table is updated; the service data are packaged according to a preset format and then sent to a message queue; otherwise, returning an overtime message to the client, wherein the overtime message is used for indicating that the request message waits overtime. Wherein the service table comprises one or more of the following information: service type, channel code, channel name, service data, processing status, processing result, etc. The data can be accurately delivered and consumed through the data structure of the service table and the message queue, so that the request processing is more efficient.
It can be understood that, the client requests to query the service database for the first time, and if the service database has the service data requested by the client, the service data is returned to the client; otherwise, adding the request of the client into the request message queue to wait. And if the server generates related service data within the timeout time set by the response, synchronously updating the service database and the message queue. At this time, the request obtains the service data from the message queue, updates the service database, and then returns the service data to the client. If the overtime business database has no corresponding business data, the overtime business database also directly returns. By setting reasonable request waiting time, the probability that the client side obtains effective service data in each polling request is greatly increased, and service response and operation experience are well improved.
When the service database is updated according to the service data, the service data received or generated by the service end can be stored in the service table. The service table includes one or more of the following information: service type, channel code, channel name, service data, processing status, processing result, etc. Wherein the service type may be composed of a code consisting of two digits; the channel code (ChannelId) may be a code consisting of three digits, 001 starting to indicate the channel to which the service is to be sent; the channel name is a string; the service data is formed by character strings in JSON format, and comprises data items and data information appointed with the channel end. The processing state is used for representing the state of the processing of the piece of service information, and comprises a two-digit code, 00-unprocessed, 01-consumed and 02-processed. The processing result is used for saving the latest processing condition.
In the embodiment of the invention, after the request access of the client, the service processing logic of the server does not firstly walk the message service device, but firstly walks the service processing device to inquire whether the service database has the service data to be processed. If the message queue exists, returning directly, and not entering the message queue; if not, the message queue is entered to wait. The message service device is used as the post logic of the business processing, the business processing device is in front of the message service device, and the message service device is behind the message service device.
By introducing the message middleware, the embodiment reduces the invalid overhead of polling the database by the server, saves the network flow, and can avoid the operation and maintenance pressure brought by polling the server by the client and the resource waste caused by hanging of long polling connection requests by the server.
It can be understood that the above embodiment solves the problem that the application server side is not enough in connection resources due to a large number of client http polling requests in distributed and internet environments, and also solves the problems of service timeliness and poor client operation experience in the case of long polling. By the embodiment, the application and database server resources can be greatly saved, and the service timeliness and the customer operation experience can be improved.
Fig. 2 is a flowchart illustrating a request processing method based on message middleware according to a second embodiment of the present invention, and referring to fig. 2, the request processing method may include steps S201 to S205 as follows.
Step S201: the client sends a request message to the server.
In step S201, the client packages and sends a communication request, where the communication request carries a request packet. The request packet may adopt a JSON format, and the request packet at least includes: a request data field and a public field; the request data field is used to indicate request information of a request packet of each request, for example: the request data field is a specific parameter of each request in plain text. The public domain is used for indicating service framework control information which is irrelevant to services, such as a global tracking number, a service code, a service version number, message encryption information and the like.
Further, the client may use an http/https protocol, and may initiate the communication request by a GET method. The http communication request message can be encoded and compiled by using BASE64 in UTF-8 character set format.
Step S202: and the server receives the request message and inquires a service database according to the initiating channel in the request message.
In step S202, after receiving the request message, the request processing module first determines whether decryption is required according to the message encryption/decryption identifier in the public domain of the request message; and then acquiring request information such as channel identification (ChannelId) from the request data field of the decrypted request message, and inquiring a service database according to the request information. And when the service data is not inquired in the service database, adding the request message into a message request queue to be processed to wait.
Step S203: and judging whether the service database has the to-be-processed service data corresponding to the channel. If yes, go to step S204; otherwise, step S205 is executed.
It can be understood that, after the server receives the client request message, it queries whether there is 00-unprocessed service data in the channel according to the channel code. If the unprocessed service data of the channel exists in the service database, the service data is sent to the client and the processing state is updated to be 01-consumed; and if the unprocessed service data of the channel does not exist in the service database, entering a corresponding message queue to wait.
Step S204: and the server returns the service data to be processed to the client and updates the service database.
When the service database is updated according to the service data, the service data received or generated by the service end can be stored in the service table. The service table includes one or more of the following information: service type, channel code, channel name, service data, processing status, processing result, etc. Wherein the service type may be composed of a code consisting of two digits; the channel code (ChannelId) may be a code consisting of three digits, 001 starting to indicate the channel to which the service is to be sent; the channel name is a string; the service data is formed by character strings in JSON format, and comprises data items and data information appointed with the channel end. The processing state is used for representing the state of the processing of the piece of service information, and comprises a two-digit code, 00-unprocessed, 01-consumed and 02-processed. The processing result is used for saving the latest processing condition.
Step S205: and adding the request message into a message queue.
It should be noted that, the design parameters of the message queue include:
1) each channel is correspondingly provided with a message queue, for example: the channels are Q001-Q010;
2) the channel code (ChannelId) is a routing key (RouteKey);
3) the business data processing program is a Producer (Producer);
4) the request handler is a Consumer (Consumer);
5) timeout time, for example: TTL is 30 s.
In step S205, when the request packet is added to the message queue, a channel code may be obtained from the request message; the channel code is used for representing identification information of channels, and each channel is correspondingly provided with a message queue. And then adding the request message into a corresponding message queue according to the channel code.
On the basis of the above embodiment, and after step S205, the request processing method further includes: and after receiving the service data to be processed generated by the back end, storing the service data in a service database, updating a service table, packaging the service data according to a preset format and then sending the packaged service data to a message queue. That is, if the service end generates service data, the service data can be inserted into the service database and the processing state is set to 00-unprocessed; meanwhile, the service message is sent to the message queue corresponding to the message through the specified routing key word.
In addition, in order to solve the problem of message backlog, the method further comprises: judging whether the service data is generated within a preset timeout period; if yes, the service data is stored in the service database and a preset service table is updated; the service data is packaged according to a preset format and then sent to a message queue; otherwise, returning an overtime message to the client, wherein the overtime message is used for indicating that the request message waits overtime. Wherein the service table comprises one or more of the following information: service type, channel code, channel name, service data, processing status and processing result. The data can be accurately delivered and consumed through the data structure of the service table and the message queue, so that the request processing is more efficient.
For example: the timeout time may be set to 30 s. That is, if the business data is acquired within the waiting 30s, the business data is pulled, and the processing state of the business table of the business database is updated to be 01-consumed; and if the service data is not received for more than 30s, returning a response overtime message to the client. Therefore, if the messages of the message queue are not consumed for 30s beyond the set expiration time, the messages are expired, and the message backlog problem is solved.
In the embodiment of the invention, after the request access of the client, the service processing logic of the server does not firstly walk the message service device, but firstly walks the service processing device to inquire whether the service database has the service data to be processed. If the message queue exists, returning directly, and not entering the message queue; if not, the message queue is entered to wait. The message service device is used as the post logic of the business processing, the business processing device is in front of the message service device, and the message service device is behind the message service device.
By introducing the message middleware, the embodiment reduces the invalid overhead of polling the database by the server, saves the network flow, and can avoid the operation and maintenance pressure brought by polling the server by the client and the resource waste caused by hanging of long polling connection requests by the server.
It can be understood that the above embodiment solves the problem that the application server side is not enough in connection resources due to a large number of client http polling requests in distributed and internet environments, and also solves the problems of service timeliness and poor client operation experience in the case of long polling. By the embodiment, the application and database server resources can be greatly saved, and the service timeliness and the customer operation experience can be improved. In addition, by setting reasonable request waiting time, the probability that the client side acquires effective service data in each polling request is greatly increased, and service response and operation experience are well improved.
Fig. 3 is a schematic block diagram of a message middleware based request processing apparatus according to an embodiment of the present invention, and referring to fig. 3, the message middleware based request processing apparatus 300 includes the following modules:
the query module 301 is configured to query, according to a request packet sent by a client, whether service data related to the request packet exists in a service database;
a sending module 302, configured to send a response packet to the client if service data related to the request packet exists in a service database, where the response packet carries the service data;
and a message queue module 303, configured to add the request packet to a message queue if the request packet is not the request packet.
Optionally, the request packet at least includes: a request data field and a public field; the request data field is used for indicating the request information of the request message of each request, and the public field is used for indicating the service framework control information.
Optionally, the query module 301 is further configured to:
acquiring request information from a request message sent by a client;
and inquiring whether the service data related to the request message exists in a service database according to the acquired request information.
Optionally, the request information at least includes: a channel code; the message queue module 303 is further configured to:
acquiring a channel code from the request information; the channel code is used for representing identification information of channels, and each channel is correspondingly provided with a message queue;
and adding the request message into a corresponding message queue according to the channel code.
Optionally, the public domain includes at least one or more of the following information: global tracking number, service code, service version number and message encryption information.
Optionally, the query module 301 is further configured to:
acquiring message encryption information from the public domain of the request message;
decrypting the request message according to the message encryption information;
and acquiring the request information from the request data field of the decrypted request message.
Optionally, the design parameters of the message queue include:
1) each channel is correspondingly provided with a message queue;
2) the channel code is a routing keyword;
3) the service data processing program is a producer;
4) the request processing program is a consumer;
5) a timeout time.
Optionally, the message middleware-based request processing apparatus further includes:
the judging module is used for judging whether the service data is generated within the preset overtime time;
the first execution module is used for storing the service data into the service database and updating a preset service table if the service data is in the first execution module; the service data is packaged according to a preset format and then sent to a message queue;
and the second execution module is used for returning an overtime message to the client if the request message is not overtime, and the overtime message is used for indicating that the request message waits overtime.
Optionally, the service table includes one or more of the following information: service type, channel code, channel name, service data, processing status and processing result.
In the embodiment of the invention, by introducing the message middleware, the invalid overhead of polling the database by the server is reduced, the network flow is saved, and the operation and maintenance pressure brought by polling the server by the client and the resource waste caused by hanging of long polling connection requests by the server can be avoided.
It can be understood that the above embodiment solves the problem that the application server side is not enough in connection resources due to a large number of client http polling requests in distributed and internet environments, and also solves the problems of service timeliness and poor client operation experience in the case of long polling. By the embodiment, the application and database server resources can be greatly saved, and the service timeliness and the customer operation experience can be improved.
Fig. 4 illustrates an exemplary system architecture 400 of a message-middleware based request processing method or a message-middleware based request processing apparatus to which an embodiment of the present invention may be applied.
As shown in fig. 4, the system architecture 400 may include client devices 401, 402, 403, a network 404, and a server 405. Network 404 serves as a medium for providing communication links between client devices 401, 402, 403 and server 405. Network 404 may include various types of connections, such as wire, wireless communication links, or fiber optic cables, to name a few.
A user may interact with a server 405 over a network 404 using client devices 401, 402, 403 to receive or send messages, etc. Various messaging client applications, such as shopping-like applications, web browser applications, search-like applications, instant messaging tools, mailbox clients, social platform software, etc. (examples only) may be installed on the client devices 401, 402, 403.
It should be noted that the request processing method based on the message middleware provided by the embodiment of the present invention is generally executed by the server 405, and accordingly, the request processing apparatus based on the message middleware is generally disposed in the server 405.
It should be understood that the number of client devices, networks, and servers in fig. 4 is merely illustrative. There may be any number of client devices, networks, and servers, as desired for an implementation.
Referring now to FIG. 5, a block diagram of a computer system 500 suitable for use with a client device implementing an embodiment of the present invention is shown. The client device shown in fig. 5 is only an example, and should not bring any limitation to the function and the scope of use of the embodiments of the present invention.
As shown in fig. 5, the computer system 500 includes a Central Processing Unit (CPU)501 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)502 or a program loaded from a storage section 508 into a Random Access Memory (RAM) 503. In the RAM 503, various programs and data necessary for the operation of the system 500 are also stored. The CPU 501, ROM 502, and RAM 503 are connected to each other via a bus 504. An input/output (I/O) interface 505 is also connected to bus 504.
The following components are connected to the I/O interface 505: an input portion 506 including a keyboard, a mouse, and the like; an output portion 507 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 508 including a hard disk and the like; and a communication section 509 including a network interface card such as a LAN card, a modem, or the like. The communication section 509 performs communication processing via a network such as the internet. The driver 510 is also connected to the I/O interface 505 as necessary. A removable medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 510 as necessary, so that a computer program read out therefrom is mounted into the storage section 508 as necessary.
In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 509, and/or installed from the removable medium 511. The computer program performs the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 501.
It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. 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 or flowchart illustration, and combinations of blocks in the block diagrams 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.
As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise: inquiring whether business data related to the request message exists in a business database according to the request message sent by the client; if business data related to the request message exists in a business database, sending a response message to the client, wherein the response message carries the business data; otherwise, adding the request message into a message queue.
In the embodiment of the invention, by introducing the message middleware, the invalid overhead of polling the database by the server is reduced, the network flow is saved, and the operation and maintenance pressure brought by polling the server by the client and the resource waste caused by hanging of long polling connection requests by the server can be avoided.
It can be understood that the above embodiment solves the problem that the application server side is not enough in connection resources due to a large number of client http polling requests in distributed and internet environments, and also solves the problems of service timeliness and poor client operation experience in the case of long polling. By the embodiment, the application and database server resources can be greatly saved, and the service timeliness and the customer operation experience can be improved.
The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (12)
1. A request processing method based on message middleware is characterized by comprising the following steps:
inquiring whether business data related to the request message exists in a business database according to the request message sent by the client;
if business data related to the request message exists in a business database, sending a response message to the client, wherein the response message carries the business data;
otherwise, adding the request message into a message queue.
2. The method according to claim 1, wherein the request message comprises at least: a request data field and a public field; the request data field is used for indicating the request information of the request message of each request, and the public field is used for indicating the service framework control information.
3. The method of claim 2, wherein querying a service database for the presence of service data associated with the request message according to the request message sent by the client comprises:
acquiring request information from a request message sent by a client;
and inquiring whether the service data related to the request message exists in a service database according to the acquired request information.
4. The method of claim 3, wherein the request information comprises at least: a channel code; adding the request message into a message queue comprises:
acquiring a channel code from the request information; the channel code is used for representing identification information of channels, and each channel is correspondingly provided with a message queue;
and adding the request message into a corresponding message queue according to the channel code.
5. The method of claim 4, wherein the public domain comprises at least one or more of the following information: global tracking number, service code, service version number and message encryption information.
6. The method of claim 5, wherein obtaining the request information from the request message sent by the client comprises:
acquiring message encryption information from the public domain of the request message;
decrypting the request message according to the message encryption information;
and acquiring the request information from the request data field of the decrypted request message.
7. The method of claim 1, wherein the design parameters of the message queue comprise:
each channel is correspondingly provided with a message queue;
the channel code is a routing keyword;
the service data processing program is a producer;
the request processing program is a consumer;
a timeout time.
8. The method of claim 7, wherein after the step of adding the request message to a message queue, the method further comprises:
judging whether the service data is generated within a preset timeout period;
if yes, the service data is stored in the service database and a preset service table is updated; the service data is packaged according to a preset format and then sent to a message queue;
otherwise, returning an overtime message to the client, wherein the overtime message is used for indicating that the request message waits overtime.
9. The method of claim 8, wherein the service table comprises one or more of the following information: service type, channel code, channel name, service data, processing status and processing result.
10. A message middleware-based request processing apparatus, comprising:
the query module is used for querying whether business data related to the request message exists in a business database according to the request message sent by the client;
a sending module, configured to send a response packet to the client if service data related to the request packet exists in a service database, where the response packet carries the service data;
and the message queue module is used for adding the request message into a message queue if the request message is not the message queue.
11. A server, comprising:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-9.
12. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011482834.2A CN112653614A (en) | 2020-12-15 | 2020-12-15 | Request processing method and device based on message middleware |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011482834.2A CN112653614A (en) | 2020-12-15 | 2020-12-15 | Request processing method and device based on message middleware |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112653614A true CN112653614A (en) | 2021-04-13 |
Family
ID=75354536
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011482834.2A Pending CN112653614A (en) | 2020-12-15 | 2020-12-15 | Request processing method and device based on message middleware |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112653614A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113114768A (en) * | 2021-04-14 | 2021-07-13 | 北京京东振世信息技术有限公司 | Service request processing method, device and system |
| CN114697281A (en) * | 2022-02-28 | 2022-07-01 | 青岛海尔科技有限公司 | Text message processing method and device, storage medium and electronic device |
| CN117149888A (en) * | 2023-11-01 | 2023-12-01 | 建信金融科技有限责任公司 | Method, apparatus, device and computer readable medium for data processing |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7400624B2 (en) * | 2003-05-27 | 2008-07-15 | Sun Microsystems, Inc. | Hashing based messaging approach to a cluster |
| CN105262614A (en) * | 2015-09-08 | 2016-01-20 | 北京思特奇信息技术股份有限公司 | Service processing method and system based on service plug-in |
| CN106603598A (en) * | 2015-10-15 | 2017-04-26 | 阿里巴巴集团控股有限公司 | Method for processing service request and apparatus thereof |
| CN107277083A (en) * | 2016-04-06 | 2017-10-20 | 阿里巴巴集团控股有限公司 | A kind of processing method of data interaction, apparatus and system |
| CN109819021A (en) * | 2019-01-09 | 2019-05-28 | 网宿科技股份有限公司 | The method of business backstage and its asynchronous process service request |
| CN110336702A (en) * | 2019-07-11 | 2019-10-15 | 上海金融期货信息技术有限公司 | A kind of system and implementation method of message-oriented middleware |
| CN110933171A (en) * | 2019-11-29 | 2020-03-27 | 北京浪潮数据技术有限公司 | Server asynchronous communication method, device, equipment and computer storage medium |
-
2020
- 2020-12-15 CN CN202011482834.2A patent/CN112653614A/en active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7400624B2 (en) * | 2003-05-27 | 2008-07-15 | Sun Microsystems, Inc. | Hashing based messaging approach to a cluster |
| CN105262614A (en) * | 2015-09-08 | 2016-01-20 | 北京思特奇信息技术股份有限公司 | Service processing method and system based on service plug-in |
| CN106603598A (en) * | 2015-10-15 | 2017-04-26 | 阿里巴巴集团控股有限公司 | Method for processing service request and apparatus thereof |
| CN107277083A (en) * | 2016-04-06 | 2017-10-20 | 阿里巴巴集团控股有限公司 | A kind of processing method of data interaction, apparatus and system |
| CN109819021A (en) * | 2019-01-09 | 2019-05-28 | 网宿科技股份有限公司 | The method of business backstage and its asynchronous process service request |
| CN110336702A (en) * | 2019-07-11 | 2019-10-15 | 上海金融期货信息技术有限公司 | A kind of system and implementation method of message-oriented middleware |
| CN110933171A (en) * | 2019-11-29 | 2020-03-27 | 北京浪潮数据技术有限公司 | Server asynchronous communication method, device, equipment and computer storage medium |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113114768A (en) * | 2021-04-14 | 2021-07-13 | 北京京东振世信息技术有限公司 | Service request processing method, device and system |
| CN114697281A (en) * | 2022-02-28 | 2022-07-01 | 青岛海尔科技有限公司 | Text message processing method and device, storage medium and electronic device |
| CN114697281B (en) * | 2022-02-28 | 2024-03-22 | 青岛海尔科技有限公司 | Text message processing method and device, storage medium and electronic device |
| CN117149888A (en) * | 2023-11-01 | 2023-12-01 | 建信金融科技有限责任公司 | Method, apparatus, device and computer readable medium for data processing |
| CN117149888B (en) * | 2023-11-01 | 2024-02-13 | 建信金融科技有限责任公司 | Method, apparatus, device and computer readable medium for data processing |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112653614A (en) | Request processing method and device based on message middleware | |
| CN102255934B (en) | Cloud service dissemination method and cloud service intermediary | |
| CN109995801B (en) | Message transmission method and device | |
| CN111917687B (en) | Method and device for circularly pushing reminding message | |
| US20190173960A1 (en) | Method, device and computer program product for protocol selection | |
| CN110858202A (en) | Method and device for generating where clause in database query statement | |
| CN113364795B (en) | Data transmission method and proxy server | |
| CN112507005A (en) | Method and device for processing message | |
| CN109981546B (en) | Method and device for acquiring remote call relation between application modules | |
| CN112084042A (en) | Message processing method and device | |
| CN113778499B (en) | Method, apparatus, device and computer readable medium for publishing services | |
| CN112685481A (en) | Data processing method and device | |
| CN114417318A (en) | Third-party page jumping method and device and electronic equipment | |
| CN112306791B (en) | Performance monitoring method and device | |
| CN113779122A (en) | Method and apparatus for exporting data | |
| CN113779018A (en) | Data processing method and device | |
| CN110019671B (en) | Method and system for processing real-time message | |
| CN113572704A (en) | Information processing method, production end, consumption end and server | |
| CN113722115A (en) | Method, device, equipment and computer readable medium for calling interface | |
| CN113238808A (en) | Message pushing method and device | |
| CN113760487A (en) | Service processing method and device | |
| CN111984616A (en) | Method, device and system for updating shared file | |
| CN112306984A (en) | Data source routing method and device | |
| CN113626176A (en) | Service request processing method and device | |
| CN113542324A (en) | Message pushing method and device |
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 | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210413 |