CN113760500A - Service processing method, device, server and medium - Google Patents
Service processing method, device, server and medium Download PDFInfo
- Publication number
- CN113760500A CN113760500A CN202110126486.3A CN202110126486A CN113760500A CN 113760500 A CN113760500 A CN 113760500A CN 202110126486 A CN202110126486 A CN 202110126486A CN 113760500 A CN113760500 A CN 113760500A
- Authority
- CN
- China
- Prior art keywords
- calling
- message
- interface
- retry
- target interface
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Retry When Errors Occur (AREA)
Abstract
The embodiment of the invention discloses a service processing method, a device, a server and a medium, wherein the method comprises the following steps: starting a target interface calling thread according to business requirements, calling a target interface through the target interface calling thread, generating a retry interface calling message when the calling of the target interface fails, and putting the retry interface calling message into a preset message queue; monitoring the preset message queue through the message monitoring thread, and when a retry interface calling message enters the preset message queue, repeatedly calling the target interface according to the retry interface calling message until the condition of stopping calling the target interface is met, thereby completing the service requirement. The technical scheme of the embodiment solves the problem that the overall performance of the system is influenced by the blocking of the serial repeated calling interface thread of a single thread, and realizes the decoupling of the main service flow and the step of calling the target interface by adopting an asynchronous mechanism, so that the interface calling is independent from the main flow, and the performance and the stability of the system are ensured.
Description
Technical Field
The embodiment of the invention relates to the technical field of communication, in particular to a service processing method, a service processing device, a service processing server and a service processing medium.
Background
The service applied by the large-scale internet project is generally complex, the interaction between service parties is frequent, and different service module interfaces are important service interaction carriers and media. In actual service, mutual calling between interfaces has a certain failure rate, and when the interface calling fails, the interface needs to be called again to acquire data.
At present, after an interface call fails, the call is usually cyclically attempted until the interface call is successful or the preset number of times of call is repeated; or, the corresponding service is completed in a mode of using a timing task in part of service scenes.
However, in the process of implementing the present invention, at least the following technical problems are found in the prior art: the circular calling mode is a real-time serial operation mode, and a thread dormancy mode is adopted, so that thread blockage and resource occupation are caused, and the overall performance of the system is influenced; the form of the timing task has the limitation of application scenes.
Disclosure of Invention
Embodiments of the present invention provide a service processing method, an apparatus, a server, and a medium, so as to implement decoupling of a service main process and a step of calling a target interface, release and protect system resources, improve a capability of a system for processing a service, and expand a wider application scenario.
In a first aspect, an embodiment of the present invention provides a service processing method, where the method includes:
starting a target interface calling thread according to service requirements, calling a target interface through the target interface calling thread, generating a retry interface calling message when the calling of the target interface fails, and putting the retry interface calling message into a preset message queue;
and monitoring the preset message queue through a message monitoring thread, and when a retry interface calling message enters the preset message queue, repeatedly calling the target interface according to the retry interface calling message until the condition of stopping calling the target interface is met, so as to complete the service requirement.
Optionally, while repeatedly calling the target interface according to the retry interface call message, the method further includes:
recording the calling times of repeatedly calling the target interface;
and sending out warning information when the calling times reach preset times.
Optionally, the condition for stopping the target interface call is satisfied, including:
successfully calling the target interface and acquiring target service information; alternatively, the first and second electrodes may be,
and the calling is still failed after the number of times of repeatedly calling the target interface reaches the preset number.
Optionally, repeatedly calling the target interface according to the retry interface calling message until a condition for stopping calling of the target interface is met, and completing the service requirement, including:
after the target interface is successfully called and target service information is acquired, updating the target service information into service information corresponding to the service requirement, executing service operation associated with the service requirement, and completing the service requirement; alternatively, the first and second electrodes may be,
and after the target interface is repeatedly called for a preset number of times and is still failed to be called, feeding back the result of the failed interface calling to the service information corresponding to the service requirement, and ending the service flow.
Optionally, the repeatedly invoking the target interface according to the retry interface invocation message includes:
and repeatedly calling the target interface according to the message consumption time interval in the message consumption strategy of the message queue management platform.
Optionally, when it is monitored that a retry interface calls a message to enter in the preset message queue, the method further includes:
setting a key value of the retry interface calling message queue message as the identification of the service requirement;
correspondingly, before repeatedly calling the target interface according to the retry interface calling message, the method further comprises:
and identifying a key value of the retry interface calling message, and determining whether the retry interface calling message is executed.
Optionally, the business requirement includes an order management business requirement.
In a second aspect, an embodiment of the present invention further provides a service processing apparatus, where the apparatus includes:
the retry message generation module is used for starting a target interface calling thread according to service requirements, calling a target interface through the target interface calling thread, generating a retry interface calling message when the calling of the target interface fails, and putting the retry interface calling message into a preset message queue;
and the retry message execution module is used for monitoring the preset message queue through a message monitoring thread, and when a retry interface calling message is monitored to enter the preset message queue, the retry message execution module repeatedly calls the target interface according to the retry interface calling message until the condition of stopping calling the target interface is met, so that the service requirement is completed.
Optionally, the service processing apparatus further includes an interface call alarm module, configured to record the number of times of repeatedly calling the target interface while repeatedly calling the target interface according to the retry interface call message;
and sending out warning information when the calling times reach preset times.
Optionally, the retry message execution module satisfies a condition for stopping the target interface from being called when the target interface is successfully called and the target service information is acquired; or when the calling is still failed after the number of times of repeatedly calling the target interface reaches the preset number of times, the condition of stopping calling the target interface is met.
Optionally, the retry message execution module is specifically configured to:
after the target interface is successfully called and target service information is acquired, updating the target service information into service information corresponding to the service requirement, executing service operation associated with the service requirement, and completing the service requirement; alternatively, the first and second electrodes may be,
and after the target interface is repeatedly called for a preset number of times and is still failed to be called, feeding back the result of the failed interface calling to the service information corresponding to the service requirement, and ending the service flow.
Optionally, the retry message execution module is further configured to:
and repeatedly calling the target interface according to the message consumption time interval in the message consumption strategy of the message queue management platform.
Optionally, the service processing apparatus further includes a message identifier adding module, configured to set, when it is monitored that a retry interface call message enters the preset message queue, a key value of the retry interface call message queue message as an identifier of the service requirement;
correspondingly, the retry message execution module is further configured to:
before the target interface is repeatedly called according to the retry interface calling message, identifying a key value of the retry interface calling message, and determining whether the retry interface calling message is executed.
Optionally, the business requirement includes an order management business requirement.
In a third aspect, an embodiment of the present invention further provides a server, where the server includes:
one or more processors;
a memory for storing one or more programs;
when executed by the one or more processors, cause the one or more processors to implement a service processing method as provided by any of the embodiments of the invention.
In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements a service processing method as provided in any embodiment of the present invention.
The embodiment of the invention has the following advantages or beneficial effects:
according to the embodiment of the invention, a target interface calling thread is started according to a service requirement, the target interface is called through the target interface calling thread, a retry interface calling message is generated when the calling of the target interface fails, and then when a retry interface calling message enters a preset message queue, a new target interface calling thread is started according to the retry interface calling message through a message monitoring thread to repeatedly call the target interface until a condition of stopping calling the target interface is met, so that the service requirement is completed; the problem of utilize the serial repeated interface of calling of single thread to lead to the thread to block among the prior art, influence system's wholeness can be solved to and use the scene restriction to the adoption timing task mode to retry to call the interface can be solved, realized adopting asynchronous mechanism, with the step decoupling of business main flow and calling target interface mutually, make interface call independent with the main flow, thereby guaranteed system performance, stability, the use scene of extension application simultaneously makes it more have the commonality.
Drawings
Fig. 1 is a flowchart of a service processing method according to an embodiment of the present invention;
fig. 2 is a signaling diagram of a retry interface call message according to an embodiment of the present invention;
fig. 3 is a flowchart of a service processing method according to a second embodiment of the present invention;
fig. 4 is a flowchart of retry of interface call according to the second embodiment of the present invention;
fig. 5 is a schematic structural diagram of a service processing apparatus according to a third embodiment of the present invention;
fig. 6 is a schematic structural diagram of a server according to a fourth embodiment of the present invention.
Detailed Description
The present invention will be described in further detail with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be further noted that, for the convenience of description, only some of the structures related to the present invention are shown in the drawings, not all of the structures.
Example one
Fig. 1 is a flowchart of a service processing method according to an embodiment of the present invention, which is applicable to a situation where an interface call fails and retries are performed. The method can be executed by a device configured for service processing, and the device can be realized by software and/or hardware and is integrated in an electronic device with application development function.
As shown in fig. 1, the service processing method includes the following steps:
s110, starting a target interface calling thread according to business requirements, calling a target interface through the target interface calling thread, generating a retry interface calling message when the calling of the target interface fails, and putting the retry interface calling message into a preset message queue.
For example, a link in the service flow in the system a is to acquire a message generated by the system B and related to the service in the system a, and then the system a needs to establish a connection with the system B to acquire corresponding information or complete corresponding operations. Accordingly, the channel through which the system a can establish a connection with the system B is the target interface.
Specifically, when the system detects that there is a service requirement, a target interface calling thread is started, and the target interface is called through the thread to acquire corresponding service information or complete a corresponding service instruction and obtain feedback. However, due to the fluctuation of network signals or system failure, the calling of the target interface fails, and the service requirement for calling the target interface cannot be fulfilled. In this embodiment, when the target interface call fails, a retry interface call message is generated, and the retry interface call message is placed in a preset message queue, so that the service system starts a new thread to retry calling the target interface. Instead, in a thread calling the target interface, the calling of the target interface is retried all the time, and message feedback of successful interface calling is waited.
S120, monitoring the preset message queue through a message monitoring thread, and when it is monitored that a retry interface calling message enters the preset message queue, repeatedly calling the target interface according to the retry interface calling message until the condition of stopping calling the target interface is met, so as to complete the service requirement.
The message monitoring thread is used for monitoring a retry interface calling message in a preset queue message, namely a new thread which is started for realizing the retry interface calling operation. When the retry interface calling information is monitored, the retry interface calling information is analyzed, and a corresponding target interface is called according to an analysis result.
Further, when retrying the target interface successfully, the target service information related to the service requirement is acquired, for example, in a hospital registration system, an interface of a payment system is called to complete a registration payment task, and after calling the interface of the payment system, feedback information such as a payment entry or successful payment is obtained, so that the current target interface calling task can be completed, and the service requirement is realized. And when the calling of the retry target interface fails, generating a retry interface calling message again according to a feedback result of the calling failure, putting the retry interface calling message into a preset message queue, monitoring and executing the retry interface calling message by the message monitoring thread until the number of times of retrying the calling of the target interface reaches the preset number, feeding back the calling failure message, and finishing the service requirement of calling the interface. The preset number may be determined according to a parameter set by a queue message consumption policy of the message queue management platform, for example, the upper limit number of times of retrying to call the target interface is 5 times. Then, when the retry interface call message is monitored in the 6 th time, the message monitoring thread is ended and the target interface call is not retried.
In a preferred real-time manner, the process of producing and consuming the retry interface call message may refer to the signaling diagram of the retry interface call message shown in fig. 2.
Specifically, in fig. 2, the producer and listener of the retry (interface call) message are both the business systems that generate the business requirement for calling the target interface call. After the service system fails to call the target interface, a retry interface call message is generated, and the retry interface call message is put into a preset message queue. When a retry message listener hears a retry interface calling message, a key value of the retry interface calling message queue message is set as an identifier of a service requirement, so that whether the retry message is consumed or not is verified according to the identifier when a retry target interface calling is executed subsequently, each retry message is guaranteed to be consumed only once, and the consumption power of the message is guaranteed.
In addition, when the retry message listener calls the target interface repeatedly according to the monitored retry interface call message, the call times of the target interface repeatedly called can be recorded; and when the calling times reach the preset times, warning information is sent out, so that system maintenance personnel can master the calling failure information of the target interface in the shortest time and process the calling failure information. The preset number of the upper limit of the number of calls of the repeatedly called target interface may be a parameter of a message consumption policy configured by the message queue management console. Furthermore, a target interface call retry mechanism can be relied on a message queue management console, and retry interval time is further realized by configuring a message consumption strategy, namely, according to a message consumption time interval in the message consumption strategy of the message queue management platform, a consumption retry interface calls a message and repeatedly calls a target interface. In the process of consuming the retry interface call message each time, if the call still fails, the retry interface call message is matched with a consumption strategy configured by a queue message management platform to determine whether to retry again, and if the retry is needed, the call result is fed back to a retry message producer.
According to the technical scheme of the embodiment, a target interface calling thread is started according to a service requirement, the target interface is called through the target interface calling thread, a retry interface calling message is generated when the calling of the target interface fails, and then when a retry interface calling message enters a preset message queue, a new target interface calling thread is started according to the retry interface calling message through a message monitoring thread to repeatedly call the target interface until a condition of stopping calling of the target interface is met, so that the service requirement is completed; the problem of utilize the serial repeated interface of calling of single thread to lead to the thread to block among the prior art, influence system's wholeness can be solved to and use the scene restriction to the adoption timing task mode to retry to call the interface can be solved, realized adopting asynchronous mechanism, with the step decoupling of business main flow and calling target interface mutually, make interface call independent with the main flow, thereby guaranteed system performance, stability, the use scene of extension application simultaneously makes it more have the commonality.
Example two
Fig. 3 is a flowchart of a service processing method according to a second embodiment of the present invention, where this embodiment is applicable to a situation where an asynchronous mechanism is used to retry interface call in an order management scenario, and the service processing method in the second embodiment of the present invention is the same as the service processing method in the first embodiment of the present invention. The method can be executed by a service processing device, which can be implemented by software and/or hardware, and is integrated in a server device with an application development function.
As shown in fig. 3, the service processing method includes the following steps:
s210, monitoring order warehouse-out information of the order generation system, analyzing the order warehouse-out information and obtaining order information.
The order generation system can be any shopping platform system, when a user buys physical articles or virtual articles, an order is generated, the warehouse management subsystem in the order generation system sends out order warehouse-out information to a preset message queue to transfer when the articles are out of the warehouse according to the order information of each order, and the order warehouse-out information comprises information such as order numbers, order article names, warehouse-out time, logistics information and the like.
S220, when the order information comprises an order taking management identifier, storing the order information into a database of a service management system, starting a target interface calling thread according to the order management service requirement, and calling a target interface through the target interface calling thread.
Due to different types of articles in the orders, some orders need to be managed further in a unified manner, for example, the orders for purchasing special articles need to be documented and monitored, or associated virtual services are provided for users who purchase certain articles, and the like, which all need to manage orders with management needs in a unified manner, and further need to match management serial numbers for the orders with management needs.
When the order ex-warehouse information is analyzed and the order information is identified to contain the order management identification, the order information is stored in a database of the service management system to be backed up, a target interface calling thread is started according to the order management service requirement, and the target interface is called through the target interface calling thread. The description is about a service management system, that is, a system for monitoring order delivery information. The target interface can be a serialization center system, an interface of the serialization center is called, a serial number is obtained for an order needing to be managed, and unified management is facilitated; the target interface can also be a customer service center, which calls the customer service center interface to match corresponding additional service information for the goods purchased by the user, or the target interface can also be any system interface related to the order management service, so as to obtain corresponding target service information and complete the service requirement, so as to execute subsequent related service logic operation.
And S230, generating a retry interface calling message when the calling of the target interface fails, and putting the retry interface calling message into a preset message queue.
Due to the fluctuation of network signals or system faults and other reasons, the calling of the target interface fails, and the service requirement for calling the target interface cannot be completed, such as the order serial number fed back by the target interface cannot be acquired. In this embodiment, when the target interface call fails, a retry interface call message is generated, and the retry interface call message is placed in a preset message queue, so that the service management system starts another new thread to retry to call the target interface.
S240, monitoring the preset message queue through a message monitoring thread, and when a retry interface calling message is monitored to enter the preset message queue, repeatedly calling the target interface according to the retry interface calling message until the condition of stopping calling the target interface is met, updating the calling result of the target interface into the database, and completing the order management service requirement.
When the retry interface calling information is monitored, the retry interface calling information is analyzed, corresponding order information can be obtained, and a corresponding target interface is called according to an analysis result. When the retry of the target interface is successful, the target service information related to the order management service requirement is obtained, and the current target interface calling task can be completed to realize the service requirement. And when the calling of the retry target interface fails, generating a retry interface calling message again according to a feedback result of the calling failure, putting the retry interface calling message into a preset message queue, monitoring and executing the retry interface calling message by the message monitoring thread until the number of times of retrying the calling of the target interface reaches the preset number, feeding back the calling failure message, and finishing the service requirement of calling the interface. The preset number may be determined according to a parameter set by a queue message consumption policy of the message queue management platform, for example, the upper limit number of times of retrying to call the target interface is 5 times. Then, when the retry interface call message is monitored in the 6 th time, the message monitoring thread is ended and the target interface call is not retried.
Specifically, in the technical solution of this embodiment, the interface call retry flowchart shown in fig. 4 may also be referred to. In the flow chart, when the target interface is successfully called and the target service information is acquired, the information is also fed back to the user to inform the user of corresponding operation.
In particular, the retry interface calling scheme of the embodiment is not only suitable for order management services of some large-scale e-commerce systems, but also suitable for multi-service scenarios such as other communication, medical treatment, insurance, banking and the like.
According to the technical scheme of the embodiment, order ex-warehouse information of an order generation system is monitored, an order needing to be managed is identified according to the order ex-warehouse information, a target interface calling thread is started according to business requirements of order management, a target interface is called through the target interface calling thread, a retry interface calling message is generated when calling of the target interface fails, and then when the fact that a retry interface calling message enters a preset message queue is monitored through a message monitoring thread, a new target interface calling thread is started according to the retry interface calling message to repeatedly call the target interface until the condition of stopping calling of the target interface is met, so that order management related operations are achieved; the problem of utilize the serial repeated interface of calling of single thread to lead to the thread to block when carrying out order management operation among the prior art, influence system's wholeness can be solved to and use the scene restriction to the adoption timing task mode retries and calls the interface can be had is solved, realized adopting asynchronous mechanism, the step decoupling mutually of business main flow and calling target interface for the interface is called and the main flow is independent, thereby guaranteed system performance, stability, the use scene of extension application simultaneously makes it more have the commonality.
The following is an embodiment of a service processing apparatus provided in an embodiment of the present invention, and the apparatus and the service processing method in the foregoing embodiments belong to the same inventive concept, and can implement the service processing method in the foregoing embodiments. For details which are not described in detail in the embodiments of the service processing device, reference may be made to the embodiments of the service processing method described above.
EXAMPLE III
Fig. 5 is a schematic structural diagram of a service processing apparatus according to a third embodiment of the present invention, which is applicable to a situation where an interface call fails and retries are performed.
As shown in fig. 5, the service processing apparatus includes a retry message generation module 310 and a retry message execution module 320.
The retry message generation module 310 is configured to start a target interface calling thread according to a service requirement, call a target interface through the target interface calling thread, generate a retry interface calling message when the calling of the target interface fails, and place the retry interface calling message in a preset message queue; and the retry message execution module 320 is configured to monitor the preset message queue through a message monitoring thread, and when it is monitored that a retry interface calling message enters the preset message queue, repeatedly call the target interface according to the retry interface calling message until a condition for stopping calling of the target interface is met, so as to complete the service requirement.
According to the technical scheme of the embodiment, a target interface calling thread is started according to a service requirement, the target interface is called through the target interface calling thread, a retry interface calling message is generated when the calling of the target interface fails, and then when a retry interface calling message enters a preset message queue, a new target interface calling thread is started according to the retry interface calling message through a message monitoring thread to repeatedly call the target interface until a condition of stopping calling of the target interface is met, so that the service requirement is completed; the problem of utilize the serial repeated interface of calling of single thread to lead to the thread to block among the prior art, influence system's wholeness can be solved to and use the scene restriction to the adoption timing task mode to retry to call the interface can be solved, realized adopting asynchronous mechanism, with the step decoupling of business main flow and calling target interface mutually, make interface call independent with the main flow, thereby guaranteed system performance, stability, the use scene of extension application simultaneously makes it more have the commonality.
Optionally, the service processing apparatus further includes an interface call alarm module, configured to record the number of times of repeatedly calling the target interface while repeatedly calling the target interface according to the retry interface call message;
and sending out warning information when the calling times reach preset times.
Optionally, the retry message execution module 320, when the target interface is successfully called and the target service information is obtained, meets the condition of stopping calling the target interface; or when the calling is still failed after the number of times of repeatedly calling the target interface reaches the preset number of times, the condition of stopping calling the target interface is met.
Optionally, the retry message execution module 320 is specifically configured to:
after the target interface is successfully called and target service information is acquired, updating the target service information into service information corresponding to the service requirement, executing service operation associated with the service requirement, and completing the service requirement; alternatively, the first and second electrodes may be,
and after the target interface is repeatedly called for a preset number of times and is still failed to be called, feeding back the result of the failed interface calling to the service information corresponding to the service requirement, and ending the service flow.
Optionally, the retry message execution module 320 is further configured to:
and repeatedly calling the target interface according to the message consumption time interval in the message consumption strategy of the message queue management platform.
Optionally, the service processing apparatus further includes a message identifier adding module, configured to set, when it is monitored that a retry interface call message enters the preset message queue, a key value of the retry interface call message queue message as an identifier of the service requirement;
accordingly, the retry message execution module 320 is further configured to:
before the target interface is repeatedly called according to the retry interface calling message, identifying a key value of the retry interface calling message, and determining whether the retry interface calling message is executed.
Optionally, the business requirement includes an order management business requirement.
The service processing device provided by the embodiment of the invention can execute the service processing method provided by any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.
Example four
Fig. 6 is a schematic structural diagram of a server according to a fourth embodiment of the present invention. FIG. 6 illustrates a block diagram of an exemplary server 12 suitable for use in implementing embodiments of the present invention. The server 12 shown in fig. 6 is only an example, and should not bring any limitation to the function and the scope of use of the embodiment of the present invention. The server 12 may be any terminal device with computing capability, such as a smart controller and a terminal device such as a server and a mobile phone.
As shown in FIG. 6, the server 12 is in the form of a general purpose computing device. The components of the server 12 may include, but are not limited to: one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including the system memory 28 and the processing unit 16.
The server 12 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by server 12 and includes both volatile and nonvolatile media, removable and non-removable media.
The system memory 28 may include computer system readable media in the form of volatile memory, such as Random Access Memory (RAM)30 and/or cache memory 32. The server 12 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 34 may be used to read from and write to non-removable, nonvolatile magnetic media (not shown in FIG. 6, and commonly referred to as a "hard drive"). Although not shown in FIG. 6, a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 by one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.
A program/utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which examples or some combination thereof may comprise an implementation of a network environment. Program modules 42 generally carry out the functions and/or methodologies of the described embodiments of the invention.
The server 12 may also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), with one or more devices that enable a user to interact with the server 12, and/or with any devices (e.g., network card, modem, etc.) that enable the server 12 to communicate with one or more other computing devices. Such communication may be through an input/output (I/O) interface 22. Also, the server 12 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the Internet) via the network adapter 20. As shown, the network adapter 20 communicates with the other modules of the server 12 via the bus 18. It should be appreciated that although not shown in FIG. 6, other hardware and/or software modules may be used in conjunction with the server 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.
The processing unit 16 executes various functional applications and data processing by executing programs stored in the system memory 28, for example, to implement a service processing method provided by the embodiment of the present invention, the method includes:
starting a target interface calling thread according to service requirements, calling a target interface through the target interface calling thread, generating a retry interface calling message when the calling of the target interface fails, and putting the retry interface calling message into a preset message queue;
and monitoring the preset message queue through a message monitoring thread, and when a retry interface calling message enters the preset message queue, repeatedly calling the target interface according to the retry interface calling message until the condition of stopping calling the target interface is met, so as to complete the service requirement.
EXAMPLE five
The fifth embodiment provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements a service processing method according to any embodiment of the present invention, and the method includes:
starting a target interface calling thread according to service requirements, calling a target interface through the target interface calling thread, generating a retry interface calling message when the calling of the target interface fails, and putting the retry interface calling message into a preset message queue;
and monitoring the preset message queue through a message monitoring thread, and when a retry interface calling message enters the preset message queue, repeatedly calling the target interface according to the retry interface calling message until the condition of stopping calling the target interface is met, so as to complete the service requirement.
Computer storage media for embodiments of the invention may employ any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer-readable storage medium may be, for example but not limited to: an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: 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 context of this document, 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.
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.
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).
It will be understood by those skilled in the art that the modules or steps of the invention described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of computing devices, and optionally they may be implemented by program code executable by a computing device, such that it may be stored in a memory device and executed by a computing device, or it may be separately fabricated into various integrated circuit modules, or it may be fabricated by fabricating a plurality of modules or steps thereof into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.
It is to be noted that the foregoing is only illustrative of the preferred embodiments of the present invention and the technical principles employed. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, although the present invention has been described in greater detail by the above embodiments, the present invention is not limited to the above embodiments, and may include other equivalent embodiments without departing from the spirit of the present invention, and the scope of the present invention is determined by the scope of the appended claims.
Claims (10)
1. A method for processing a service, comprising:
starting a target interface calling thread according to service requirements, calling a target interface through the target interface calling thread, generating a retry interface calling message when the calling of the target interface fails, and putting the retry interface calling message into a preset message queue;
and monitoring the preset message queue through a message monitoring thread, and when a retry interface calling message enters the preset message queue, repeatedly calling the target interface according to the retry interface calling message until the condition of stopping calling the target interface is met, so as to complete the service requirement.
2. The method of claim 1, wherein while repeatedly invoking the target interface in accordance with the retry interface invocation message, the method further comprises:
recording the calling times of repeatedly calling the target interface;
and sending out warning information when the calling times reach preset times.
3. The method of claim 1, wherein satisfying the condition for stopping the target interface call comprises:
successfully calling the target interface and acquiring target service information; alternatively, the first and second electrodes may be,
and the calling is still failed after the number of times of repeatedly calling the target interface reaches the preset number.
4. The method of claim 3, wherein repeatedly invoking the target interface according to the retry interface invocation message until a condition for stopping target interface invocation is satisfied to fulfill the service requirement, comprises:
after the target interface is successfully called and target service information is acquired, updating the target service information into service information corresponding to the service requirement, executing service operation associated with the service requirement, and completing the service requirement; alternatively, the first and second electrodes may be,
and after the target interface is repeatedly called for a preset number of times and is still failed to be called, feeding back the result of the failed interface calling to the service information corresponding to the service requirement, and ending the service flow.
5. The method of claim 1, wherein said repeatedly invoking said target interface according to said retry interface invocation message comprises:
and repeatedly calling the target interface according to the message consumption time interval in the message consumption strategy of the message queue management platform.
6. The method of claim 1, wherein when it is monitored that a retry interface call message enters the preset message queue, the method further comprises:
setting a key value of the retry interface calling message queue message as the identification of the service requirement;
correspondingly, before repeatedly calling the target interface according to the retry interface calling message, the method further comprises:
and identifying a key value of the retry interface calling message, and determining whether the retry interface calling message is executed.
7. The method of any of claims 1-6, wherein the business requirements comprise order management business requirements.
8. A traffic processing apparatus, comprising:
the retry message generation module is used for starting a target interface calling thread according to service requirements, calling a target interface through the target interface calling thread, generating a retry interface calling message when the calling of the target interface fails, and putting the retry interface calling message into a preset message queue;
and the retry message execution module is used for monitoring the preset message queue through a message monitoring thread, and when a retry interface calling message is monitored to enter the preset message queue, the retry message execution module repeatedly calls the target interface according to the retry interface calling message until the condition of stopping calling the target interface is met, so that the service requirement is completed.
9. A server, characterized in that the server comprises:
one or more processors;
a memory for storing one or more programs;
when executed by the one or more processors, cause the one or more processors to implement the business process method of any one of claims 1-7.
10. A computer-readable storage medium, on which a computer program is stored, which program, when being executed by a processor, is adapted to carry out the service processing method according to any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110126486.3A CN113760500A (en) | 2021-01-29 | 2021-01-29 | Service processing method, device, server and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110126486.3A CN113760500A (en) | 2021-01-29 | 2021-01-29 | Service processing method, device, server and medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113760500A true CN113760500A (en) | 2021-12-07 |
Family
ID=78786532
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110126486.3A Pending CN113760500A (en) | 2021-01-29 | 2021-01-29 | Service processing method, device, server and medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113760500A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115174296A (en) * | 2022-05-30 | 2022-10-11 | 青岛海尔科技有限公司 | Equipment function access method, device, storage medium and electronic device |
| CN115333942A (en) * | 2022-08-10 | 2022-11-11 | 北京搜房科技发展有限公司 | Event retry method and device, storage medium and electronic equipment |
-
2021
- 2021-01-29 CN CN202110126486.3A patent/CN113760500A/en active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115174296A (en) * | 2022-05-30 | 2022-10-11 | 青岛海尔科技有限公司 | Equipment function access method, device, storage medium and electronic device |
| CN115174296B (en) * | 2022-05-30 | 2024-03-22 | 青岛海尔科技有限公司 | Equipment function access method and device, storage medium and electronic device |
| CN115333942A (en) * | 2022-08-10 | 2022-11-11 | 北京搜房科技发展有限公司 | Event retry method and device, storage medium and electronic equipment |
| CN115333942B (en) * | 2022-08-10 | 2023-10-27 | 北京搜房科技发展有限公司 | Event retry method and device, storage medium and electronic equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108595316B (en) | Lifecycle management method, manager, device, and medium for distributed application | |
| WO2021042849A1 (en) | Cloud platform, service processing method, command interface and computer device | |
| CN113760500A (en) | Service processing method, device, server and medium | |
| CN111858007A (en) | Task scheduling method and device based on message middleware | |
| CN111813418B (en) | Distributed link tracking method, device, computer equipment and storage medium | |
| US20080216093A1 (en) | Method, system and computer program for monitoring components in a service framework | |
| CN111324622A (en) | Resource first-aid-purchase processing method, device, equipment and storage medium | |
| CN112598529B (en) | Data processing method and device, computer readable storage medium and electronic equipment | |
| CN107656999B (en) | Call history tracing method and device, electronic equipment and storage medium | |
| CN113760386A (en) | Access control system, access control method and storage medium | |
| CN112581257A (en) | Dispute service management method, system, device and medium supporting different card organizations | |
| CN112445860A (en) | Method and device for processing distributed transaction | |
| CN113919310A (en) | Short message content determination method and device, electronic equipment and storage medium | |
| CN114265633A (en) | Application parameter configuration and query method of self-service equipment, equipment and storage medium | |
| CN114528108A (en) | Serial number generation method, device, server and storage medium | |
| CN113763094A (en) | Service information processing method, device, server, medium and system | |
| CN107704557B (en) | Processing method and device for operating mutually exclusive data, computer equipment and storage medium | |
| CN111061576A (en) | Method and system for creating entity object | |
| CN111383025B (en) | Method and device for forwarding wind control data and electronic equipment | |
| CN117055977B (en) | Method and device for linking data between code-free applications | |
| CN112306819B (en) | Abnormal event playback method and device, electronic equipment and storage medium | |
| US20230214766A1 (en) | Product management method and related device | |
| CN109376023B (en) | Method and equipment for generating calling information and issuing return code group | |
| CN113761508A (en) | Information processing method, information processing device, electronic equipment and storage medium | |
| CN117114613A (en) | Flow engine, method, equipment and program product for business flow control |
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 |