Non-critical transaction decoupling method, device and storage medium in high concurrency scenarios

Abstract

The present invention discloses a method, device and storage medium for decoupling non-critical transactions in high-concurrency scenarios. A method for decoupling non-critical transactions in high-concurrency scenarios includes: obtaining a first transaction message and at least one other transaction message tightly coupled with the first transaction message; determining at least one second transaction message among other transaction messages tightly coupled with the first transaction message, the priority of at least one second transaction message being lower than a first preset threshold; sending the first transaction message and other transaction messages tightly coupled with the first message except at least one second transaction message to the receiver of each transaction message; sending the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message receiver at a time node after the time node of sending the first transaction message. Asynchronous execution of tightly coupled transactions is achieved, which can effectively block the spread of blocking in high-concurrency scenarios.

Description

Technical Field

[0001] Embodiments of the present invention relate to information processing technology, and more particularly to a method, device and storage medium for decoupling non-critical transactions in a high-concurrency scenario. Background Art

[0002] The various transaction functions of traditional centralized transactions are tightly coupled. Taking the common order system as an example, the business logic after the user clicks the [Place Order] button may include: deducting inventory, generating corresponding documents, sending red envelopes, and sending SMS notifications.

[0003] In the early stages of business development, these logics may be put together and executed synchronously, but as the business develops and the order volume grows, if new technologies are used to improve performance, multiple business performances may be improved at the same time, which is obviously not economical, and the performance improvement space is limited due to the numerous functions on the link. At the same time, the transaction peak after the superposition of multiple similar products may cause the traditional centralized transaction to be blocked, and even spread to other business processing functions due to the tightly coupled design.

[0004] Therefore, in a high-concurrency centralized transaction scenario, how to deal with the blockage caused by a large number of tightly coupled transactions is an urgent problem to be solved. Summary of the invention

[0005] The present invention provides a method, device and storage medium for decoupling non-critical transactions in high-concurrency scenarios, which can solve the blockage caused by a large number of tightly coupled transactions in high-concurrency scenarios.

[0006] In a first aspect, an embodiment of the present invention provides a method for decoupling non-critical transactions in a high-concurrency scenario, comprising:

[0007] Acquire a first transaction message and at least one other transaction message tightly coupled with the first transaction message, wherein the first transaction message has at least one other transaction message tightly coupled with the first transaction message;

[0008] Determine at least one second transaction message among other transaction messages that are closely coupled with the first transaction message, wherein a priority of the at least one second transaction message is lower than a first preset threshold;

[0009] Sending the first transaction message and other transaction messages among other transaction messages tightly coupled with the first message except for at least one second transaction message to receivers of the transaction messages;

[0010] At a time node after the time node of sending the first transaction message, a second transaction message corresponding to the second transaction message sending request is sent to the corresponding transaction message recipient.

[0011] In a second aspect, an embodiment of the present invention further provides a non-critical transaction decoupling device in a high-concurrency scenario, including:

[0012] A receiving module, configured to obtain a first transaction message and at least one other transaction message tightly coupled with the first transaction message, wherein the first transaction message has at least one other transaction message tightly coupled with the first transaction message;

[0013] a decoupling module, configured to determine at least one second transaction message among other transaction messages tightly coupled with the first transaction message, wherein the priority of the at least one second transaction message is lower than a first preset threshold;

[0014] A sending module is used to send the first transaction message and other transaction messages tightly coupled with the first message except at least one second transaction message to the recipients of each transaction message; and send the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient at a time node after the time node of sending the first transaction message.

[0015] In a third aspect, an embodiment of the present invention further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for decoupling non-critical transactions in a high-concurrency scenario as in the first aspect is implemented.

[0016] In a third aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the method for decoupling non-critical transactions in a high-concurrency scenario as in the first aspect is implemented.

[0017] The non-critical transaction decoupling method, device and storage medium in a high concurrency scenario provided by an embodiment of the present invention first obtain a first transaction message and at least one other transaction message tightly coupled with the first transaction message, then determine at least one second transaction message among the other transaction messages tightly coupled with the first transaction message whose priority is lower than a first preset threshold, and then send the first transaction message and other transaction messages except at least one second transaction message among the first transaction message and other transaction messages tightly coupled with the first message to recipients of each transaction message; finally, when a second transaction message sending request is received, the second transaction message corresponding to the second transaction message sending request is sent to the corresponding transaction message recipient, thereby realizing asynchronous execution of tightly coupled transactions and effectively isolating the spread of blocking in high concurrency scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A flowchart of decoupling non-critical transactions in a high-concurrency scenario provided by an embodiment of the present invention;

[0019] Figure 2 A flowchart of decoupling non-critical transactions in another high-concurrency scenario provided by an embodiment of the present invention;

[0020] Figure 3 This is a schematic diagram of the structure of the RabbitMQ application;

[0021] Figure 4 A schematic diagram of the structure of a non-critical transaction decoupling device in a high-concurrency scenario provided by an embodiment of the present invention;

[0022] Figure 5 A schematic diagram of the structure of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0023] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

[0024] Figure 1 A flowchart of decoupling non-critical transactions in a high-concurrency scenario provided by an embodiment of the present invention is as follows: Figure 1 As shown, the non-critical transaction decoupling method in a high-concurrency scenario provided by this embodiment includes:

[0025] Step S110: acquiring a first transaction message and at least one other transaction message tightly coupled with the first transaction message, wherein the first transaction message has at least one other transaction message tightly coupled with the first transaction message.

[0026] The non-critical transaction decoupling method in a high-concurrency scenario provided by this embodiment is applied to a server that processes transaction information. The server that processes transaction messages is set at a supplier or cloud that provides transaction services. The supplier that provides transaction services is, for example, a bank, a transaction platform, a payment platform, etc. For any transaction operation, there are other operations associated with it that need to be processed synchronously. For example, for shopping on a transaction platform, after placing an order and completing payment, the transaction operation corresponding to the payment has at least multiple operations such as order generation, payment account deduction, transaction success notification, account balance change notification, platform inventory change, etc. associated with it. Among them, some transaction operations corresponding to the executed transaction operations need to be executed synchronously to ensure the normal progress of the transaction, and whether some transaction operations such as multiple notification messages are executed synchronously will not affect the success of the transaction. Therefore, the non-critical transaction decoupling method in a high-concurrency scenario provided by this embodiment decouples transaction messages with coupling relationships so that tightly coupled transaction messages can be executed asynchronously, thereby solving the blocking caused when tightly coupled transaction operations in high-concurrency scenarios are executed synchronously.

[0027] First, for any transaction operation, a notification message will be sent to the server, and the server will execute the corresponding transaction operation according to the received notification message. Therefore, in an embodiment of the present application, each transaction operation is referred to as a transaction message. When the first transaction message is obtained, at least one other transaction message tightly coupled with the first transaction message can be determined first. The first transaction message can be a transaction message corresponding to any transaction operation, and the first transaction message has at least one other transaction message tightly coupled with it. Other transaction messages tightly coupled with the first transaction message refer to other transaction messages that need to be executed synchronously with the first transaction message according to preset transaction message processing rules. The first transaction message may carry indication information of other transaction messages tightly coupled with it, or a coupling relationship table of each transaction message is stored in the server, and the server can determine other transaction messages tightly coupled with the first transaction message according to the stored coupling relationship table.

[0028] Step S120: determining at least one second transaction message among other transaction messages that are tightly coupled with the first transaction message, wherein the priority of the at least one second transaction message is lower than a first preset threshold.

[0029] In a high-concurrency scenario, many transaction messages may be sent to the server at the same time and need to be executed synchronously. If each transaction message has multiple other transaction messages tightly coupled with it, there will be a large number of transaction messages that need to be executed synchronously, which may cause transaction message blocking.

[0030] Therefore, after obtaining the first transaction message and determining other transaction messages that are tightly coupled with the first transaction message, the above messages are not directly executed synchronously, but the priority of each transaction message is determined. Whether different transaction messages are executed synchronously has different effects on whether the transaction can be successfully executed, and also has different effects on the user experience. Different priorities can be set for each transaction operation according to the degree of influence of each transaction message on the success of the transaction, the degree of influence on the user experience, or the degree of influence on other factors in the transaction process. The higher the priority of the transaction information, the greater the impact on the transaction process. For transaction information with a priority lower than the preset threshold, whether it is executed synchronously has little effect on the successful execution of the transaction operation and the user experience. Therefore, this part of the transaction information can be executed asynchronously with the first transaction message, thereby reducing the number of synchronously executed transaction messages to reduce the occurrence of blocking.

[0031] The priority of each transaction message may be preset in the server or carried in each transaction message. The server may determine that at least one second transaction message has a priority lower than a first preset threshold among other transaction messages that are closely coupled with the first transaction message. The first preset threshold may be preset or adjusted in real time according to the load of the server.

[0032] Step S130: Send the first transaction message and other transaction messages tightly coupled with the first message except for at least one second transaction message to receivers of the transaction messages.

[0033] After determining at least one second transaction message, the at least one second transaction message may not be executed synchronously with the first transaction message, and then the first transaction message and other transaction messages except the at least one second transaction message among other transaction messages tightly coupled with the first message may be sent to the receivers of each transaction message. After receiving each transaction message, the receivers of each transaction message may synchronously execute the transaction operations corresponding to each transaction message.

[0034] Step S140: sending a second transaction message corresponding to the second transaction message sending request to a corresponding transaction message recipient at a time point after the time point of sending the first transaction message.

[0035] For at least one second transaction message that is not executed synchronously with the first transaction message, although it is not executed synchronously with the first transaction message and will not affect the result of the transaction operation corresponding to the first transaction message, it still needs to be executed, but its execution is asynchronous with the first transaction message. Therefore, the second transaction message corresponding to the second transaction message sending request can be sent to the corresponding transaction message recipient at a time node after the time node of sending the first transaction message, so as to execute the transaction operation corresponding to the second transaction message.

[0036] Specifically, upon receiving the second transaction message sending request, the server may send the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient. Alternatively, the server may also send the second transaction message to the corresponding recipient according to a preset strategy at a time node after the time node of sending the first transaction message, for example, after the first transaction message is sent to the corresponding recipient, according to the current load of the server, when the load of the server is lower than a preset load threshold.

[0037] In this way, part of the second transaction message that is tightly coupled with the first transaction message will be executed asynchronously with the first transaction message, which can effectively block the spread of blocking in high-concurrency scenarios and fundamentally reduce the occurrence of blocking due to good performance and elastic expansion capabilities.

[0038] The non-critical transaction decoupling method in a high-concurrency scenario provided by this embodiment first obtains a first transaction message and at least one other transaction message tightly coupled with the first transaction message, then determines at least one second transaction message whose priority is lower than a first preset threshold among the other transaction messages tightly coupled with the first transaction message, and then sends the first transaction message and other transaction messages except at least one second transaction message among the other transaction messages tightly coupled with the first message to recipients of each transaction message; finally, upon receiving a second transaction message sending request, sending the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient, thereby realizing asynchronous execution of tightly coupled transactions and effectively isolating the spread of blocking in high-concurrency scenarios.

[0039] Figure 2 Another flowchart of decoupling non-critical transactions in a high-concurrency scenario provided by an embodiment of the present invention is as follows: Figure 2 As shown, the non-critical transaction decoupling method in a high-concurrency scenario provided by this embodiment includes:

[0040] Step S210: acquiring a first transaction message and at least one other transaction message tightly coupled with the first transaction message, wherein the first transaction message has at least one other transaction message tightly coupled with the first transaction message.

[0041] Step S220: According to a preset scheduling strategy, the first transaction message and other transaction messages tightly coupled with the first message are stored in at least one message queue.

[0042] Step S230: determining at least one second transaction message among other transaction messages that are tightly coupled with the first transaction message, wherein the priority of the at least one second transaction message is lower than a first preset threshold.

[0043] Step S240: sending the first transaction message and other transaction messages tightly coupled with the first message except at least one second transaction message among the transaction messages stored in at least one message queue to receivers of the transaction messages.

[0044] Step S250: sending a second transaction message corresponding to the second transaction message sending request to a corresponding transaction message recipient at a time point after the time point of sending the first transaction message.

[0045] The non-critical transaction decoupling method in a high concurrency scenario provided by this embodiment is Figure 1The difference between the illustrated embodiments is that transaction messages are stored and distributed in a message queue manner. The message queue can establish a message middleware for forwarding messages between the message sender and the message receiver. The main function of the message middleware is decoupling. The most standard usage is that the producer produces messages and transmits them to the queue, and the consumer takes the messages from the queue and processes them. The producer does not need to care who consumes them, and the consumer does not need to care who produces the messages, thereby achieving the purpose of decoupling.

[0046] After obtaining the first transaction message and at least one other transaction message that is tightly coupled with the first transaction message, the first transaction message and the other transaction messages that are tightly coupled with the first message are stored in at least one message queue according to a preset scheduling strategy. That is, various transaction messages are stored in the message queue, and the message queue distributes the messages. After determining at least one second transaction message among the other transaction messages that are tightly coupled with the first transaction message, the first transaction message and the other transaction messages that are tightly coupled with the first message, except for at least one second transaction message, are sent to the recipients of each transaction message among the transaction messages stored in at least one message queue. Finally, when a second transaction message sending request is received, the second transaction message corresponding to the second transaction message sending request stored in at least one message queue is sent to the corresponding transaction message recipient.

[0047] Further, after step S204, after the first transaction message and the other transaction messages tightly coupled with the first message except for at least one second transaction message are sent, a stop sending message may be sent to at least one message queue, and the stop sending message is used to instruct at least one message queue to stop sending at least one second transaction message. Since the second transaction message is tightly coupled with the first transaction message, a stop sending message may be actively sent to prevent the second transaction message from being automatically sent to the corresponding recipient.

[0048] The message queue can be based on the Advanced Message Queuing Protocol (AMQP), for example. AMQP is an open standard for application layer protocols and is designed for message-oriented middleware. Message middleware is mainly used for decoupling between components. The sender of a message does not need to know the existence of a message user, and vice versa. The main features of AMQP are message orientation, queues, routing (including point-to-point and publish / subscribe), reliability, and security. Furthermore, the AMQP-based RabbitMQ implementation can be used as a message queue for message middleware. RabbitMQ is an open source AMQP implementation. The server side is written in Erlang and supports a variety of clients, such as Python, Ruby, .NET, Java, JMS, C, PHP, ActionScript, XMPP, STOMP, etc., and supports AJAX. It is used to store and forward messages in distributed systems and performs well in terms of ease of use, scalability, and high availability.

[0049] RabbitMQ, as an open source message queue, is a message middleware that implements AMQP. It originated from the financial system and is used to store and forward messages in distributed systems. It performs well in terms of ease of use, scalability, and high availability. It is mainly used to implement asynchrony and decoupling of applications, and can also play the role of message buffering and message distribution. ConnectionFactory, Connection, and Channel are the most basic objects in the API provided by RabbitMQ. Connection is the socket link of RabbitMQ, which encapsulates some logic related to the socket protocol. ConnectionFactory is the manufacturing factory of Connection. Channel is the most important interface for dealing with RabbitMQ. Most business operations are completed in the Channel interface, including defining Queues, defining Exchanges, binding Queues and Exchanges, and publishing messages.

[0050] Usually when talking about queue services, there are three concepts: sender, queue, and receiver. RabbitMQ adds an extra layer of abstraction on top of this basic concept, adding an exchange between the sender and the queue. In this way, there is no direct connection between the sender and the queue. Instead, the sender sends the message to the exchange, and the exchange sends the message to the queue according to the scheduling strategy. Queue is an internal object of RabbitMQ, used to store messages. Messages in RabbitMQ can only be stored in Queue.

[0051] Figure 3The schematic diagram of the structure of RabbitMQ application is shown in FIG. 31, in which RabbitMQ 31 is set between message producer 32 and consumer 33. Message producer 32 is a program that sends messages to RabbitMQ 31, and consumer 33 is a program that gets messages from RabbitMQ 31. RabbitMQ 31 includes multiple switches 34 and multiple queues 35. Multiple message receivers 33 can subscribe to the same queue 35, which means that the messages in queue 35 will be evenly distributed to multiple consumers for processing, rather than each consumer receiving and processing all messages.

[0052] Taking a common order system as an example, the business logic after the user clicks the [Order] button may include: deducting inventory, generating corresponding documents, sending red envelopes, and sending SMS notifications. In the early stages of business development, these logics may be put together and executed synchronously. As the business develops and the order volume increases, the performance of the system service needs to be improved. At this time, some operations that do not need to take effect immediately can be split out for asynchronous execution, such as issuing red envelopes and sending SMS notifications. In this scenario, RabbitMQ can be used. After the main process of placing an order (such as deducting inventory and generating corresponding documents) is completed, a message is sent to RabbitMQ to quickly complete the main process, and another separate thread pulls the RabbitMQ message (or RabbitMQ pushes the message). When a message such as sending a red envelope or sending a text message is found in RabbitMQ, the corresponding business logic is executed.

[0053] The above are situations for business decoupling. Other common scenarios include eventual consistency, broadcasting, peak-shifting flow control, etc.

[0054] In another specific example, a complete payment process in a bank payment system can be roughly understood as follows: 1. A mobile banking application (APP) or H5 initiates a transaction and sends it to the payment system through the Enterprise Service Bus (ESB). 2. After receiving the transaction, the cashier microservice, which is connected to the ESB, first determines whether it is a payment transaction or a query transaction by the transaction name. If it is a payment transaction, it sends it to the payment microservice. 3 The payment microservice determines whether the transaction is a transaction of the bank or a transaction of another bank, and then sends it to the subsequent microservice to execute the specific transaction. 4. After the specific transaction is executed, the transaction result will be returned to the payment microservice, and then the payment microservice will send the specific transaction result to the record entry microservice. 5. After the record entry microservice receives the transaction result, it will insert the transaction result into the database and return the payment microservice processing result. 6. After the payment microservice gets the information returned by the record entry microservice, it returns the required information to the cashier microservice, and then the cashier returns the information to the mobile banking APP or H5.

[0055] In the fifth step above, the record entry microservice inserts the transaction result into the database, which is an operation in the bank payment system that does not need to take effect immediately, and the record entry microservice needs to insert the transaction information into the database. Therefore, when the transaction volume is large, the record entry microservice limits the efficiency of the entire transaction process, so RabbitMQ is introduced. After the main process of the transaction is completed, that is, after the fourth step above is completed, a message is sent to RabbitMQ to quickly complete the main process, and then another record entry microservice pulls the RabbitMQ message (or RabbitMQ pushes the message). When a message with a transaction record is found in RabbitMQ, the corresponding business logic is executed. That is, the fourth step above is modified to: after the specific transaction is completed, the transaction result will be returned to the payment microservice, and then the payment microservice sends the transaction result to RabbitMQ, and directly returns the required information to the cashier microservice.

[0056] The introduction of RabbitMQ not only reduces the coupling between projects but also speeds up the main process and plays a role in message buffering.

[0057] In addition, after the introduction of the message queue, the cluster composed of at least one message queue can have two modes, wherein in the normal mode, at least one message queue is respectively established in different servers in the service cluster. In the mirror mode, at least one message queue is established in each server in the service cluster. In the normal mode, according to the preset scheduling strategy, the first transaction message and other transaction messages tightly coupled with the first message are respectively stored in the message queues of different servers. At the time node after the time node of sending the first transaction message, if the second transaction message corresponding to the second transaction message sending request is not stored in the message queue of the first server, the first server reads the second transaction message from the message queue of the server storing the second transaction message corresponding to the second transaction message sending request and sends it to the corresponding transaction message recipient. In the mirror mode, according to the preset scheduling strategy, the first transaction message and other transaction messages tightly coupled with the first message are stored in each message queue.

[0058] Still taking RabbitMQ message clustering as an example, the nodes in the RabbitMQ cluster include memory nodes and disk nodes. Memory nodes put all data in memory, and disk nodes put data on disk. If the persistence of the message is turned on when delivering the message, then even if it is a memory node, the data is still safely placed on the disk. Then the performance of the memory node can only be reflected in resource management, such as adding or deleting queues, virtual hosts, exchanges, etc. The speed of sending and receiving messages is the same as that of disk nodes. A cluster must have at least one disk node. Users, virtual hosts, exchanges, etc. can be shared in a rabbitMQ cluster. All data and status must be replicated on all nodes. For queues, there should be different performances depending on the cluster mode. In cluster mode, as long as any node can work, the RabbitMQ cluster can provide services to the outside world.

[0059] In the default cluster mode, after the queue is created, if there is no other policy, the queue will be clustered in the normal mode. For the queue, the message entity only exists in one of the nodes. Nodes A and B have only the same metadata, that is, the queue structure, but only one copy of the queue metadata is saved, that is, the rabbitMQ node (node ​​A) that created the queue. When node A goes down, you can go to its node B to check. . / rabbitmqctl list_queues finds that the queue has been lost, but the declared exchange still exists.

[0060] When the message enters the queue of node A and the consumer pulls it from node B, RabbitMQ will temporarily transmit the message between A and B, take out the message entity in A and send it to the consumer through B, so the consumer should connect to each node evenly to get the message from it. One problem with this mode is that when node A fails, node B cannot get the message entity that has not been consumed in node A. If the queue is persistent or the message is persistent, it must wait for node A to recover before it can be consumed, and other nodes cannot create a persistent queue that node A has created before node A recovers; if there is no persistence, the message will be lost. This mode is more suitable for non-persistent queues. Only when the queue is non-persistent can the client reconnect to other nodes in the cluster and recreate the queue. If the queue is persistent, the only way is to recover the failed node.

[0061] In mirror mode, message entities will be actively synchronized between mirror nodes instead of being temporarily pulled when consumers retrieve data. The side effects of this mode are also obvious. In addition to reducing system performance, if there are too many mirror queues and a large number of messages enter, the network bandwidth within the cluster will be greatly consumed by this synchronous communication. Therefore, it is applicable in situations where reliability is required to be high. If a queue wants to be a mirror queue, it is necessary to set the policy first. Then, when the client creates the queue, the RabbitMQ cluster automatically sets it to a normal cluster mode or a mirror queue according to the "queue name". The details are as follows:

[0062] Queues enable mirroring through policies. Policies can be changed at any time, and RabbitMQ queues can also change queues as policies change; there is a difference between non-mirrored queues and mirrored queues. The former lacks additional mirroring infrastructure and has no mirrors (slaves), so it will run faster.

[0063] To make a queue a mirror queue, you will create a policy to match the queue. The policy has two keys: ha-mode and ha-params (optional). ha-params has different values ​​depending on ha-mode. The following table describes the options for these keys.

[0064]

[0065] Next, we will introduce RabbitMQ's message clustering and high availability (Highly Available Queues, queues can be mirrored on machines in the cluster so that queues are still available when some nodes have problems) features.

[0066] Based on the above scheme, specific equipment can be used to implement the above scheme, in which the RabbitMQ server message queue is based on the stress test results of using a 4C8G server in the development environment. A message occupies 10K data and is sent 10,000 times within 1 second. After data monitoring, the CPU usage rate rises to 45%, and the memory uses 4G. Taking this as a reference value, the operating system needs to occupy 4G memory. The memory size required for a single machine is (4+4) / (1-30%)=12G. The required performance is about 2 CPUs, and the tpcc value is about 170000tpmc. Considering the development of the business, an 8C24G server is used for the production system. The server is deployed in both the online banking DMZ-APP network segment and the business network segment. At the same time, it is deployed on 2 virtual machines according to a set of RabbitMQ clusters and deployed in two locations, so 2 virtual machines are required at each location. According to the k1 and k2 deployment isolation scheme, the RabbitMQ service is independently deployed on k1 and k2, so 4 virtual machines are required at each location. The message center server achieves high availability through the RabbitMQ cluster. If a switch occurs to the first location, the message will be persisted to the file system of the server at the second location. After the switch is back, the message will be pulled up and resent. The production RabbitMQ uses the mirror mode, and a cluster contains four machines.

[0067] Taking the use of RabbitMQ message queues during a bank's gold bean payment activity as an example, it mainly involves two parts: consumption records and merchant notifications. The following two queues are specifically introduced below:

[0068] 1. Order details record billRecordQueue

[0069] In order to receive order details for front-end display, the payment microservice needs to inform the consumption record microservice of the specific information after the order is completed. First, the payment microservice assembles a message and sends it to the billRecordQueue message queue, which is bound to the publicExchange switch and the bound topic is topic.billRecord. The payment microservice does not send the message directly to the billRecordQueue, but to the publicExchange switch, and informs the topic is topic.billRecord. The switch then sends the message to the corresponding message queue according to the topic, that is, billRecordQueue. The consumption record microservice monitors the billRecordQueue message queue and receives messages for consumption.

[0070] In order to ensure that messages are not lost and data is not repeated, the consumption record microservice is designed with a dead letter queue and a retry queue. Since the order in which the message queue sends messages is random, in order to prevent data errors caused by unsuccessful consumption due to order problems, some errors can be considered worth retrying. Based on this, a retry queue billRetryQueue is designed and bound to the deathExchange switch, with the topic being topic.billRecord. This message queue sets a delay of 5s, and the number of retries is recorded in the message. When the number of retries reaches 3, the message is thrown into the dead letter queue. The dead letter queue is a queue that stores consumption failure messages, with a validity period of one week. Messages in this queue need to be manually confirmed to contain valid information.

[0071] 2. Merchants asynchronously notify SHNoteRecordQueue

[0072] In order to inform the merchant of the order payment status, after the payment process is completed, the payment microservice sends the merchant notification content to RabbitMQ, and the notification microservice gets the message from RabbitMQ. The message queue involved is SHNoteRecordQueue, which is also bound to the publicExchange switch, and the topic is topic.SHNoteRecord. The notification microservice also involves a dead letter queue. When the message consumption is unsuccessful, the message is thrown into the dead letter queue. The dead letter queue here is the same as the consumption record mentioned above.

[0073] In addition, the bank's payment system also uses RabbitMQ in modules such as credit limit, WeChat notification, and payment collection notification.

[0074] By adopting the non-critical transaction decoupling method in high-concurrency scenarios provided by the embodiment of the present invention, some operations that do not need to take effect immediately are split out for asynchronous execution, which can not only effectively block the spread of blockage, but also fundamentally reduce the occurrence of blockage due to good performance and elastic expansion capabilities. Business logic is no longer acquired by the application when data is needed, but data is transformed into messages and flows at high speed between various components to drive the completion of business, ensure that the customer transaction link is clean and concise, and improve customer experience.

[0075] Figure 4 A schematic diagram of the structure of a non-critical transaction decoupling device in a high-concurrency scenario provided by an embodiment of the present invention, such as Figure 4 As shown, the non-critical transaction decoupling device in a high-concurrency scenario provided by this embodiment includes:

[0076] The receiving module 41 is used to obtain a first transaction message and at least one other transaction message tightly coupled with the first transaction message, wherein the first transaction message has at least one other transaction message tightly coupled with the first transaction message.

[0077] The decoupling module 42 is configured to determine at least one second transaction message among other transaction messages that are tightly coupled with the first transaction message, wherein the priority of the at least one second transaction message is lower than a first preset threshold.

[0078] The sending module 43 is used to send the first transaction message and other transaction messages tightly coupled with the first message except at least one second transaction message to the recipients of each transaction message; and send the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient at a time node after the time node of sending the first transaction message.

[0079] The non-critical transaction decoupling device in high-concurrency scenarios provided by an embodiment of the present invention can execute the non-critical transaction decoupling method in high-concurrency scenarios provided by any embodiment of the present invention, and has functional modules and beneficial effects corresponding to the execution method.

[0080] Further, in Figure 4 On the basis of the illustrated embodiment, the non-critical transaction decoupling device in a high concurrency scenario may further include: a queue module, used to store the first transaction message and other transaction messages tightly coupled with the first message in at least one message queue according to a preset scheduling strategy; a sending module 43, specifically used to send the first transaction message and other transaction messages tightly coupled with the first message among the transaction messages stored in at least one message queue except for at least one second transaction message to the recipients of each transaction message; and send the second transaction message corresponding to the second transaction message sending request stored in at least one message queue to the corresponding transaction message recipient at a time node after the time node of sending the first transaction message.

[0081] Further, in Figure 4 On the basis of the illustrated embodiment, the decoupling module 42 is further used to send a stop sending message to at least one message queue, where the stop sending message is used to instruct the at least one message queue to stop sending at least one second transaction message.

[0082] Further, in Figure 4 On the basis of the illustrated embodiment, at least one message queue is respectively established in different servers in the service cluster; the queue module is specifically used to store the first transaction message and other transaction messages closely coupled with the first message in the message queues of different servers respectively according to a preset scheduling strategy; the sending module 43 is specifically used to, at a time node after the time node of sending the first transaction message, if the second transaction message corresponding to the second transaction message sending request is not stored in the message queue of the first server, the first server reads the second transaction message from the message queue of the server storing the second transaction message corresponding to the second transaction message sending request and sends it to the corresponding transaction message recipient.

[0083] Further, in Figure 4 Based on the illustrated embodiment, at least one message queue is established in each server in the service cluster; the queue module is specifically used to store the first transaction message and other transaction messages closely coupled with the first message in each message queue according to a preset scheduling strategy.

[0084] Further, in Figure 4 On the basis of the illustrated embodiment, the sending module 43 is specifically used to send the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient when a second transaction message sending request is received; or to send the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient at a time node after the time node of sending the first transaction message according to a preset strategy.

[0085] Further, in Figure 4 On the basis of the illustrated embodiment, the decoupling module 43 is specifically configured to determine at least one second transaction message among other transaction messages tightly coupled with the first transaction message when the priority of the first transaction message is higher than a second preset threshold.

[0086] Further, in Figure 4 Based on the illustrated embodiment, the first transaction message includes a payment transaction message or a refund transaction message, and the second transaction message includes a transaction result feedback message or a transaction result record message.

[0087] Figure 5 A schematic diagram of the structure of a computer device provided by an embodiment of the present invention is shown in FIG. Figure 5 As shown, the computer device includes a processor 51, a memory 52, an input device 53 and an output device 54; the number of processors 51 in the computer device can be one or more. Figure 5 A processor 51 is taken as an example; the processor 51, memory 52, input device 53 and output device 54 in the computer device can be connected by a bus or other means. Figure 5 The example of connecting through bus is taken in the following.

[0088] The memory 52, as a computer-readable storage medium, can be used to store software programs, computer executable programs and modules, such as program instructions / modules corresponding to the non-critical transaction decoupling method in high-concurrency scenarios in the embodiments of the present invention (for example, the receiving module 41, the decoupling module 42, and the sending module 43 in the non-critical transaction decoupling device in high-concurrency scenarios). The processor 51 executes various functional applications and data processing of the computer device by running the software programs, instructions and modules stored in the memory 52, that is, realizing the above-mentioned non-critical transaction decoupling method in high-concurrency scenarios.

[0089] The memory 52 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and at least one application required for a function; the data storage area may store data created according to the use of the terminal, etc. In addition, the memory 52 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 52 may further include a memory remotely arranged relative to the processor 51, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0090] The input device 53 may be used to receive input digital or character information and generate key signal input related to user settings and function control of the computer device. The output device 54 may include a display device such as a display screen.

[0091] An embodiment of the present invention further provides a storage medium containing computer executable instructions, which, when executed by a computer processor, is used to execute a method for decoupling non-critical transactions in a high-concurrency scenario, the method comprising:

[0092] Acquire a first transaction message and at least one other transaction message tightly coupled with the first transaction message, wherein the first transaction message has at least one other transaction message tightly coupled with the first transaction message;

[0093] Determine at least one second transaction message among other transaction messages that are closely coupled with the first transaction message, wherein a priority of the at least one second transaction message is lower than a first preset threshold;

[0094] Sending the first transaction message and other transaction messages among other transaction messages tightly coupled with the first message except for at least one second transaction message to receivers of the transaction messages;

[0095] At a time node after the time node of sending the first transaction message, a second transaction message corresponding to the second transaction message sending request is sent to the corresponding transaction message recipient.

[0096] Of course, the computer executable instructions of the storage medium provided in the embodiment of the present invention are not limited to the above-mentioned method operations, but can also perform the related operations in the non-critical transaction decoupling method in the high-concurrency scenario provided in any embodiment of the present invention.

[0097] Through the above description of the implementation methods, the technicians in the relevant field can clearly understand that the present invention can be implemented by means of software and necessary general hardware, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory (FLASH), hard disk or optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0098] It is worth noting that in the above-mentioned embodiment of the non-critical transaction decoupling device in the high-concurrency scenario, the various units and modules included are only divided according to functional logic, but are not limited to the above-mentioned division, as long as the corresponding functions can be achieved; in addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of the present invention.

[0099] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A method for decoupling non-critical transactions in a high-concurrency scenario, characterized in that: include: Acquire a first transaction message and at least one other transaction message tightly coupled with the first transaction message, wherein the first transaction message has at least one other transaction message tightly coupled with the first transaction message; determining at least one second transaction message among other transaction messages that are closely coupled with the first transaction message, wherein a priority of the at least one second transaction message is lower than a first preset threshold; sending the first transaction message and other transaction messages among other transaction messages tightly coupled with the first transaction message except the at least one second transaction message to receivers of the transaction messages; At a time point after the time point of sending the first transaction message, the second transaction message corresponding to the second transaction message sending request is sent to the corresponding transaction message recipient.

2. The method according to claim 1, characterized in that: After obtaining the first transaction message, the method further includes: According to a preset scheduling strategy, the first transaction message and other transaction messages tightly coupled with the first transaction message are stored in at least one message queue; The sending the first transaction message and other transaction messages except the at least one second transaction message among other transaction messages tightly coupled with the first transaction message to receivers of the transaction messages includes: sending the first transaction message and other transaction messages tightly coupled with the first transaction message, except the at least one second transaction message, among the transaction messages stored in the at least one message queue to receivers of the transaction messages; The sending the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient at a time node after the time node of sending the first transaction message includes: At a time node after the time node of sending the first transaction message, the second transaction message corresponding to the second transaction message sending request stored in the at least one message queue is sent to the corresponding transaction message recipient.

3. The method according to claim 2, characterized in that After sending the first transaction message and other transaction messages tightly coupled with the first transaction message except the at least one second transaction message among the transaction messages stored in the at least one message queue to receivers of the transaction messages, the method further includes: A stop sending message is sent to the at least one message queue, where the stop sending message is used to instruct the at least one message queue to stop sending the at least one second transaction message.

4. The method according to claim 2, characterized in that: The at least one message queue is respectively established in different servers in the service cluster; The storing, according to a preset scheduling strategy, the first transaction message and other transaction messages tightly coupled with the first transaction message into at least one message queue comprises: According to a preset scheduling strategy, the first transaction message and other transaction messages closely coupled with the first transaction message are stored in message queues of different servers respectively; The sending, at a time node after the time node of sending the first transaction message, the second transaction message corresponding to the second transaction message sending request stored in the at least one message queue to the corresponding transaction message recipient comprises: At a time node after the time node of sending the first transaction message, if the second transaction message corresponding to the second transaction message sending request is not stored in the message queue of the first server, the first server reads the second transaction message from the message queue of the server storing the second transaction message corresponding to the second transaction message sending request and sends it to the corresponding transaction message recipient.

5. The method according to claim 2, characterized in that: The at least one message queue is established in each server in the service cluster; The storing, according to a preset scheduling strategy, the first transaction message and other transaction messages tightly coupled with the first transaction message into at least one message queue comprises: According to a preset scheduling strategy, the first transaction message and other transaction messages tightly coupled with the first transaction message are stored in each message queue.

6. The method according to any one of claims 1 to 5, characterized in that: The sending the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient at a time node after the time node of sending the first transaction message includes: When receiving the second transaction message sending request, sending the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient; Or according to a preset strategy, the second transaction message corresponding to the second transaction message sending request is sent to the corresponding transaction message recipient at a time node after the time node of sending the first transaction message.

7. The method according to any one of claims 1 to 5, characterized in that: The determining at least one second transaction message among other transaction messages that are tightly coupled with the first transaction message comprises: When the priority of the first transaction message is higher than a second preset threshold, at least one second transaction message among other transaction messages tightly coupled with the first transaction message is determined.

8. The method according to any one of claims 1 to 5, characterized in that: The first transaction message includes a payment transaction message or a refund transaction message, and the second transaction message includes a transaction result feedback message or a transaction result record message.

9. A non-critical transaction decoupling device in a high-concurrency scenario, characterized in that: include: A receiving module, configured to obtain a first transaction message and at least one other transaction message tightly coupled with the first transaction message, wherein the first transaction message has at least one other transaction message tightly coupled with the first transaction message; a decoupling module, configured to determine at least one second transaction message among other transaction messages tightly coupled with the first transaction message, wherein the priority of the at least one second transaction message is lower than a first preset threshold; A sending module is used to send the first transaction message and other transaction messages tightly coupled with the first transaction message except the at least one second transaction message to the recipients of each transaction message; and send the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient at a time node after the time node of sending the first transaction message.

10. The device according to claim 9, characterized in that Also includes: A queue module, configured to store the first transaction message and other transaction messages tightly coupled with the first transaction message into at least one message queue according to a preset scheduling strategy; The sending module is specifically used to send the first transaction message and other transaction messages tightly coupled with the first transaction message, except the at least one second transaction message, among the transaction messages stored in the at least one message queue, to recipients of each transaction message; and send the second transaction message corresponding to the second transaction message sending request stored in the at least one message queue to the corresponding transaction message recipient at a time node after the time node of sending the first transaction message.

11. The device according to claim 10, characterized in that The decoupling module is further used to send a stop sending message to the at least one message queue, where the stop sending message is used to instruct the at least one message queue to stop sending the at least one second transaction message.

12. The device according to claim 10, characterized in that The at least one message queue is respectively established in different servers in the service cluster; The queue module is specifically configured to store the first transaction message and other transaction messages tightly coupled with the first transaction message in message queues of different servers respectively according to a preset scheduling strategy; The sending module is specifically configured to, at a time node after the time node of sending the first transaction message, if the second transaction message corresponding to the second transaction message sending request is not stored in the message queue of the first server, then the first server reads the second transaction message from the message queue of the server storing the second transaction message corresponding to the second transaction message sending request and sends the second transaction message to the corresponding transaction message recipient.

13. The device according to claim 10, characterized in that The at least one message queue is established in each server in the service cluster; The queue module is specifically configured to store the first transaction message and other transaction messages tightly coupled with the first transaction message in each message queue according to a preset scheduling strategy.

14. The device according to any one of claims 9 to 13, characterized in that: The sending module is specifically used to send the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient when receiving the second transaction message sending request; or to send the second transaction message corresponding to the second transaction message sending request to the corresponding transaction message recipient at a time node after the time node of sending the first transaction message according to a preset strategy.

15. The device according to any one of claims 9 to 13, characterized in that: The decoupling module is specifically configured to determine at least one second transaction message among other transaction messages tightly coupled with the first transaction message when the priority of the first transaction message is higher than a second preset threshold.

16. The device according to any one of claims 9 to 13, characterized in that: The first transaction message includes a payment transaction message or a refund transaction message, and the second transaction message includes a transaction result feedback message or a transaction result record message.

17. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the non-critical transaction decoupling method in a high-concurrency scenario as described in any one of claims 1 to 8 is implemented.

18. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the non-critical transaction decoupling method in a high-concurrency scenario as described in any one of claims 1 to 8 is implemented.

Images