Implementation Method of Database Integrated with Message Queue and Integrated Transaction

Abstract

The present application relates to the field of database technology, and specifically to a method for implementing a database and a fusion transaction that integrates a message queue. A message processing center and a compatibility mechanism between the center and the existing mechanism of the database kernel are developed in the database kernel, so that the database adds a message queue mechanism on the basis of the original mechanism. On the one hand, for application developers, they only need to connect the application (message generator) to the database, which reduces the development difficulty and is more friendly; on the other hand, the original transaction mechanism of the database can be used to encapsulate the use of the message queue to send messages in the local database transaction, so that there is no need to develop or rely on distributed transaction middleware, and whether the message sending is successful can be monitored to achieve transaction atomicity. The development difficulty is low, the system is simple, and it will also avoid the defects such as easy blocking caused by relying too much on single-point distributed transaction middleware, and the occurrence of single-point risks leading to transaction synchronization failure.

Description

Technical Field

[0001] This application relates to the field of database technology, and specifically to a method for implementing a database integrating a message queue and a fusion transaction. Background Art

[0002] A message queue is a technology used to transfer messages between applications. It is a communication method that decouples the message producer and the message consumer, allowing the sender to send messages to the queue without immediately delivering the messages to the receiver. Message queues are commonly used to implement asynchronous communication, where the message producer and the message consumer can process messages at different times and speeds.

[0003] Common message queue systems include RabbitMQ, Apache Kafka, Amazon SQS, etc. They provide different features and applicable scenarios, and the appropriate message queue system can be selected according to specific requirements.

[0004] A database is a software system used to store and organize data. They are designed to effectively manage large amounts of data, allowing users to quickly retrieve, update, and manage data.

[0005] The database provides persistent storage of data, ensuring that the data is still available after the system is shut down or restarted. They also support transaction processing, allowing users to execute a series of operations and commit or roll them back as an atomic operation when necessary.

[0006] Common database types include relational databases (such as MySQL, PostgreSQL, Oracle) and non-relational databases (such as MongoDB, Redis, Elasticsearch), which provide different solutions for different data storage and access requirements.

[0007] Currently, in applications that require asynchronous processing and event-driven, it is necessary to integrate a database and a message queue. Please refer to Figure 1 , Figure 1 for a schematic structural diagram of the integration of a database and a message queue in the related technology. As Figure 1 shown, 100 is an application, 101 is a database, and 102 is a message queue. The common practice is that the application 100 persists the information to be sent in a library table (which can be a cache table) in the database 101, and then extracts the messages to be sent from the library table to the message queue through a trigger or a scheduled task to complete message consumption.

[0008] This integration utilizes the storage characteristics of the database to facilitate the persistence of the messages to be sent, preventing message loss caused by the exception of the entire system. However, as Figure 1The application shown needs to interface with database 101 and message queue 102. On the one hand, for R & D engineers developing the application, they need to develop complex programs to ensure data communication between database 101 and message queue 102, which involves a large amount of development work and is very unfriendly. On the other hand, in a fusion transaction (a fusion transaction includes scenarios where cross-database system cooperation is required to complete operations, such as table operations in the local database and notification operations to notify the peer database to perform relevant operations), if only the transaction mechanism of the database itself is used, only the atomicity of database operations and the messages to be sent can be ensured to be persisted in the database tables, and the success or failure of sending messages by message queue 102 cannot be included in the transaction. That is, if the message sending fails finally, transaction rollback cannot be achieved. In some solutions, as shown in Figure 2 a distributed middleware 203 (complex transaction mechanism) is used to implement a complete fusion transaction, which is difficult to develop, too dependent on a single-point distributed middleware, prone to data blocking, bringing single-point risks, resulting in inconsistent commit / rollback messages received by participants, and data inconsistency problems, and the transaction processing fails. Summary of the Invention

[0009] In view of this, the present application discloses a database integrating a message queue. The database includes a message processing center; the message processing center is communicatively connected to a message producer and a message consumer through the communication mechanism of the database; the database also includes message queues allocated for the message producer and the message consumer. The message producer is used to generate messages and send them to the message processing center; the message processing center is used to, in response to receiving the messages, write the messages into the redo log based on the redo log mechanism supported by the database kernel, and write the messages into the message queue; the message consumer is used to obtain the messages from the message queue through the communication connection and complete consumption.

[0010] In some embodiments, in response to an abnormal restart, the message processing center reads unprocessed target messages from the redo log and writes the target messages into the message queue, so that the message consumer can complete the consumption of the target messages.

[0011] In some embodiments, the message producer corresponds to a sender cache, and the message consumer corresponds to a receiver cache; after generating a message, the message producer sends the generated message to the sender cache; the sender cache sets a message sequence number for the message and the queue ID of the message queue to associate the message with the message queue, and sends the message to the message processing center, and records the message sequence number as the sent message sequence number in the sender cache; the message processing center writes the message into the redo log, returns a send confirmation success to the message producer, and records the message sequence number as the send confirmation message sequence number in the message processing center; and writes the message into the message queue corresponding to the queue ID, and pushes the message to the receiver cache through the communication connection, and records the message sequence number as the message received sequence number in the message processing center; the receiver cache pushes the message to the message consumer, and in response to the successful push, returns a receive confirmation success to the message processing center, and records the message sequence number as the message received sequence number in the receiver cache; the message consumer receives the message and completes consumption; the message processing center releases the local message upon receiving the receive confirmation success feedback from the receiver cache, and records the receive confirmation message sequence number in the message processing center.

[0012] In some embodiments, in response to an abnormal restart, the message processing center reads the target message that has not been processed from the redo log, writes the target message into the message queue, pushes the target message to the receiver cache through the communication connection, and records the message sequence number of the target message as the message received sequence number in the message processing center; the receiver cache, in response to receiving the target message, in the case where the message sequence number of the target message is greater than the locally recorded message received sequence number, pushes the target message to the message consumer, and in response to the successful push, returns a receive confirmation success to the message processing center, and records the message sequence number of the target message as the message received sequence number in the receiver cache.

[0013] In some embodiments, when the unprocessed situation means that the send confirmation success has not been returned to the message producer, before writing the target message into the message queue, a send confirmation success for the target message is returned to the message producer, and the message sequence number of the target message is recorded as the send confirmation message sequence number in the message processing center.

[0014] In the database shown in any of the previous embodiments of the present application, a message processing center and a compatibility mechanism between the center and the existing mechanisms of the database kernel are developed in the database kernel, so that the message queue mechanism is added to the database on the basis of the original mechanism. On the one hand, for application developers, they only need to connect the application (message producer) to the database, which reduces the development difficulty and is relatively user-friendly. On the other hand, the original transaction mechanism of the database can be used to encapsulate the message sending using the message queue in the local database transaction. Thus, without the need for development or dependence on a distributed transaction middleware, it is possible to monitor whether the message sending is successful and achieve transaction atomicity. The development difficulty is low, the system is simple, and it also avoids defects such as easy blocking, single-point risk leading to transaction synchronization failure, etc. caused by excessive dependence on a single-point distributed transaction middleware.

[0015] The present application also includes a method for implementing a fusion transaction. The method is implemented based on the database shown in any of the previous embodiments. The fusion transaction includes a first operation on a first database and a notification operation for notifying a second database to perform a second operation; the first database refers to the database shown in any of the previous embodiments; the method includes: receiving a processing request for the fusion transaction sent to the first database; in response to the fusion transaction, the first database encapsulates the execution of the first operation and the notification operation into the same transaction, and executes the transaction to ensure the execution of the first operation and the atomicity of the notification operation using the message queue mechanism integrated with the first database based on its own kernel's transaction mechanism.

[0016] In some embodiments, the executing the transaction to ensure the execution of the first operation and the atomicity of the notification operation using the message queue mechanism integrated with the first database includes: pre-executing the first operation and pre-executing the notification operation using the message queue mechanism integrated with the first database; in response to the successful pre-execution of the first operation and the successful pre-execution of the notification operation, issuing a commit instruction to complete the execution of the first operation and the notification operation; in response to the failure of the pre-execution of the first operation or the failure of the pre-execution of the notification operation, issuing a rollback instruction to withdraw the first operation and the notification operation.

[0017] In some embodiments, the pre-execution of the notification operation by using the message queue mechanism fused with the first database includes: in response to receiving a notification message for notifying the second database to perform a second operation, using the message processing center to write the notification message into the redo log and into a message queue associated with the notification message, so as to transmit the notification message to the consumer application corresponding to the second database; in response to receiving a message reception confirmation returned by the consumer application, determining that the pre-execution of the notification operation is successful; in response to not receiving a message reception confirmation, determining that the pre-execution of the notification operation fails.

[0018] In some embodiments, the consumer application corresponds to a receiver cache; the transmitting of the notification message to the consumer application corresponding to the second database includes: transmitting the notification message to the receiver cache corresponding to the consumer application, so that in the case where the receiver cache corresponding to the consumer application successfully receives the notification message, it returns a message reception confirmation to the message processing center; after a publish commit instruction is issued, the method further includes: in response to receiving a commit instruction regarding the notification message, using the message processing center to write the commit instruction into a message queue associated with the commit instruction, so as to transmit the commit instruction to the receiver cache corresponding to the consumer application, so that the receiver cache corresponding to the consumer application pushes the notification message to the consumer application to complete the second operation; after a publish rollback instruction is issued, the method further includes: in response to receiving a rollback instruction regarding the notification message, using the message processing center to write the rollback instruction into a message queue associated with the rollback instruction, so as to transmit the rollback instruction to the receiver cache corresponding to the consumer application, so that the receiver cache corresponding to the consumer application releases the notification message.

[0019] In some embodiments, the method further includes: in response to pushing the notification message to the consumer application, returning a commit success to the message processing center; in response to the receiver cache corresponding to the consumer application releasing the notification message, returning a completion of rollback to the message processing center; using the message processing center to return the received commit success or completion of rollback to the producer of the notification message to confirm the completion of the fusion transaction.

[0020] In the solution described in any of the foregoing embodiments, the original transaction mechanism of the database can be utilized to encapsulate the operations on the database and the notification operations for notifying other databases in the same transaction, so that without the need for development and without relying on a distributed transaction middleware, it is possible to monitor whether the database operations and the notification operations successfully achieve transaction atomicity. This has a low development difficulty, is friendly to application developers, the system is also simple, and it can also avoid defects such as being prone to blocking due to excessive reliance on a single-point distributed transaction middleware and the failure of transaction synchronization caused by single-point risks.

[0021] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit this application. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] To more clearly illustrate the technical solutions in one or more embodiments of this application or related technologies, the following will briefly introduce the drawings required for use in the description of the embodiments or related technologies. Obviously, the drawings in the following description are only some embodiments described in one or more embodiments of this application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0023] The following will briefly introduce the drawings required for use in the description of the embodiments or related technologies.

[0024] Figure 1 It is a schematic structural diagram of the integration of a database and a message queue in related technologies.

[0025] Figure 2 It is an architecture diagram of the implementation mechanism of a fusion transaction in related technologies.

[0026] Figure 3 It is a structural diagram of a database integrating a message queue shown in this application.

[0027] Figure 4 It is a schematic diagram of a message asynchronous transmission scenario shown in this application.

[0028] Figure 5 It is a schematic diagram of a message asynchronous processing flow shown in this application.

[0029] Figure 6 It is a schematic flow diagram of a method for implementing a fusion transaction shown in this application.

[0030] Figure 7 It is a schematic flow diagram of a method for a database to execute a fusion transaction shown in this application.

[0031] Figure 8 It is a schematic flow diagram of a notification operation completed based on a message processing center shown in this application.

[0032] Figure 9 A schematic flowchart of a notification operation completed based on a message processing center shown in this application.

[0033] Figure 10 A schematic structural diagram of an implementation device for a fusion transaction shown in an embodiment of this application.

[0034] Figure 11 A schematic hardware structure diagram of an electronic device shown in an embodiment of this application. Detailed implementation manners

[0035] Exemplary embodiments will be described in detail below, and examples thereof are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with this application. On the contrary, they are merely examples of devices and methods consistent with some aspects of this application as detailed in the appended claims.

[0036] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms "a", "the", and "said" used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more of the associated listed items. It should also be understood that the word "if" used herein can be interpreted as "when" or "while" or "in response to determining" depending on the context.

[0037] In the related art, as Figure 1 shown, the application 100 is docked with the database 101 and the message queue 102. Assume that the cross-database operation is to subtract 20 from account A and add 20 to account B, and account A and account B are distributed in two databases. Account A is in the database 101. The application 100 needs to generate an operation to subtract 20 from account A and a notification message to notify to add 20 to account B. The application 100 can send the operation and the notification message to the database 101, and the database 101 can encapsulate the execution of A - 20 and storing the notification message into a library table (which can be a cache table) as a transaction, that is, A - 20 and the completion of storing the notification message can ensure atomicity. Subsequently, the application can extract the notification message from the library table and then send it to the message queue, and the database corresponding to account B as the consumer can extract the notification message from the message queue. The pseudo code is as follows:

[0038] Start transaction

[0039] Account A: A - 20;

[0040] Add the message to the cache table;

[0041] If successful

[0042] Commit;

[0043] Else

[0044] Rollback;

[0045] While there is a message in the message cache table

[0046] Read the message from the cache table;

[0047] Send the message to the message queue;

[0048] If successfully received

[0049] Delete this message from the cache table;

[0050] Else

[0051] End this processing and wait to be resent.

[0052] This approach has the following drawbacks: It is necessary to implement a data storage mechanism in the database that coordinates with the message queue, which is highly difficult and complex. And if the message queue fails to send a message, since the data storage and the operations on account A-20 have been successfully completed in database 101, it will cause account A-20 to be unable to roll back and account B not to execute the operation of adding 20, resulting in errors.

[0053] In some related technologies, the following approach is adopted Figure 2 to ensure the atomicity of database operations and message notifications. Please refer to Figure 2 , Figure 2 as an architecture diagram of an implementation mechanism for a fusion transaction in related technologies. As Figure 2 shown, a distributed transaction middleware 203 is added between the application 200, the database 201, and the message queue 202. This middleware can be developed by application developers themselves, or be commercial or open source. This distributed transaction middleware 203 can encapsulate the operations on account A and the operation of notifying Bank 2 using the message queue into a transaction. Combining the previous example, the pseudocode is as follows:

[0054] Start transaction

[0055] Account A: A–20;

[0056] Notify account B: B+100;

[0057] If successful

[0058] Commit;

[0059] Else

[0060] Rollback.

[0061] Such reliance on the distributed transaction middleware can monitor the message sending situation of the message queue and achieve transaction atomicity. However, this solution has the following defects:

[0062] First, the system complexity increases and the development difficulty is great.

[0063] Second, when participants such as the database and the message queue are waiting for instructions from the transaction middleware, synchronous blocking will occur. For example, if a network communication failure occurs and the participants cannot receive instructions in time, they will be blocked all the time.

[0064] Third, introducing the distributed transaction middleware as a coordinator will become a single point of risk. Its failure will cause the entire system to be unavailable. Even if the coordinator adopts a primary and standby solution, there are still problems with transaction information synchronization during the primary and standby switchover.

[0065] Fourth, due to reasons such as the single point of failure of the coordinator or network failure, the commit / rollback messages received by the participants are inconsistent, resulting in data inconsistency problems among the participants and the failure of transaction processing.

[0066] In view of this, the present application proposes a database integrating a message queue. The core is to develop a message processing center in the database kernel and a compatibility mechanism between the center and the existing mechanisms of the database kernel, so that the database adds a message queue mechanism on the basis of the original mechanism. On the one hand, for application developers, they only need to interface with the database, which reduces the development difficulty and is relatively friendly. On the other hand, the original transaction mechanism of the database can be used to encapsulate the message sending using the message queue in the local database transaction. Thus, without developing or relying on the distributed transaction middleware, it is possible to monitor whether the message sending is successful and achieve transaction atomicity. The development difficulty is low, the system is also simple, and it will also avoid defects such as being prone to blocking, single point of risk, and transaction synchronization failure caused by over-reliance on the single point of distributed transaction middleware.

[0067] The following describes the database with reference to the accompanying drawings.

[0068] Please refer to Figure 3 , Figure 3 , which is a structural diagram of a database integrating a message queue shown in the present application. As Figure 3 shown, the database 320 includes a network connection layer 321, a database core service layer 322, a transaction processing layer 323, a database storage layer 324, and a database management and control tool 325.

[0069] The core difference between this database and the conventional databases in the related technologies lies in that a message processing center 3221 is added to the database core service layer 322, and a message queue object 3241 is added to the database storage layer 324.

[0070] Message processing center 3221: Interacts with message producers and consumers through the network connection layer to implement the core process of message interaction processing.

[0071] Message queue object 3241: Saves the core data structure information of the message queue object, saves all message information, and provides persistent storage of messages.

[0072] Through the mutual cooperation of the message processing center 3221 and the message queue object 3241, a message queue mechanism is implemented in the database 320. The original transaction processing layer 323 of the database can also be used to monitor the message sending situation in the message queue mechanism to achieve the transaction atomicity of database operations and message sending.

[0073] The message processing center 3221 communicates with message producers and message consumers through the communication mechanism of the database.

[0074] For message producers and consumers to communicate with the message processing center 3221, they need to establish a communication connection with the processing center in advance. Since the message processing center is implemented based on the database kernel, the original database network connection layer 321 connection process can be reused:

[0075] The database service selects a protocol port (for example, the default port of MySQL is 3306, and the default port of PostgreSQL is 5432) and starts the service;

[0076] The application creates a socket and specifies the IP address and port of the database service;

[0077] Uses the connect method of the socket to connect to the database;

[0078] After the connection is successful, the database may start authenticating the application;

[0079] After the connection and verification are passed, the send, recv, etc. methods of the socket can be used to send and receive data;

[0080] When communication is no longer needed, close the connection through the close method of the socket.

[0081] The database 320 also includes a message queue allocated for the message producers and message consumers. This message queue is only for illustrative purposes and does not mean that there is only one message queue in the database. There can be one or more message queues between message producers and message consumers.

[0082] The message producer is used to generate messages and send them to the message processing center.

[0083] The message format of the message may include a queue ID, a message sequence number, a message length, and a message content.

[0084] Queue ID: Used to uniquely identify a message queue. Multiple message queues can be established between the same producer and consumer, and different queue IDs are assigned to multiple queues;

[0085] Message sequence number: Can be incremented, used to determine whether a message is repeated or lost in different links, mainly for processing after various failures are recovered. Of course, the message sequence number can also be generated in a decreasing manner. This application takes increment as an example. For example, add 1 each time.

[0086] Message length: The length of the message information.

[0087] Message content: The entity of the message, written by the message producer, read and processed by the message consumer.

[0088] The message processing center is used to, in response to receiving the message, write the message into the redo log based on the redo log mechanism supported by the database kernel, and write the message into the message queue.

[0089] Redo log is called the redo log, which provides a re-write operation to restore the page operation modified by the committed transaction, and is used to ensure the durability of the transaction. This application can utilize the original redo log mechanism of the database to implement the re-write operation of sending messages to ensure their durability.

[0090] The message queue can support the first-in, first-out method, which is specifically set according to business requirements.

[0091] In some embodiments, the basic data structure of the message queue object includes a message queue ID, a message producer ID, a message consumer ID, a message send sequence number, a message send confirmation sequence number, a message receive sequence number, a message receive confirmation sequence number, a maximum number of messages, a maximum message length, and a message linked list.

[0092] The message queue ID is used to uniquely identify a message queue. Multiple message queues can be established between the same producer and consumer, and different queue IDs are assigned to multiple queues.

[0093] The message producer ID is used to identify the message producer.

[0094] The message consumer ID is used to identify the message consumer.

[0095] The message sending sequence number is the sequence number recorded when the message sending end writes a message into the queue.

[0096] The message sending confirmation sequence number is the sequence number recorded when the message processing center completes the relevant processing of the sent message and replies with a sending confirmation to the sending end.

[0097] The message receiving sequence number is the sequence number recorded by the message processing center after completing the push of the message to the receiving end.

[0098] The message receiving confirmation sequence number is the confirmation sequence number recorded by the message processing center when the receiving end replies with a receiving confirmation to the message processing center after receiving the message.

[0099] The maximum number of messages is the maximum number of messages supported by the message queue;

[0100] The maximum message length is the maximum length of a single message supported by the message queue;

[0101] The message linked list is used to store the messages written into the message queue.

[0102] When the producer generates a message, the producer can write the queue ID corresponding to the message into the message. In this application, the message processing center can determine the corresponding message queue through the queue ID carried in the message and write it in.

[0103] The message consumer is used to obtain the message from the message queue through the communication connection and complete the consumption.

[0104] In this application, the process from the message queue to the consumer can be completed by means of active push or passive acquisition. Active push means that the database actively pushes the messages in the message queue to the corresponding consumers by setting trigger tasks or scheduled tasks, etc. Real-time passive acquisition means that the message consumer can periodically query whether there are messages of interest in the message queue, and if so, complete the acquisition. This application does not particularly limit the message transmission method.

[0105] For example, when the message producer generates message A, it can access the message processing center 3221 in the database through the network connection layer 321 to complete the sending of message A. The message processing center 3221 can write message A into the redo log and the corresponding message queue object 3241, and push message A to the message consumer by means of active push to complete the asynchronous transmission of message A.

[0106] In the database shown in any of the previous embodiments of the present application, a message processing center and a compatibility mechanism between the center and the existing mechanisms of the database kernel are developed in the database kernel, so that the message queue mechanism is added to the database on the basis of the original mechanism. On the one hand, for application developers, they only need to connect the application (message producer) to the database, which reduces the development difficulty and is relatively friendly. On the other hand, the original transaction mechanism of the database can be used to encapsulate the message sent using the message queue in the local database transaction, so that the atomicity of the transaction can be monitored without the need to develop or rely on a distributed transaction middleware. The development difficulty is low, the system is simple, and it can also avoid defects such as easy blocking, single-point risk, and transaction synchronization failure caused by over-reliance on a single-point distributed transaction middleware.

[0107] In some embodiments, in response to an abnormal restart, the message processing center reads the target messages that have not been processed from the redo log and writes the target messages into the message queue, so that the message consumer can complete the consumption of the target messages.

[0108] The target message refers to the message that needs to be processed in the redo log. In some ways, after the message is successfully sent to the consumer, the message will be deleted from the redo log. Therefore, after the system is abnormally restarted, the messages remaining in the redo log can basically be understood as target messages that have not been processed. In some ways, tags indicating whether the message has been processed can be added to the messages in the redo log, and the target messages can also be selected through these tags.

[0109] After the database is abnormally restarted, some messages may be sent failed. Therefore, after the restart, the target messages in the redolog can be read out and rewritten into the corresponding message queue according to the queue ID carried by the messages, so that the consumer can obtain the target messages.

[0110] Thus, the original redo log mechanism of the database can be utilized to realize the resending of messages after the message queue mechanism fails, improving the success rate of message sending.

[0111] The following describes the process of the message asynchronous transmission mechanism (message queue mechanism) based on the message processing center with reference to the accompanying drawings. Please refer to Figure 4 , Figure 4 which is a schematic diagram of the message asynchronous transmission scenario shown in the present application. Figure 4 Other basic units of the database are omitted in, and only the message processing center is retained. The message producer corresponds to the sending-end cache, and the message consumer corresponds to the receiving-end cache. The message producer and the sending-end cache form the message generation end, and the message consumer and the receiving-end cache form the message receiving end.

[0112] Message producer: responsible for generating and sending messages to the message processing center;

[0113] Sender cache: Deployed together with the producer, the producer's messages are first cached here and then sent to the message processing center after preprocessing;

[0114] Message processing center: Responsible for message storage, forwarding, confirmation, retry, etc.;

[0115] Receiver cache: Deployed together with the consumer, the message processing center pushes messages to the consumer. First, the messages are cached here, and then the message cache pushes the messages to the message consumer.

[0116] Message consumer: Responsible for receiving messages and performing corresponding processing.

[0117] Please refer to Figure 5 , Figure 5 which is the schematic diagram of the asynchronous message processing flow shown in this application. As Figure 5 shown, this process includes S501 - S506.

[0118] S501, after the message producer generates a message, it sends the generated message to the sender cache.

[0119] The message at this time includes the content consumed by the consumer. For example, in the previous example of the cross - database operation scenario, the message includes notifying account B + 20.

[0120] S502, the sender cache sets a message sequence number and the queue ID of the message queue for the message to associate the message with the message queue, and sends the message to the message processing center, and records the message sequence number as the sent message sequence number in the sender cache.

[0121] The sender cache has a pre - set piece of business code that can encapsulate the message into the message format shown above. The message producer and consumer have obtained at least one message queue in the database message queue object in advance. This step can add the queue ID of the message queue based on the message content to associate the message with the message queue.

[0122] The sent message sequence number has at least two functions. Function one, adding 1 to the currently recorded sent message sequence number in the cache gives the sequence number of the message to be sent currently. Function two, it can be compared with the message sequence number returned by the message processing center after completing the redo log to determine whether the message is successfully sent.

[0123] For example, if the current message sequence number for sending is 10, then after receiving a new message, the sequence number of the new message is 11. Then the message is sent to the message processing center, and the message sequence number for sending is updated to 11. After the message processing center completes the redo log and returns a successful send confirmation along with the successful message sequence number 11, it can be compared with the updated message sequence number for sending. If the two are the same, it indicates that the message with sequence number 11 has been successfully sent. If the send confirmation for message sequence number 11 has not been received, it can be determined that the message sending has failed, which is convenient for the database transaction mechanism to track the message sending result and ensure atomicity.

[0124] S503. The message processing center writes the message into the redo log, replies to the message producer with a successful send confirmation, and records the message sequence number as the send confirmation message sequence number in the message processing center.

[0125] In this step, the sending sequence number of this message can be recorded, and the existing redo log mechanism of the database can be used to complete message persistence. A probe is set inside the database. After detecting the success of the redo log, a successful send confirmation for the current message can be generated and returned to the message producer and / or the sender cache, and the send confirmation message sequence number is updated. For example, after receiving a message with sequence number 11 and completing the redo log, a successful send confirmation message for message 11 can be generated and returned to the message producer and / or the sender cache, and the send confirmation message sequence number is updated to 11.

[0126] The role of the send confirmation message sequence number is to deduplicate received messages. If, after receiving a message from the sender cache, it is found that the sequence number of the message is less than or equal to the current send confirmation message sequence number, it indicates that the message has been received repeatedly.

[0127] S504. The message processing center writes the message into the message queue corresponding to the queue ID, pushes the message to the receiver cache through the communication connection, and records the message sequence number as the message reception sequence number in the message processing center.

[0128] The message processing center uses a predefined message parsing protocol to parse the queue ID of the message to identify the corresponding message queue object. Then the message can be written into the message queue. After that, the message in the message queue can be pushed to the consumer in a first-in, first-out manner by triggering a task or a scheduled task.

[0129] The role of the message reception sequence number is to record the sequence number of the last sent message, which can be compared with the sequence number of the successful receive confirmation returned by the receiver cache after the message is pushed to the consumer to determine whether the message has been truly sent successfully, which is convenient for the database to track the pre-execution status of the transaction.

[0130] For example, after the message with serial number 11 is sent from the message queue to the receiver buffer, the message reception serial number can be updated to 11. After the receiver buffer successfully receives the message and pushes it to the message consumer, if the reception confirmation for message 11 is successfully returned, it indicates that message 11 has indeed been received. If the reception confirmation of success has not been received all the time, it means that the reception of message 11 fails and the pre-execution of the transaction fails, which is convenient for the database transaction mechanism to monitor.

[0131] S505. The receiver buffer pushes the message to the message consumer. In response to successful pushing, it replies to the message processing center with a successful reception confirmation and records the message serial number as the message reception serial number in the receiver buffer.

[0132] The message consumer receives the message and completes consumption.

[0133] The function of the message reception serial number in the receiver buffer is for message deduplication. If the receiver buffer receives a message, it can compare the serial number of the message with the cached message reception serial number. If it is less than or equal to the current message reception serial number, it means the message is repeated.

[0134] For example, if the currently recorded message reception serial number is 11 and the serial number of the newly received message is 11, it means the message is received repeatedly and can be discarded.

[0135] S506. When the message processing center receives the successful reception confirmation feedback from the receiver buffer, it releases the local message and records the reception confirmation message serial number in the message processing center.

[0136] The reception confirmation message serial number has two functions. Firstly, it can record the serial numbers of the messages that have been successfully consumed by the consumers, which is convenient for the database transaction mechanism to monitor. Secondly, it can be used for message sending deduplication after the system restarts abnormally. For example, if the currently recorded reception confirmation message serial number is 11, it means message 11 has been successfully consumed. Assuming that after the system restarts abnormally and the target message is read from the redo log, if the serial number of the target message is 11, it means the message has been successfully consumed and no subsequent processing is required.

[0137] Through processes S501 - S506, based on the message processing center, the database can be enabled to increase the ability of asynchronous message transmission (message queue), and by recording the message serial numbers, the transaction mechanism can conveniently monitor the results of message sending.

[0138] In some embodiments, after the database restarts abnormally, resending can be completed based on the messages saved in the redo log, improving the success rate of asynchronous message sending.

[0139] In response to an abnormal restart, the message processing center reads the target messages that have not been processed from the redo log, writes the target messages into the message queue, pushes the target messages to the receiver cache through the communication connection, and records the message sequence number of the target messages as the message reception sequence number in the message processing center.

[0140] The target messages have been introduced in the previous example. In this example, all the messages saved in the redo log are target messages, and they need to be read one by one and written into the message queue and pushed to the receiver cache after an abnormal restart.

[0141] The unprocessed target messages include two situations. One is that the message sending to the message queue or the receiver cache fails, and the other is that the message producer has not been replied with a successful sending confirmation and the message sending also fails. It can be determined by comparing the sequence number of the read target message with the sequence number of the sending confirmation message recorded in the message processing center. If the two are the same, it means that the target message only fails to be sent to the message queue or the receiver cache. If the sequence number of the sending confirmation message is less than the sequence number of the target message, it means that the message producer has not been replied with a successful sending confirmation either.

[0142] Regardless of which unprocessed situation, the message processing center needs to write the target messages into the message queue and push them to the receiver cache.

[0143] In response to receiving the target message, when the message sequence number of the target message is greater than the locally recorded message reception sequence number, the receiver cache pushes the target message to the message consumer, replies to the message processing center with a successful reception confirmation in response to the successful push, and records the message sequence number of the target message as the message reception sequence number in the receiver cache.

[0144] In this step, the receiver cache needs to perform duplicate checking after receiving the target message. Specifically, the message sequence number of the target message can be compared with the currently recorded message reception sequence number locally. If the message sequence number of the target message is less than or equal to the currently recorded message reception sequence number, it means that the message is a duplicate message and can be directly released, and a successful target message reception confirmation is returned to the message processing center.

[0145] If the message sequence number of the target message is greater than the currently recorded message reception sequence number (for example, the currently recorded message reception sequence number + 1), it means that the message is a new message, and it can be successfully received and pushed to the consumer, and the currently recorded message reception sequence number is updated.

[0146] For example, if the sequence number of the target message is 10 and the message reception sequence number recorded in the receiver buffer is 11, it indicates that the message has been processed. To avoid duplication, the message can be released, and it can be returned that message 10 has been successfully received. The message processing center will update the received confirmation message sequence number and release message 10.

[0147] For another example, if the sequence number of the target message is 12 and the message reception sequence number recorded in the receiver buffer is 11, it indicates that the message has not been processed. The message 11 can be pushed to the consumer, and it can be returned that message 12 has been successfully received. The message processing center will update the received confirmation message sequence number and release message 12.

[0148] Through the above method, based on the database redo log mechanism, after an abnormal restart, the unprocessed messages can be reprocessed to improve the message sending success rate.

[0149] In some embodiments, when the unprocessed situation means that no send confirmation success has been replied to the message producer, before writing the target message into the message queue, reply to the message producer that the send confirmation for the target message is successful, and record the message sequence number of the target message as the send confirmation message sequence number in the message processing center.

[0150] If it is confirmed by comparing the sequence number of the target message and the send confirmation message sequence number in the message processing center that no send confirmation success for the target message has been replied to the message producer, the step of replying the send confirmation success needs to be executed, and the send confirmation message sequence number is updated.

[0151] In this example, these steps are only re-executed when no send confirmation success has been sent to the message producer, and the repeated execution of this step will not be caused.

[0152] This application proposes an implementation method for a fusion transaction. In this method, the original transaction mechanism of the database can be utilized to encapsulate the operations on the database and the notification operations to other databases in the same transaction, so that without development and without relying on a distributed transaction middleware, it can be monitored whether the database operations and notification operations successfully achieve transaction atomicity. The development difficulty is low, it is friendly to application developers, the system is also simple, and it will also avoid defects such as easy blocking and single-point risk leading to transaction synchronization failure caused by over-reliance on a single-point distributed transaction middleware.

[0153] The following is an illustration with reference to the accompanying drawings. Please refer to Figure 6 , Figure 6 which is a schematic flowchart of an implementation method for a fusion transaction shown in this application. As Figure 6 shown, the method includes S602 - S604.

[0154] This method is implemented based on the database shown in any of the previous embodiments. The fusion transaction includes a first operation on the first database and a notification operation for notifying the second database to execute a second operation.

[0155] The first database refers to the database shown in any of the previous embodiments. For example Figure 3 The schematic database. The kernel of this database implements the message asynchronous transmission (message queue) mechanism through the message processing center and the message queue object.

[0156] The second database refers to other databases in the cross-database operation scenario. In this scenario, the number of second databases is not limited and can be set according to actual needs.

[0157] S602, receive the processing request of the fusion transaction sent to the first database.

[0158] The specific contents of the first operation and the second operation are generated according to business requirements.

[0159] Some fusion transaction operation logics are pre-deployed in the application program. After receiving the previous business transaction, the first operation and a notification message for notifying the second database to execute the second operation can be generated, forming a notification operation, forming a fusion transaction, and sending it to the first database for execution through an instruction. The first database can receive this request. It can be understood that the application program is the message producer in the previous embodiment, and the second database and its corresponding consumer application program are the message consumers. The consumer application program, as the application program corresponding to the second database, is used to publish an instruction to the second database to complete the database operation.

[0160] For example, if a transaction occurs in the application program where account A in the first database is decreased by 20 and account B in the second database is increased by 20, then the first operation is to decrease account A by 20 in the first database, and the second operation is to increase account B by 20 in the second database. The application program takes A - 20 and notifying B + 20 as a fusion transaction. After the consumer application program receives the notification message of B + 20, it can publish an instruction to the second database to execute the operation of B + 20. The pseudo-code of the fusion transaction at the application program side is shown as:

[0161] Start transaction

[0162] Account A - 20;

[0163] Notify account B + 20;

[0164] If successful

[0165] Commit;

[0166] Else

[0167] Rollback。

[0168] S604. The first database, in response to the fusion transaction, encapsulates the execution of the first operation and the notification operation into the same transaction, and executes this transaction to ensure the execution of the first operation based on the transaction mechanism of its own kernel, and completes the atomicity of the notification operation by using the message queue mechanism integrated with the first database.

[0169] After receiving the previous fusion transaction, the first database can, through its internal transaction mechanism, ensure the execution of the first operation and complete the atomicity of notifying the second database and its corresponding consumer application to execute the second operation by using the message queue mechanism integrated with the first database.

[0170] The transaction mechanism may include: the application initiates transaction processing, and the database forms a transaction by combining the first operation on the library table and the notification message through the transaction processing layer;

[0171] The transaction processing layer records the transaction start status and coordinates each operation to perform transaction preprocessing respectively: saves the current library table status to the undo log, then executes the library table operation, and notifies the transaction processing module after the operation is completed; notification message notification preprocessing: the message is pushed from the sender to the receiver cache, and the transaction processing module is notified after the operation is completed.

[0172] If the preprocessing of both operations is successful, the transaction is committed: each operation returns that the preprocessing is successful, and the application initiates transaction commitment: performs the first operation on the library table: releases the undo log and returns that the transaction is successful; notification operation: the message is pushed from the receiver cache to the message consumer and returns that the transaction is successful.

[0173] If any operation returns that the preprocessing fails, or the application initiates transaction rollback, the transaction is rolled back: the original modification is rolled back through the undo log, the undo log is released, and rollback success is returned; notification operation: the message is released in the receiver cache and rollback success is returned.

[0174] Taking the previous example as an example, the first database will ensure the atomicity of both account A–20 and notifying account B+20 as a transaction.

[0175] Thus, through the solution described in S602 - S604, the original transaction mechanism of the database can be utilized to encapsulate the operations on the database and the notification operations to other databases in the same transaction. As a result, without the need for development or reliance on a distributed transaction middleware, it is possible to monitor whether the database operations and notification operations have successfully achieved transaction atomicity. This approach has a low development difficulty, is friendly to application developers, the system is simple, and it also avoids defects such as easy blocking and single - point risk - induced transaction synchronization failure caused by over - reliance on a single - point distributed transaction middleware.

[0176] In some embodiments, the database can execute the fusion transaction in two phases. The first phase is the pre - operation. The second phase is the commit or rollback operation.

[0177] Please refer to Figure 7 , Figure 7 which is a schematic flowchart of the method for the database to execute the fusion transaction shown in this application. Figure 7 The steps shown are the explanations for S604. As Figure 7 shown, the method may include S702 - S706.

[0178] The first phase, pre - operation.

[0179] S702, pre - execute the first operation, and pre - execute the notification operation by using the message queue mechanism of the first database fusion.

[0180] Among them, pre - executing the first operation can be understood as a regular database operation. For example Figure 3 shown, the pre - operation of account A - 20 can be completed in the database by using the core service layer and the storage layer.

[0181] Pre - executing the notification operation by using the message queue mechanism of the first database fusion is a new operation added to the database in this application. For example Figure 3 shown, in the database, message pushing can be completed by using the message processing center and the message queue object. Confirming that the message has been successfully sent to the consumer means that the pre - notification operation is successful, and if the message has not been successfully sent, it means that the pre - notification operation fails.

[0182] The second phase, commit or rollback operation.

[0183] S704, in response to the successful pre - execution of the first operation and the successful pre - execution of the notification operation, issue a commit instruction to complete the execution of the first operation and the notification operation.

[0184] S706, in response to the failure of the pre - execution of the first operation or the failure of the pre - execution of the notification operation, issue a rollback instruction to withdraw the first operation and the notification operation.

[0185] The application will issue a commit instruction to complete the actual operation only if both the first operation and the notification operation are successfully pre-executed. If any operation fails to be pre-executed successfully, a rollback operation will be issued to ensure transaction atomicity.

[0186] The solution described in S702 - S706 refers to the logic for ensuring transaction atomicity in the related art. A two-phase execution strategy is also set in the database, and the submission will only occur after all operations are successfully pre-executed; otherwise, a rollback will be performed, thus ensuring transaction atomicity.

[0187] In some embodiments, the notification operation can be completed based on the message processing center. Please refer to Figure 8 , Figure 8 which is a schematic flowchart of the process for completing the notification operation based on the message processing center shown in this application. Figure 8 The steps illustrated are an explanation of the first stage S702. As Figure 8 shown, the method may include S802 - S806.

[0188] S802, in response to receiving a notification message for instructing the second database to perform a second operation, use the message processing center to write the notification message into the redo log and into a message queue associated with the notification message, so as to transmit the notification message to the consumer application corresponding to the second database.

[0189] The description of this step can refer to the previous embodiments and will not be elaborated here. The message queue associated with the notification message refers to the queue indicated by the queue ID carried in the notification message. It can be understood that the second database and its corresponding consumer application are the consumers in the previous embodiments, and the application is the message producer.

[0190] S804, in response to receiving the message reception confirmation returned by the consumer application, determine that the pre-execution of the notification operation is successful.

[0191] S806, in response to not receiving the message reception confirmation, determine that the pre-execution of the notification operation fails.

[0192] When the consumer application corresponding to the second database receives the notification message, it may return a reception success to the message processing center, indicating that the pre-notification operation is successful. If it returns a reception failure or does not return any message, it indicates that the pre-notification fails.

[0193] The solution described in S802 - S806 can complete asynchronous message forwarding based on the message processing center and can monitor the message forwarding result to ensure transaction atomicity.

[0194] In some embodiments, the consumer application corresponds to the receiver cache; transmitting the notification message to the consumer application corresponding to the second database includes transmitting the notification message to the receiver cache corresponding to the consumer application, so that when the receiver cache corresponding to the consumer application successfully receives the notification message, it returns a message reception confirmation to the message processing center.

[0195] After issuing a commit instruction, the method further includes:

[0196] In response to receiving a commit instruction regarding the notification message, using the message processing center, write the commit instruction into a message queue associated with the commit instruction, so as to transmit the commit instruction to the receiver cache corresponding to the consumer application, so that the receiver cache corresponding to the consumer application pushes the notification message to the consumer application to complete a second operation;

[0197] After issuing a rollback instruction, the method further includes:

[0198] In response to receiving a rollback instruction regarding the notification message, using the message processing center, write the rollback instruction into a message queue associated with the rollback instruction, so as to transmit the rollback instruction to the receiver cache corresponding to the consumer application, so that the receiver cache corresponding to the consumer application releases the notification message.

[0199] In this embodiment, the difference from the Figure 5 shown solution is that transmitting the message to the receiver cache means that the task pre-notification is successful. Only after receiving the commit instruction, will the message be pushed from the receiver cache to the consumer, that is, the consumer application corresponding to the second database, ensuring the two-phase nature of the notification operation. Thus, if there is a situation where the pre-execution fails in the fusion transaction, it is only necessary to release the message in the receiver cache, which will not affect the operation of the second database. Otherwise, if it is directly pushed to the consumer application, rollback may not be possible.

[0200] In some embodiments, in response to pushing the notification message to the consumer application, return a commit success to the message processing center;

[0201] In response to the receiver cache corresponding to the consumer application releasing the notification message, return a completed rollback to the message processing center;

[0202] Using the message processing center, return the received commit success or completed rollback to the producer of the notification message to confirm the completion of the fusion transaction.

[0203] The producer of the notification message is the upper-layer application.

[0204] For example, if all the pre-operations in the first stage are successful, the second stage issues a commit instruction. When the receiving end cache receives the commit instruction, it will actually push the notification message to the consumer application, causing the consumer application to issue an instruction to the second database to perform the second operation. After the message push is completed, the message processing center can return information indicating the completion of the fusion transaction to the upper-layer application. If there is a failure in the pre-operation in the first stage, the second stage issues a rollback instruction. When the receiving end cache receives the rollback instruction, it will locally release the notification message and will not push it to the consumer application. After the message release is completed, the message processing center can return information indicating the rollback of the fusion transaction to the upper-layer application, indicating that the transaction execution has failed. Thus, feedback can be given to the application.

[0205] The following combines Figure 9 to provide a detailed two-phase process description of the notification operation completed based on the message processing center. Please refer to Figure 9 , Figure 9 which is a schematic diagram of the process for completing the notification operation based on the message processing center shown in this application. Figure 9 The steps shown are descriptions of the two-phase transaction processing. As Figure 9 shown, the method may include S901 - S910.

[0206] The first stage is preprocessing.

[0207] S901, after the application generates a notification message, it pushes the notification message to the sending end cache. For relevant descriptions, refer to S501.

[0208] S902, the sending end cache sets a message sequence number and the queue ID of the message queue for the notification message to associate the notification message with the message queue, and sends the notification message to the message processing center, and records the message sequence number as the sent message sequence number in the sending end cache. For relevant descriptions, refer to S502.

[0209] S903, the message processing center writes the message into the redo log, replies to the message producer that the sending is confirmed successfully, and records the message sequence number as the sent confirmation message sequence number in the message processing center. For relevant descriptions, refer to S903.

[0210] S904, the message processing center writes the message into the message queue corresponding to the queue ID, and pushes the message to the receiving end cache through the communication connection, and records the message sequence number as the message received sequence number in the message processing center. For relevant descriptions, refer to S904.

[0211] S905. After receiving the notification message, the receiving - end buffer replies with a successful receipt confirmation to the message processing center. The message processing center also replies with a successful receipt confirmation to the message producer (application program), and records the message sequence number as the message receipt sequence number in the receiving - end buffer.

[0212] The difference between this step and S505 is that after the receiving - end buffer successfully receives the message, it does not push the message to the consumer first, and returns a successful receipt confirmation. The message processing center also replies with a successful receipt confirmation to the message producer (application program). This enables the upper - layer application to clearly know that the first - stage pre - notification operation is successful. If the upper - layer application does not receive the successful receipt confirmation for a long time or receives a notification of receipt failure, it can consider that the first - stage pre - notification fails.

[0213] S906. After receiving the successful receipt confirmation feedback from the receiving - end buffer, the message processing center releases the local message and records the receipt confirmation message sequence number in the message processing center. The relevant operations can refer to S506.

[0214] The above is the completion of the first stage.

[0215] The second stage.

[0216] S907. The message producer generates a commit instruction or a rollback instruction according to the return situation of the first stage and publishes it to the message processing center.

[0217] In this step, the application program can generate the corresponding commit instruction or rollback instruction according to the first - stage pre - processing result, and encapsulate it as a message through the sending - end buffer and send it to the message processing center.

[0218] S908. The message processing center can forward the commit instruction or rollback instruction to the receiving - end buffer.

[0219] This step can be completed by forwarding through the message queue or directly forwarding.

[0220] S909. If the receiving - end buffer receives the commit instruction, it pushes the notification message to the consumer, that is, the consumer application program corresponding to the second database; if it receives the rollback instruction, it locally releases the notification message.

[0221] S910. After the receiving - end completes the corresponding operation, it returns a successful commit confirmation or a successful rollback confirmation to the message processing center. The message processing center also returns a successful commit confirmation or a successful rollback confirmation to the message producer. Thus, the entire fusion transaction is completed.

[0222] Through the solution illustrated by S901 - S910, it is possible to monitor message forwarding in a two - stage manner based on a database integrated with a message queue mechanism, by utilizing the original transaction mechanism of the database. Thus, without the need for development or reliance on a distributed transaction middleware, it is possible to monitor whether the database operations and notification operations successfully achieve transaction atomicity. This approach has a low development difficulty, is friendly to application developers, the system is simple, and it also avoids defects such as easy blocking due to over - reliance on a single - point distributed transaction middleware and transaction synchronization failures caused by single - point risks.

[0223] Corresponding to any of the above - mentioned embodiments, the present application further proposes an implementation device for integrated transactions. Please refer to Figure 10 , Figure 10 which is a schematic structural diagram of an implementation device for integrated transactions shown in the embodiments of the present application. The device is implemented based on the database shown in any of the previous embodiments. The integrated transaction includes a first operation on a first database and a notification operation for notifying a second database to execute a second operation; the first database refers to the database shown in any of the previous embodiments. As Figure 10 shown, the implementation device 1000 for integrated transactions includes:

[0224] A receiving module 1010, which receives a processing request for the integrated transaction sent to the first database;

[0225] An execution module 1020, in response to the integrated transaction, the first database encapsulates the execution of the first operation and the notification operation into the same transaction, and executes this transaction to ensure the execution of the first operation based on its own kernel transaction mechanism, and to complete the atomicity of the notification operation by using the message queue mechanism integrated with the first database.

[0226] In some embodiments, the execution module 1020 further:

[0227] Pre - execute the first operation and pre - execute the notification operation by using the message queue mechanism integrated with the first database;

[0228] In response to the successful pre - execution of the first operation and the successful pre - execution of the notification operation, issue a commit instruction to complete the execution of the first operation and the notification operation;

[0229] In response to the failure of the pre - execution of the first operation or the failure of the pre - execution of the notification operation, issue a rollback instruction to withdraw the first operation and the notification operation.

[0230] In some embodiments, the execution module 1020 further:

[0231] In response to receiving a notification message for the second database to perform a second operation, the message processing center is used to write the notification message to the redo log and to a message queue associated with the notification message, so as to transmit the notification message to the consumer application corresponding to the second database;

[0232] In response to receiving the message reception confirmation returned by the consumer application, it is determined that the pre-execution of the notification operation is successful;

[0233] In response to not receiving the message reception confirmation, it is determined that the pre-execution of the notification operation fails.

[0234] In some embodiments, the consumer application corresponds to a receiver cache; the execution module 1020 further:

[0235] Transmit the notification message to the receiver cache corresponding to the consumer application, so that the receiver cache corresponding to the consumer application returns a message reception confirmation to the message processing center when the notification message is successfully received;

[0236] After issuing a commit instruction, in response to receiving a commit instruction regarding the notification message, the message processing center is used to write the commit instruction to a message queue associated with the commit instruction, so as to transmit the commit instruction to the receiver cache corresponding to the consumer application, so that the receiver cache corresponding to the consumer application pushes the notification message to the consumer application to complete the second operation;

[0237] After issuing a rollback instruction, in response to receiving a rollback instruction regarding the notification message, the message processing center is used to write the rollback instruction to a message queue associated with the rollback instruction, so as to transmit the rollback instruction to the receiver cache corresponding to the consumer application, so that the receiver cache corresponding to the consumer application releases the notification message.

[0238] In some embodiments, the execution module 1020 further:

[0239] In response to pushing the notification message to the consumer application, return commit success to the message processing center;

[0240] In response to the receiver cache corresponding to the consumer application releasing the notification message, return completion of rollback to the message processing center;

[0241] Using the message processing center, return the received commit success or completion of rollback to the producer of the notification message to confirm the completion of the fusion transaction.

[0242] In the solution described in the foregoing device embodiments, the original transaction mechanism of the database can be utilized to encapsulate the operations on the database and the notification operations for notifying other databases in the same transaction, so that without development and without relying on a distributed transaction middleware, it is possible to monitor whether the database operations and the notification operations successfully achieve transaction atomicity. This has a low development difficulty, is friendly to application developers, the system is also simple, and it can also avoid defects such as easy blocking and single-point risk leading to transaction synchronization failure caused by over-reliance on a single-point distributed transaction middleware.

[0243] The embodiments of the implementation device for the fusion transaction shown in this application can be applied to an electronic device. Correspondingly, this application discloses an electronic device, which may include: a processor.

[0244] A memory for storing executable instructions that can be executed by the processor.

[0245] Wherein, the processor is configured to call the executable instructions stored in the memory to implement the implementation method of the fusion transaction shown in any of the foregoing embodiments.

[0246] Please refer to Figure 11 , Figure 11 which is a schematic diagram of the hardware structure of an electronic device shown in the embodiments of this application.

[0247] As Figure 11 shown, the electronic device may include a processor for executing instructions, a network interface for network connection, a memory for storing running data for the processor, and a non-volatile memory for storing the corresponding instructions of the implementation device for the fusion transaction.

[0248] Wherein, the embodiments of the device can be implemented through software, or through hardware or a combination of software and hardware. Taking software implementation as an example, as a logically meaningful device, it is formed by the processor of the electronic device where it is located reading the corresponding computer program instructions in the non-volatile memory into the memory for operation. From the hardware level, in addition to Figure 11 the processor, memory, network interface, and non-volatile memory shown, the electronic device where the device in the embodiments is located usually may further include other hardware according to the actual functions of the electronic device, which will not be elaborated here.

[0249] It can be understood that in order to improve the processing speed, the corresponding instructions of the implementation device for the fusion transaction may also be directly stored in the memory, which is not limited herein.

[0250] This application proposes a computer-readable storage medium, and the storage medium stores a computer program, and the computer program can be used to enable the processor to execute the implementation method of the fusion transaction shown in any of the foregoing embodiments.

[0251] Those skilled in the art should understand that one or more embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, one or more embodiments of the present application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present application can take the form of a computer program product implemented on one or more computer-usable storage media (which may include, but are not limited to, disk storage, CDROM, optical storage, etc.) that contain computer-usable program code.

[0252] "And / or" in the present application means at least one of the two. For example, "A and / or B" can include three scenarios: A, B, and "A and B".

[0253] Each embodiment in the present application is described in a progressive manner. For the same or similar parts between each embodiment, reference can be made to each other, and the key point of each embodiment is to illustrate the differences from other embodiments. In particular, for the embodiment of the data processing device, since it is basically similar to the method embodiment, the description is relatively simple, and reference can be made to the corresponding part of the method embodiment for relevant content.

[0254] The above describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the acts or steps recited in the claims can be performed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the figures do not necessarily require the particular order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0255] The subject matter and embodiments of the functional loading described in the present application can be implemented in the following: digital electronic circuits, tangible computer software or firmware, computer hardware that can include the structures disclosed in the present application and their structural equivalents, or a combination of one or more of them. Embodiments of the subject matter described in the present application can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non-transitory program carrier to be executed by a data processing device or to control the loading of the data processing device. Alternatively or additionally, the program instructions can be encoded on an artificially generated propagated signal, such as a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode and transmit information to a suitable receiver device for execution by the data processing device. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.

[0256] The processes and logical flows described in this application can be executed by one or more programmable computers executing one or more computer programs to perform corresponding functions by loading based on input data and generating output. The processes and logical flows can also be executed by special-purpose logic circuitry, such as an FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and the apparatus can also be implemented as special-purpose logic circuitry.

[0257] Computers suitable for executing computer programs can include, for example, general and / or special-purpose microprocessors, or any other type of central processing unit. Generally, the central processing unit will receive instructions and data from a read-only memory and / or a random access memory. The basic components of a computer can include a central processing unit for implementing or executing instructions and one or more memory devices for storing the instructions and data. Generally, a computer will also can include one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, etc., or the computer will be loadably coupled to such mass storage devices to receive data therefrom or transfer data thereto, or both. However, a computer is not necessarily required to have such devices. In addition, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name just a few.

[0258] Computer-readable media suitable for storing computer program instructions and data can include all forms of non-volatile memory, media, and memory devices, such as can include semiconductor memory devices (such as EPROM, EEPROM, and flash memory devices), magnetic disks (such as internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special-purpose logic circuitry.

[0259] Although this application contains many specific implementation details, these should not be construed as limiting the scope of any disclosure or the scope of what is claimed, but rather are mainly used to describe the features of specific embodiments of a particular disclosure. Certain features described in multiple embodiments in this application can also be implemented in combination in a single embodiment. On the other hand, various features described in a single embodiment can also be implemented separately in multiple embodiments or in any suitable sub-combination. In addition, although features can operate in certain combinations as described and are even initially claimed as such, one or more features from a claimed combination can in some cases be removed from that combination, and the claimed combination can be directed to a sub-combination or a variation of a sub-combination.

[0260] Similarly, although the loads are depicted in a particular order in the figures, this should not be construed as requiring that these loads be performed in the particular order shown or sequentially, or that all of the illustrated loads be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Additionally, the separation of the various system modules and components in the embodiments described should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0261] Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the acts recited in the claims can be performed in a different order and still achieve the desired result. Additionally, the processing depicted in the figures is not necessarily in the particular order or sequential order shown to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0262] The foregoing are only preferred embodiments of one or more embodiments of the present application, and are not intended to limit one or more embodiments of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of one or more embodiments of the present application shall be included within the scope of protection of one or more embodiments of the present application.

Claims

1. A database integrating a message queue, characterized in that: The database includes a message processing center; the message processing center is connected to the message producer and the message consumer through the communication mechanism of the database; the database also includes message queues allocated to the message producer and the message consumer; The message producer is used to generate a message and send it to the message processing center; The message processing center is configured to, in response to receiving the message, write the message into a redo log based on a redo log mechanism supported by the database kernel, and write the message into the message queue; The message consumer is used to obtain the message from the message queue through the communication connection to complete the consumption, and utilize the original transaction mechanism of the database to encapsulate the message sent by the message queue in a local database transaction.

2. A database for integrating message queues according to claim 1, characterized in that: The message processing center, in response to an abnormal restart, reads the target message that has not been completely processed from the redo log, and writes the target message into the message queue, so that the message consumer completes consumption of the target message.

3. A database for integrating message queues according to claim 2, characterized in that: The message producer corresponds to the sender cache, and the message consumer corresponds to the receiver cache; After generating the message, the message producer sends the generated message to the sender cache; The sending end cache sets a message sequence number and a queue ID of the message queue for the message to associate the message with the message queue, sends the message to the message processing center, and records the message sequence number in the sending end cache as a sending message sequence number; The message processing center writes the message into the redolog, replies to the message producer with a successful sending confirmation, and records the message sequence number as the sending confirmation message sequence number in the message processing center; and writes the message into the message queue corresponding to the queue ID, pushes the message to the receiving end cache through the communication connection, and records the message sequence number as the message receiving sequence number in the message processing center; The receiving end cache pushes the message to the message consumer, responds to the message processing center with a successful push, and records the message sequence number as the message reception sequence number in the receiving end cache; The message consumer receives the message and completes consumption; The message processing center releases the local message upon receiving the successful reception confirmation fed back by the receiving end buffer, and records the reception confirmation message sequence number in the message processing center.

4. A database for integrating message queues according to claim 3, characterized in that: The message processing center, in response to the abnormal restart, reads the target message that has not been processed from the redo log, writes the target message into the message queue, pushes the target message to the receiving end cache through the communication connection, and records the message sequence number of the target message as the message receiving sequence number in the message processing center; The receiving-end cache, in response to receiving the target message, pushes the target message to the message consumer when the message sequence number of the target message is greater than the locally recorded message receiving sequence number, replies to the message processing center with a successful reception confirmation in response to a successful push, and records the message sequence number of the target message in the receiving-end cache as the message receiving sequence number.

5. A database for integrating message queues according to claim 4, characterized in that: In the case where the incomplete processing means that no sending confirmation is replied to the message producer, before the target message is written into the message queue, a sending confirmation of the target message is replied to the message producer, and the message sequence number of the target message is recorded in the message processing center as the sending confirmation message sequence number.

6. A method for implementing a fusion transaction, characterized in that: The method is implemented based on the database according to any one of claims 1 to 5, wherein the fusion transaction includes a first operation on a first database and a notification operation for notifying a second database to perform a second operation; The first database refers to the database according to any one of claims 1 to 5; The method comprises: receiving a processing request for the fusion transaction sent to the first database; In response to the fused transaction, the first database encapsulates the execution of the first operation and the notification operation into the same transaction, and executes the transaction based on the transaction mechanism of its own kernel to ensure the execution of the first operation and the atomicity of completing the notification operation using the message queue mechanism fused by the first database.

7. A method for implementing a fusion transaction according to claim 6, characterized in that: The executing of the transaction ensures the execution of the first operation based on the transaction mechanism of the kernel itself, and completes the atomicity of the notification operation by using the message queue mechanism integrated by the first database, including: Pre-execute the first operation, and pre-execute the notification operation using a message queue mechanism integrated with the first database; In response to the success of pre-execution of the first operation and the success of pre-execution of the notification operation, issuing a commit instruction to complete execution of the first operation and the notification operation; In response to a failure in pre-execution of the first operation or a failure in pre-execution of the notification operation, a rollback instruction is issued to withdraw the first operation and the notification operation.

8. A method for implementing a fusion transaction according to claim 7, characterized in that: The pre-execution of the notification operation by using the message queue mechanism integrated with the first database includes: In response to receiving a notification message notifying the second database to perform a second operation, using the message processing center, writing the notification message into a redo log and a message queue associated with the notification message, so as to transmit the notification message to a consumer application corresponding to the second database; In response to receiving a message reception confirmation returned by the consumer-end application, determining that the pre-execution of the notification operation is successful; In response to not receiving a message receipt confirmation, it is determined that pre-execution of the notification operation has failed.

9. A method for implementing a fusion transaction according to claim 8, characterized in that: The consumer-side application corresponds to a receiving-side cache; The transmitting the notification message to the consumer application corresponding to the second database includes: Transmitting the notification message to a receiving end cache corresponding to the consumer application, so that the receiving end cache corresponding to the consumer application returns a message reception confirmation to the message processing center when the notification message is successfully received; After issuing the commit instruction, the method further includes: In response to receiving a submission instruction regarding the notification message, using the message processing center, writing the submission instruction into a message queue associated with the submission instruction, so as to transmit the submission instruction to a receiving end cache corresponding to the consumer-end application, so that the receiving end cache corresponding to the consumer-end application pushes the notification message to the consumer-end application to complete the second operation; After issuing the rollback instruction, the method further includes: In response to receiving a rollback instruction regarding the notification message, the message processing center is used to write the rollback instruction into a message queue associated with the rollback instruction, so as to transmit the rollback instruction to the receiving-end cache corresponding to the consumer-end application, so that the notification message is released by the receiving-end cache corresponding to the consumer-end application.

10. A method for implementing a fusion transaction according to claim 9, characterized in that: The method further comprises: In response to pushing the notification message to the consumer application, returning a submission success to the message processing center; In response to the receiving end cache corresponding to the consumer end application releasing the notification message, returning the completion rollback to the message processing center; The message processing center is used to return the received submission success or completion rollback to the generator of the notification message to confirm the completion of the fusion transaction.

Images