CN108965164B

CN108965164B - Service request retransmission method and device based on message queue and readable storage medium

Info

Publication number: CN108965164B
Application number: CN201710347403.7A
Authority: CN
Inventors: 董志强
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Priority date: 2017-05-17
Filing date: 2017-05-17
Publication date: 2021-12-07
Anticipated expiration: 2037-05-17
Also published as: CN108965164A

Abstract

The application discloses a service request retransmission method and device based on a message queue and a readable storage medium. The method comprises the following steps: sending the service request in the service message queue; when the response message of the service request is not received within a preset time threshold or the failure of sending the service request is detected, the service request is placed into a first retry message queue in a plurality of retry message queues according to a preset configuration file chain; wherein the plurality of retry message queues have different message expiration times; the chain of profiles is used to determine a routing order of the service requests in the plurality of retry message queues. The method can realize the retransmission requests with different frequencies, reduce the load of the service server and improve the message safety.

Description

Service request retransmission method and device based on message queue and readable storage medium

Technical Field

The invention relates to a computer network application technology, in particular to a method, a device and equipment for retransmitting service requests based on a message queue and a readable storage medium.

Background

In an e-commerce system, where communication is required between multiple system platforms, retries may need to be initiated at different time frequencies after the first communication failure. Such as ledger back-check services. The standing book reverse check means that when a user charges a mobile phone on the online mall platform, the payment platform informs the online mall platform of a user payment result after the user selects a corresponding face value and pays, and then the online mall platform performs subsequent charging actions according to the user payment result. And if the payment platform does not inform the online mall platform of the payment result of the user in time after the user finishes payment, the online mall platform can actively inquire the payment result of the user by the payment platform in an interface mode.

At present, the online shopping mall platform performs machine account back-check by inquiring cache through a timed task and circularly paying unconfirmed information at different time periods. However, by the method, circular cache is needed during each query, the overhead of the service server is greatly increased, and even if no order needing to be back-checked exists in the current time period, the timing task is started to scan the cache. In addition, the order to be checked back is suspended in a JVM (Java Virtual Machine) cache, which has a problem of data security.

The above information disclosed in this background section is only for enhancement of understanding of the background of the invention and therefore it may contain information that does not constitute prior art that is already known to a person of ordinary skill in the art.

Disclosure of Invention

The invention provides a method, a device and equipment for retransmitting service requests based on a message queue and a readable storage medium, which can realize retransmission requests with different frequencies, reduce the load of a service server and improve the message security.

Additional features and advantages of the invention will be set forth in the detailed description which follows, or may be learned by practice of the invention.

According to an aspect of the present invention, a method for retransmitting a service request based on a message queue is provided, which includes: sending the service request in the service message queue; when the response message of the service request is not received within a preset time threshold or the failure of sending the service request is detected, the service request is placed into a first retry message queue in a plurality of retry message queues according to a preset configuration file chain; wherein the plurality of retry message queues have different message expiration times; the chain of profiles is used to determine a routing order of the service requests in the plurality of retry message queues.

According to an embodiment of the present invention, the method further includes: when the message expiration time of the service request in the first retry message queue expires, putting the service request into a redistribution total message queue; routing the service request from the redistribution total message queue to the service message queue according to the attribute of the service request; and retransmitting the service request in the service message queue.

According to an embodiment of the present invention, after the retransmitting the service request in the service message queue, the method further includes: when the response message of the service request is not received within the time threshold or the retransmission failure of the service request is detected, the service request is placed into a second retry message queue of the retry message queues according to a preset configuration file chain; wherein a message expiration time of the second retry message queue is longer than a message expiration time of the first retry message queue.

According to an embodiment of the present invention, the plurality of retry message queues are deadlock queues.

According to an embodiment of the present invention, the method further includes: putting the received service request into a receiving total message queue; and routing the service request from the receiving total message queue to the service message queue according to the attribute of the service request.

According to another aspect of the present invention, there is provided a message queue-based service request retransmission apparatus, including: the service request sending module is used for sending the service requests in the service message queue; the service request processing module is used for placing the service request into a first retry message queue in a plurality of retry message queues according to a preset configuration file chain when the response message of the service request is not received within a preset time threshold or the failure of sending the service request is detected; wherein the plurality of retry message queues have different message expiration times; the chain of profiles is used to determine a routing order of the service requests in the plurality of retry message queues.

According to an embodiment of the present invention, the apparatus further includes: a service request redistribution module, configured to place the service request into a redistribution total message queue when a message expiration time of the service request in the first retry message queue expires; a service request routing module, configured to route the service request from the redistribution total message queue to the service message queue according to an attribute of the service request; and a service request retransmission module, configured to retransmit the service request in the service message queue.

According to an embodiment of the present invention, the service request processing module is further configured to: after the service request retransmission module retransmits the service request in the service message queue, when a response message of the service request is not received within the time threshold or the retransmission failure of the service request is detected, the service request is placed in a second retry message queue in the retry message queues according to a preset configuration file chain; wherein a message expiration time of the second retry message queue is longer than a message expiration time of the first retry message queue.

According to an embodiment of the present invention, the apparatus further includes: the service request receiving module is used for putting the received service request into a receiving total message queue; wherein, the service request routing module is further configured to route the service request from the receive total message queue to the service message queue according to the attribute of the service request.

According to yet another aspect of the invention, there is provided a computer-readable storage medium having stored thereon computer-executable instructions which, when executed by a processor, implement any of the methods described above.

According to still another aspect of the present invention, there is provided an electronic apparatus including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the steps of any of the message queue based service request retransmission methods described above via execution of the executable instructions.

According to the message queue-based service request retransmission method, the retry message queues with different message expiration times are set, retransmission requests with different frequencies can be realized, the service requests are put into the message queues, the load of a service server can be reduced, and the message safety can be improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

Drawings

The above and other objects, features and advantages of the present invention will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings.

Fig. 1 is an application scenario of the method of the present invention shown according to an exemplary embodiment.

Fig. 2 is a flowchart illustrating a method for retransmission of service requests based on a message queue according to an exemplary embodiment.

Fig. 3 is an architecture diagram illustrating a system applied to the method of the present invention, according to an exemplary embodiment.

Fig. 4 is a flowchart illustrating another method for retransmission of service requests based on message queues according to an exemplary embodiment.

Fig. 5 is a schematic routing diagram of a service request according to an example.

Fig. 6 is a schematic diagram illustrating a traffic request flow according to an example.

Fig. 7 is a block diagram illustrating a message queue based service request retransmission apparatus according to an example embodiment.

Fig. 8 is a schematic structural diagram of an electronic device according to an example embodiment.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The drawings are merely schematic illustrations of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known structures, methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

A Message Queue (MQ) is a Queue of deposited messages that provides a loosely coupled approach to distributed applications in a synchronous or asynchronous manner. Message queues may be used in applications to perform a variety of functions, such as requiring services, exchanging information, or asynchronous processing.

Fig. 1 is an application scenario of the method of the present invention shown according to an exemplary embodiment. As shown in fig. 1, in this scenario, the method includes: at least one service request server 11, at least one message queue server 12 and at least one service processing server 13. Wherein, the service request server 11 sends or retransmits the service request to the service processing server 13 by means of the message queue in the message queue server 12 to request the service processing server 13 to process the service request. Taking the ledger reverse check service as an example, the service request server 11 may be, for example, an online mall platform server, and the service processing server 13 may be, for example, a payment platform server.

Fig. 2 is a flowchart illustrating a method for retransmission of service requests based on a message queue according to an exemplary embodiment. Referring to fig. 1 and 2, the method 10 includes:

in step S102, the service request in the service message queue is sent.

For example, the service message queue is located in the message queue server 12 in fig. 1, and the same type of service request message may be carried in the service message queue. When the service request server 11 needs to process the service request in the service message queue, the service request is sent to the service processing server 13.

In step S104, when a response message of the service request is not received within a preset time threshold or a failure of sending the service request is detected, the service request is placed in a first retry message queue of the retry message queues according to a preset configuration file chain.

Wherein the plurality of retry message queues have different message expiration times, respectively.

For example, after the service request server 11 sends the service request to the service processing server 13, when the response message returned by the service processing server 13 is not received within a preset time threshold, the service request server puts the service request into a first retry message queue of the retry message queues of the message queue server 12 according to a preset configuration file chain. In practical applications, the length of the time threshold may be set according to practical requirements, and the invention is not limited thereto. In practical applications, the monitoring of the time threshold may be implemented by starting a timer, for example. If a timer is started after the service request in the service message queue is sent, and the length of the timer is the time threshold, if the response message is still not received after the timer expires, the service request is placed into a first retry message queue in the plurality of retry message queues according to a preset configuration file chain.

Or, when the failure of sending the service request is detected due to an abnormal reason, the operation of placing the service request into a first retry message queue of the plurality of retry message queues according to the preset configuration file chain is also executed.

The chain of profiles is used to specify the routing order of the service requests in the plurality of retry message queues. For example, when the first transmission fails, the service request is placed in a first retry message queue; when the retransmission fails, the service request is placed in a second retry message queue; when retransmission fails again, the service request is placed in a third retry message queue, and so on. The Routing order is defined in the profile chain, for example by the Routing identification (Routing ID) of the respective retry message queue.

It should be clearly understood that the present disclosure describes how to make and use particular examples, but the principles of the present disclosure are not limited to any details of these examples. Rather, these principles can be applied to many other embodiments based on the teachings of the present disclosure.

Fig. 3 is an architecture diagram illustrating a system applied to the method of the present invention, according to an exemplary embodiment. As shown in fig. 3, the service architecture may be composed of two parts, a message queue service layer and a service request service layer. Wherein, the message queue server 12 in fig. 1 serves the message queue service layer, and the service request server 11 serves the service request service layer. The first, third and fifth layers in fig. 3 are message queue service layers, and the second, fourth and sixth layers are service request service layers.

Fig. 4 is a flowchart illustrating another method for retransmission of service requests based on message queues according to an exemplary embodiment. As shown in conjunction with fig. 1, 3, and 4, the method 20 includes:

in step S202, the received service request is put into the receive total message queue.

The receive total message queue is located in the message queue server 12. Taking the ledger reverse check service as an example, for a service request for which a payment success response message is not received after payment is completed, the attribute of the service request can be set, and then the service request is put into a total message receiving queue. The attributes of the service request include, for example: a telephone fee recharge order, a flow recharge order, etc. The attribute may be represented by a Routing Key.

In step S204, the service request is routed from the receiving total message queue to the corresponding service message queue according to the attribute of the service request.

For example, the service request is placed into the corresponding message queue according to the route identifier of the service request by the "MQ listening route" unit in the service request server 11. For example, the service request with the attribute of charging the telephone fee may be put into the first service message queue, the service request with the attribute of charging the traffic fee may be put into the second service message queue, and so on.

In step S206, the service request in the service message queue is sent.

For example, as shown in the fourth layer in fig. 3, a plurality of "MQ service processing" units may be respectively disposed in the service request server 11 to respectively process the service requests in the service message queues. The MQ service processing unit sends the service request in its corresponding service message queue to the service processing server 13.

In step S208, when a response message of the service request is not received within a preset time threshold or a failure of sending the service request is detected, determining whether a corresponding retry queue can be obtained from the configuration file chain, if so, entering step S210; otherwise, the process proceeds to step S216.

In practical applications, the length of the time threshold may be set according to practical requirements, and the invention is not limited thereto. In practical applications, the monitoring of the time threshold may be implemented by starting a timer, for example. If a timer is started after the service request in the service message queue is sent, the length of the timer is the time threshold, and if the response message is still not received after the timer expires, whether the corresponding retry queue can be obtained from the configuration file chain is judged.

Or, when the failure of sending the service request is detected due to an abnormal reason, the operation of judging whether the corresponding retry queue can be obtained from the configuration file chain is also executed.

The plurality of retry message queues respectively have different message expiration times, and when the time of the service request in the retry message queues expires, the service request in the retry message queues is ready to be retransmitted.

The chain of profiles is used to specify the routing order of the service requests in the plurality of retry message queues.

In step S210, the service request is placed in a corresponding retry message queue of the retry message queues according to a preset configuration file chain.

Taking retransmission three times with retransmission intervals of 10 seconds, 20 seconds, and 30 seconds as examples, "retry. timer 1 s", "retry. timer 2 s", and "retry. timer 30s" are used to represent routing identifiers of retry message queues with message expiration times of 10 seconds, 20 seconds, and 30 seconds, respectively, the configuration file may be configured, for example, { "audeflt", "retry. timer 1 s", "retry. timer 10s" \\\, "retry. timer 2s" }.

When the retransmission is the first time, the service request may be placed in a first retry message queue with a route identifier "retry.

When retransmitting for the second time, the service request may be placed in a second retry message queue with a route identifier of "retry.

When retransmitting for the third time, the service request may be placed in a third retry message queue with a route identifier "retry.

A Dead Message queue (Dead Message) is one of Message queues, and is different from a normal Message queue in that messages in the Dead Message queue have a Message expiration Time (TTL), and when a Message in the Dead Message queue reaches the expiration Time, the Message queue processes the Message at the expiration Time. In some embodiments, the retry message queue is a credit-loss queue, and the credit-loss queue is used to implement the function of service request due retransmission.

In step S212, when the message expiration time of the service request in the retry message queue expires, the service request is placed in the redistribution aggregate message queue.

As shown in the fifth layer of fig. 3, the message queue server 12 further includes a redistribution aggregate message queue for carrying service requests for which the message expiration time in the retry message queue expires.

In step S214, the service request is rerouted from the redistribution aggregate message queue to the service message queue according to the attribute of the service request, and the process proceeds to step S206 again.

For example, as shown in the sixth layer of fig. 3, the service request is routed from the redistribution aggregate message queue to the service message queue by the "MQ service redistribution unit" in the service request server 11 according to the attribute of the service request. In the synchronization step S204, for example, the service request with the attribute of charging the telephone fee may be placed in the first service message queue, the service request with the attribute of charging the traffic fee may be placed in the second service message queue, and the like.

In step S216, after the log is printed, the service request is deleted.

Fig. 5 is a schematic routing diagram of a service request according to an example. Wherein, the example of creating Exchange and retry message queue and redistributing the total message queue is as follows:

Exchange(my_exchange)

first retry message queue (my _ retry _10s)

Second retry message queue (my _ retry _20s)

Third retry message queue (my _ retry _30s)

Redistribution master message queue (my _ handler)

Fig. 6 is a schematic diagram illustrating a traffic request flow according to an example. As can be seen from fig. 5 and 6, the service request is routed from the receiving total message queue to the corresponding service message queue for processing according to the attribute, and if the processing fails, the service request is routed to the corresponding retry message queue according to the configuration file chain, and if the processing fails, the service request is placed in the first retry message queue; the first retry is failed and is put into a second retry message queue; the second retry identifies, places in a third retry message queue, and so on.

According to the message queue-based service request retransmission method, a thread circular scanning mode can be used during specific implementation, so that the reliability of system performance can be improved, and the complexity of code development can be reduced.

Those skilled in the art will appreciate that all or part of the steps implementing the above embodiments are implemented as computer programs executed by a CPU. The computer program, when executed by the CPU, performs the functions defined by the method provided by the present invention. The program may be stored in a computer readable storage medium, which may be a read-only memory, a magnetic or optical disk, or the like.

Furthermore, it should be noted that the above-mentioned figures are only schematic illustrations of the processes involved in the method according to exemplary embodiments of the invention, and are not intended to be limiting. It will be readily understood that the processes shown in the above figures are not intended to indicate or limit the chronological order of the processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, e.g., in multiple modules.

The following are embodiments of the apparatus of the present invention that may be used to perform embodiments of the method of the present invention. For details which are not disclosed in the embodiments of the apparatus of the present invention, reference is made to the embodiments of the method of the present invention.

Fig. 7 is a block diagram illustrating a message queue based service request retransmission apparatus according to an example embodiment. As shown in fig. 7, the apparatus 30 includes: a service request sending module 302 and a service request processing module 304.

The service request sending module 302 is configured to send a service request in a service message queue.

The service request processing module 304 is configured to, when a response message of a service request is not received within a preset time threshold or a failure of sending the service request is detected, put the service request into a first retry message queue of the retry message queues according to a preset configuration file chain. Wherein the plurality of retry message queues have different message expiration times; the chain of profiles is used to determine a routing order of the service requests in the plurality of retry message queues.

In some embodiments, the apparatus 30 further comprises: a service request redistribution module 306, a service request routing module 308 and a service request retransmission module 310. Wherein, the service request redistribution module 306 is configured to place the service request into the redistribution total message queue when the message expiration time of the service request in the first retry message queue expires. The service request routing module 308 is configured to route the service request from the redistribution aggregate message queue to the service message queue according to the attribute of the service request. The service request retransmission module 310 is used for retransmitting the service request in the service message queue.

In some embodiments, the service request processing module 304 is further configured to, when no response message of the service request is received within the time threshold or a retransmission failure of the service request is detected, place the service request in a second retry message queue of the retry message queues according to a preset profile chain. Wherein the message expiration time of the second retry message queue is longer than the message expiration time of the first retry message queue.

In some embodiments, the plurality of retry message queues are blind message queues.

In some embodiments, the apparatus 30 further comprises: a service request receiving module 312, configured to put the received service request into the receiving total message queue. The service request routing module 308 is further configured to route the service request from the receive total message queue to the service message queue according to the attribute of the service request.

It is noted that the block diagrams shown in the above figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

Fig. 8 is a schematic structural diagram of an electronic device according to an example embodiment. It should be noted that the electronic device shown in fig. 8 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 8, the electronic apparatus 800 includes a Central Processing Unit (CPU)801 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data necessary for the operation of the system 800 are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other via a bus 804. An input/output (I/O) interface 805 is also connected to bus 804.

The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, a mouse, and the like; an output section 807 including a signal such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 808 including a hard disk and the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. A drive 810 is also connected to the I/O interface 805 as necessary. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as necessary, so that a computer program read out therefrom is mounted on the storage section 808 as necessary.

In particular, according to an embodiment 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 storage medium, the computer program comprising program code for performing the method illustrated by the above-described flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 809 and/or installed from the removable medium 811. The computer program executes the above-described functions defined in the system of the present application when executed by the Central Processing Unit (CPU) 801.

It should be noted that the computer readable storage medium shown in the present application 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 application, 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 this application, 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 storage 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 storage 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 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 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.

The units described in the embodiments of the present application may be implemented by software or hardware. The described units may also be provided in a processor, and may be described as: a processor includes a transmitting unit, an obtaining unit, a determining unit, and a first processing unit. The names of these units do not in some cases constitute a limitation to the unit itself, and for example, the sending unit may also be described as a "unit sending a picture acquisition request to a connected server".

As another aspect, the present application also provides a computer-readable storage medium, which may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable storage medium carries one or more programs which, when executed by a device, cause the device to include:

sending the service request in the service message queue; and

when the response message of the service request is not received within a preset time threshold or the failure of sending the service request is detected, the service request is placed into a first retry message queue in a plurality of retry message queues according to a preset configuration file chain;

wherein the plurality of retry message queues have different message expiration times; the chain of profiles is used to determine a routing order of the service requests in the plurality of retry message queues.

Exemplary embodiments of the present invention are specifically illustrated and described above. It is to be understood that the invention is not limited to the precise construction, arrangements, or instrumentalities described herein; on the contrary, the invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A service request retransmission method based on a message queue is characterized by comprising the following steps:

sending the service request in the service message queue; and

when the response message of the service request is not received within a preset time threshold or the failure of sending the service request is detected, the service request is placed into a first retry message queue in a plurality of retry message queues according to a preset configuration file chain; wherein the plurality of retry message queues have different message expiration times; the configuration file chain is used for determining the routing sequence of the service request in the plurality of retry message queues;

when the message expiration time of the service request in the first retry message queue expires, putting the service request into a redistribution total message queue;

routing the service request from the redistribution total message queue to the service message queue according to the attribute of the service request; and retransmitting the service request in the service message queue;

when the response message of the service request is not received within the time threshold or the retransmission failure of the service request is detected, the service request is placed into a second retry message queue of the retry message queues according to a preset configuration file chain; wherein a message expiration time of the second retry message queue is longer than a message expiration time of the first retry message queue.

2. The method of claim 1, wherein the plurality of retry message queues are blind-letter queues.

3. The method of claim 1, further comprising:

putting the received service request into a receiving total message queue; and

and routing the service request from the receiving total message queue to the service message queue according to the attribute of the service request.

4. A message queue-based service request retransmission apparatus, comprising:

the service request sending module is used for sending the service requests in the service message queue; and

a service request processing module, configured to, when a response message of the service request is not received within a preset time threshold or a failure of sending the service request is detected, put the service request into a first retry message queue of a plurality of retry message queues according to a preset configuration file chain; wherein the plurality of retry message queues have different message expiration times; the configuration file chain is used for determining the routing sequence of the service request in the plurality of retry message queues;

a service request redistribution module, configured to place the service request into a redistribution total message queue when a message expiration time of the service request in the first retry message queue expires;

a service request routing module, configured to route the service request from the redistribution total message queue to the service message queue according to an attribute of the service request; and a service request retransmission module, configured to retransmit the service request in the service message queue;

the service request processing module is further configured to: after the service request retransmission module retransmits the service request in the service message queue, when a response message of the service request is not received within the time threshold or the retransmission failure of the service request is detected, the service request is placed in a second retry message queue in the retry message queues according to a preset configuration file chain; wherein a message expiration time of the second retry message queue is longer than a message expiration time of the first retry message queue.

5. The apparatus of claim 4, wherein the plurality of retry message queues are credit-dead queues.

6. The apparatus of claim 4, further comprising: the service request receiving module is used for putting the received service request into a receiving total message queue; wherein, the service request routing module is further configured to route the service request from the receive total message queue to the service message queue according to the attribute of the service request.

7. A computer-readable storage medium having stored thereon computer-executable instructions that, when executed by a processor, implement the method of any of claims 1-3.

8. An electronic device, comprising:

a processor; and a memory for storing executable instructions of the processor;

wherein the processor is configured to perform the steps of the message queue based service request retransmission method according to any of claims 1-3 via execution of the executable instructions.