A highly available online transaction method, apparatus, equipment, and storage medium that combines database sharding and dynamic multi-active failover.

Abstract

This application discloses a highly available online transaction method, apparatus, device, and storage medium combining database sharding and dynamic multi-active switching, relating to the field of computer technology. The method includes: responding to a transaction request by determining a business transaction mode based on the operating status of each transaction data shard; when the business transaction mode is a fault-random mode, determining at least one available data shard among multiple transaction data shards; and processing the transaction request according to the transaction application corresponding to the available data shard. Through this method, in fault-random mode, at least one available data shard is determined based on the operating status of each transaction data shard, and the transaction request is processed using the transaction application of that available data shard. Flexible switching of transaction modes is achieved through the operating status of the shards, improving the availability and stability of the business system, accelerating response speed, reducing transaction losses, and lowering the complexity of operation and maintenance.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a highly available online transaction method, apparatus, device, and storage medium that combines database sharding and dynamic multi-active switching. Background Technology

[0002] Business systems provide services based on cloud services. Compared to traditional mainframes, cloud services have more complex layers and a higher failure rate. Current application deployments are distributed, involving multiple databases, instances, and data centers. For online services, to increase system throughput and ensure high availability, multiple databases and applications are grouped into clusters, with services routed to specific databases according to designated factors. To achieve highly available distributed deployments for large-volume data businesses, data is often horizontally or vertically partitioned and stored in multiple databases, with corresponding applications deployed on each database. Currently, horizontal database partitioning deployments include database sharding and active-active deployments. In a database sharding deployment, if one shard fails, users on that shard cannot conduct transactions. Summary of the Invention

[0003] The main objective of this application is to provide a highly available online transaction method, apparatus, device, and storage medium that combines database sharding and dynamic multi-active switching, aiming to solve the technical problem in the existing database sharding deployment where users stored in a database cannot conduct transactions when a database shard goes down.

[0004] To achieve the above objectives, this application proposes a high-availability online transaction method combining database sharding and dynamic multi-active failover. The high-availability online transaction method combining database sharding and dynamic multi-active failover includes:

[0005] In response to transaction requests, the business transaction mode is determined based on the operational status of each transaction data sub-database;

[0006] When the business transaction mode is a random failure mode, at least one available data shard is determined from multiple transaction data shards.

[0007] The transaction request is processed according to the transaction application corresponding to the available data shard.

[0008] In one embodiment, the step of determining the business transaction mode based on the operating status of each transaction data sub-database includes:

[0009] When the operation status of the transaction data sharding database is down, the business transaction mode is determined to be the fault random mode;

[0010] If all transaction data shards are online within a preset historical time period, the business transaction mode is determined to be the shard distribution mode.

[0011] When all transaction data sub-databases are in an online state and there is a transaction data sub-database in an offline state within a preset historical time period, the business transaction mode is determined to be the fault recovery mode.

[0012] In one embodiment, the step of processing the transaction request according to the transaction application corresponding to the available data shard includes:

[0013] When multiple available data shards exist, obtain the current capacity of each available data shard;

[0014] The target data shard is determined from multiple available data shards based on the current capacity of each available data shard.

[0015] The transaction request is sent to the transaction application corresponding to the target data shard, so that the transaction application corresponding to the target data shard can process the transaction request.

[0016] In one embodiment, the step of obtaining the current capacity of each available data shard when multiple available data shards exist includes:

[0017] When multiple available data shards exist, the transaction type of the transaction request is obtained;

[0018] When the transaction type is a positive transaction, a duplicate verification request is generated;

[0019] Send the anti-duplicate verification request to the transaction application corresponding to each available data shard, so that each available data shard can return the anti-duplicate verification result according to the transaction application corresponding to each available data shard;

[0020] When the anti-duplicate verification results returned by each available data shard are all preset results, obtain the current capacity of each available data shard.

[0021] In one embodiment, after the step of determining the business transaction mode based on the operating status of each transaction data sub-database in response to a transaction request, the method further includes:

[0022] When the business transaction mode is the sharding and distribution mode, obtain the transaction identifier code of the transaction request;

[0023] The target data shard is determined from multiple transaction data shards based on the sharding distribution rules and the transaction identifier code.

[0024] The transaction request is sent to the transaction application corresponding to the target data shard, so that the transaction application corresponding to the target data shard can process the transaction request.

[0025] In one embodiment, after the step of determining the business transaction mode based on the operating status of each transaction data sub-database in response to a transaction request, the method further includes:

[0026] When the business transaction mode is fault recovery mode and the transaction request is a related transaction, the transaction request is broadcast so that each transaction data sub-database can return the transaction query results;

[0027] The target data sub-database is determined from among multiple transaction data sub-databases based on the transaction query results fed back from each transaction data sub-database.

[0028] The transaction request is sent to the transaction application corresponding to the target data shard, so that the transaction application corresponding to the target data shard can process the transaction request.

[0029] In one embodiment, before the step of determining the business transaction mode based on the operating status of each transaction data sub-database in response to a transaction request, the method further includes:

[0030] Upon receiving a transaction request, obtain the running status of the downstream user database;

[0031] When the downstream user database is in an online state, the step of responding to the transaction request and determining the business transaction mode based on the operating status of each transaction data sub-database is executed.

[0032] Furthermore, to achieve the above objectives, this application also proposes a high-availability online transaction device that combines database sharding and dynamic multi-active switching, wherein the high-availability online transaction device combining database sharding and dynamic multi-active switching includes:

[0033] The processing module is used to respond to transaction requests and determine the business transaction mode based on the operating status of each transaction data sub-database.

[0034] The processing module is also used to determine at least one available data shard among multiple transaction data shards when the business transaction mode is a fault random mode.

[0035] The processing module is also used to process the transaction request according to the transaction application corresponding to the available data shard.

[0036] In addition, to achieve the above objectives, this application also proposes a high-availability online transaction device that combines database sharding and dynamic multi-active switching. The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the high-availability online transaction method that combines database sharding and dynamic multi-active switching as described above.

[0037] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the high-availability online transaction method combining database sharding and dynamic multi-active switching as described above.

[0038] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the high-availability online transaction method combining database sharding and dynamic multi-active switching as described above.

[0039] The method of this application includes: responding to a transaction request, determining a business transaction mode based on the operating status of each transaction data sub-database; when the business transaction mode is a fault-random mode, determining at least one available data sub-database among multiple transaction data sub-databases; and processing the transaction request according to the transaction application corresponding to the available data sub-database. Through the above method, the corresponding transaction mode is selected based on the operating status of each transaction data sub-database, and in the fault-random mode, at least one available data sub-database is determined based on the operating status of each transaction data sub-database. The transaction request is processed using the transaction application of the available data sub-database. Flexible switching of transaction modes is achieved through the operating status of the sub-databases, improving the availability and stability of the business system, accelerating response speed, reducing transaction losses, and lowering the complexity of operation and maintenance. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0041] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a flowchart illustrating an embodiment of the highly available online transaction method combining database sharding and dynamic multi-active switching in this application.

[0043] Figure 2 A schematic diagram of the system architecture for a highly available online transaction method combining database sharding and dynamic multi-active switching provided in Embodiment 1 of this application;

[0044] Figure 3 A schematic diagram of the database distribution mode architecture for a highly available online transaction method that combines database sharding and dynamic multi-active switching, as provided in Embodiment 1 of this application;

[0045] Figure 4 A schematic diagram of the fault recovery mode architecture of the high-availability online transaction method combining database sharding and dynamic multi-active switching provided in Embodiment 1 of this application;

[0046] Figure 5 This is a flowchart illustrating Embodiment 2 of the high-availability online transaction method combining database sharding and dynamic multi-active switching in this application.

[0047] Figure 6 A schematic diagram of the fault random mode architecture of the high-availability online transaction method combining database sharding and dynamic multi-active switching provided in Embodiment 2 of this application;

[0048] Figure 7 A simplified flowchart illustrating the highly available online transaction method combining database sharding and dynamic multi-active switching provided in Embodiment 2 of this application;

[0049] Figure 8 This is a schematic diagram of the module structure of a highly available online transaction device that combines database sharding and dynamic multi-active switching, as described in an embodiment of this application.

[0050] Figure 9 This is a schematic diagram of the hardware operating environment involved in the high-availability online transaction method combining database sharding and dynamic multi-active switching in the embodiments of this application.

[0051] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0052] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0053] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0054] The main solution of this application embodiment is: in response to a transaction request, a business transaction mode is determined based on the operating status of each transaction data sub-database; when the business transaction mode is a fault random mode, at least one available data sub-database is determined among multiple transaction data sub-databases; and the transaction request is processed according to the transaction application corresponding to the available data sub-database.

[0055] Currently, horizontal database deployment includes two forms: database sharding and active-active deployment. Database sharding means that user data is distributed across multiple different databases. When a user needs to perform a transaction, the transaction system routes the transaction to a designated database shard. Active-active deployment means that the basic data that the application relies on is stored synchronously across all databases. The data is stateless, and when a user performs a transaction, the transaction system routes the transaction to any database. Database sharding deployment has the following advantages: when a single database fails, only users in that database are affected, and users in other databases are not affected. The application's routing rules are simple, and preventing duplicate transactions and finding the original transaction are relatively simple. Active-active deployment has the following advantages: user transactions can be stored in any database. When a database fails, the failed database can be directly removed, and other databases can still provide complete service. In addition to the advantages mentioned above, the current database sharding deployment also has the following disadvantages: When a database shard goes down, users stored in that database cannot conduct transactions and can only wait for the database to recover; the current multi-active deployment also has the following disadvantages: the underlying data must be stateless. If there are scenarios with uniquely identifiable data such as user balances, synchronization between multiple databases cannot be achieved, so this scenario cannot be used; in addition, if there are related transactions such as transaction status queries, cancellations, and refunds, finding the original transaction will be difficult and requires traversing all databases.

[0056] This application provides a solution that selects the appropriate transaction mode based on the operating status of each transaction data shard. In the fault random mode, at least one available data shard is determined based on the operating status of each transaction data shard. The transaction application of the available data shard is used to process transaction requests. The transaction mode can be flexibly switched by the operating status of the shard, which improves the availability and stability of the business system, speeds up the response time, reduces transaction losses, and reduces the complexity of operation and maintenance.

[0057] It should be noted that the execution subject in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a highly available online transaction device that combines database sharding and dynamic multi-active switching to achieve the above functions. The following description uses a highly available online transaction device combining database sharding and dynamic multi-active switching as an example to illustrate this embodiment and the subsequent embodiments.

[0058] Based on this, embodiments of this application provide a highly available online transaction method that combines database sharding and dynamic multi-active failover, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the highly available online transaction method combining database sharding and dynamic multi-active switching in this application.

[0059] In this embodiment, the method includes steps S10 to S30:

[0060] Step S10: In response to the transaction request, determine the business transaction mode based on the operating status of each transaction data sub-database.

[0061] It should be noted that the business system architecture involved in this embodiment is as follows: Figure 2 As shown, the system includes multiple transaction data sub-databases 01-04, corresponding transaction applications 01-04 for each sub-database, and a microservice center. Each transaction data sub-database in this embodiment stores the basic data required to complete the transaction, such as card BIN data, transaction country / currency mapping relationships, transaction risk control rules, and error code mapping rules. This basic data does not require frequent updates, does not store customer information, and does not require an efficient synchronization mechanism to ensure complete consistency across sub-databases. The microservice center provides the addresses of the transaction applications, their liveness status, and the liveness status of each transaction data sub-database. The code deployed for the transaction applications corresponding to each transaction data sub-database is consistent. Each transaction application is deployed in multiple instances, with no state between application instances. Deployment instances can be added, and instances can be automatically replaced. In this embodiment, the upstream system may initiate forward transactions, as well as related transactions such as queries or reversals. The business system needs to have anti-duplicate capabilities for forward transactions, and related transactions need to be processed back to the original transaction data sub-database. The business system in this embodiment is not responsible for controlling constraints such as limits and balances that need to be jointly controlled with historical transactions or other transactions.

[0062] In this embodiment, under normal circumstances, all transaction data shards and transaction applications work normally, and the business system can work efficiently. In abnormal circumstances, there is no need to wait for the data shards to recover, and the system can switch to other shards to continue providing services, which can reduce transaction losses and improve the availability of the system in unstable database environments.

[0063] It is understood that the high-availability online transaction device combining database sharding and dynamic multi-active switching in this embodiment is equipped with a business system. When the business system receives a transaction request initiated by the transaction initiator, it obtains the running status of each transaction data shard. In this embodiment, the running status of each transaction data shard refers to its liveness status, which includes two states: downtime and online. In the downtime state, the transaction data shard is unavailable; in the online state, the transaction data shard can operate normally.

[0064] In its specific implementation, this embodiment includes three business transaction modes: a sharding distribution mode, a fault random mode, and a fault recovery mode. Different methods are used to process transaction requests under different business transaction modes, and the business transaction mode is determined based on the operational status of each transaction data shard in the business system.

[0065] In one feasible implementation, determining the business transaction mode based on the operating status of each transaction data sub-database in step S10 may include steps A11 to A13:

[0066] Step A11: When the running status of the transaction data sharding database is down, determine the business transaction mode as the fault random mode.

[0067] It should be noted that when there is a transaction data shard in the running state of being down, and another transaction data shard in the running state of being online, it means that the business system can still operate normally. In this case, the business transaction mode is determined to be the fault random mode.

[0068] Step A12: When all transaction data sub-databases are online within a preset historical time period, the business transaction mode is determined to be the sub-database distribution mode.

[0069] It should be noted that the preset historical time period refers to the time period of the preset time interval from the current time. In this embodiment, the preset time interval T1 can be set as the maximum time interval between the related transaction and the original positive transaction, or it can be set to other times as needed. For example, if the preset time interval T1 is 10 minutes and the current time is 10:00:00, then the preset historical time period is 09:50:00 to 10:00:00.

[0070] It is understandable that if all transaction data sub-databases are currently online and no transaction data sub-database is down within the preset historical time period, it indicates that all transaction data sub-databases are online within the preset historical time period. In this case, the business transaction mode is determined to be the sub-database distribution mode. In this embodiment, if no transaction data sub-database is down or if a transaction data sub-database was down previously but the fault recovery time has reached the preset time interval, the business transaction mode is determined to be the sub-database distribution mode.

[0071] Step A13: When all transaction data sub-databases are in an online state and there is a transaction data sub-database in an offline state within a preset historical time period, the business transaction mode is determined to be the fault recovery mode.

[0072] It should be noted that at the current moment, all transaction data sub-databases are in an online state, but there are transaction data sub-databases in a down state during the preset historical time period. This indicates that after a transaction data sub-database goes down, the fault recovery time has not yet reached the preset time interval. In this case, the business transaction mode is determined to be the fault recovery mode.

[0073] In one feasible implementation, steps B11 to B13 may be included after step S10:

[0074] Step B11: When the business transaction mode is the sharding and distribution mode, obtain the transaction identifier code of the transaction request.

[0075] Step B12: Determine the target data shard from among multiple transaction data shards according to the sharding distribution rules and the transaction identifier code.

[0076] Step B13: Send the transaction request to the transaction application corresponding to the target data shard, so that the transaction application corresponding to the target data shard can process the transaction request.

[0077] It should be noted that in the database sharding distribution mode, all transaction applications corresponding to all transaction data shards are alive. At this time, the transaction identifier code of the transaction request is obtained. In this embodiment, the transaction identifier code can be a unique key value of the transaction request, or it can be other parameters; this embodiment does not impose any restrictions on this.

[0078] It is understood that the database sharding distribution rule is used to determine the transaction data shard corresponding to the transaction request. In this embodiment, the database sharding distribution rule can be set as follows: the remainder n after dividing the transaction identifier code of the transaction request by the number of transaction data shards + a constant a = the number of the transaction data shard (i.e., the transaction application). In this embodiment, the constant a can be set according to business needs, and this embodiment does not impose any restrictions on it. In this embodiment, the constant a is set to 1.

[0079] In practical implementation, the target data shard is determined from multiple transaction data shards based on the sharding distribution rules and transaction identifier codes. The transaction request is then sent to the corresponding transaction application for that target data shard, which processes the request. For example, ... Figure 3 As shown, when the transaction identifier code of transaction request A is 1, according to the database distribution rules, the transaction application code corresponding to the target data database of transaction request A is 2. At this time, transaction request A is sent to transaction application 02. When the related transactions of transaction request A are also sent to transaction application 02 corresponding to transaction request A.

[0080] In one feasible implementation, after step S10, steps C11 to C13 may also be included:

[0081] Step C11: When the business transaction mode is fault recovery mode and the transaction request is a related transaction, the transaction request is broadcast so that each transaction data sub-database can return the transaction query results.

[0082] Step C12: Determine the target data sub-database from among multiple transaction data sub-databases based on the transaction query results returned by each transaction data sub-database.

[0083] Step C13: Send the transaction request to the transaction application corresponding to the target data shard, so that the transaction application corresponding to the target data shard can process the transaction request.

[0084] It should be noted that when the business transaction mode is fault recovery mode, it means that the previously downed transaction data shard has been restored, and the recovery time has reached the preset time interval. All transaction applications corresponding to each transaction data shard are now available. At this point, the transaction type of the transaction request is determined. In this embodiment, the transaction type includes, but is not limited to, related transactions and forward transactions; related transactions include, but are not limited to, query transactions and reversal transactions.

[0085] Understandably, in fault recovery mode, if a transaction request is a related transaction, since the system has just recovered, the forward transactions of the related transactions were randomly distributed in the previous stage. In this case, it is necessary to broadcast the related transactions to all transaction data shards, such as... Figure 4 As shown, each transaction data shard will return the corresponding transaction query results. If the forward transaction of a related transaction is conducted in this transaction data shard, the transaction data shard will return a transaction query result indicating that the forward transaction was found; otherwise, the transaction data shard will return a transaction query result indicating that the forward transaction could not be found.

[0086] In practice, the transaction data shards that handle the related transaction can be determined by the transaction query results fed back from each transaction data shard. These transaction data shards are then used as the target data shards, and the related transaction is sent to the transaction application corresponding to the target data shard. The transaction request is then processed by the transaction application corresponding to the target data shard.

[0087] It should be noted that when the business transaction mode is fault recovery mode and the transaction request is a positive transaction, the business system needs to perform a full database query on the transaction before the transaction to prevent duplicates.

[0088] In one feasible implementation, steps D11 to D12 may be included before step S10:

[0089] Step D11: Upon receiving a transaction request, obtain the running status of the downstream user database.

[0090] Step D12: When the downstream user database is in an online state, execute the step of responding to the transaction request and determining the business transaction mode based on the operating status of each transaction data sub-database.

[0091] It should be noted that the downstream user database refers to the database that stores user balances and other relevant customer information. When the business system receives a transaction request, it obtains the running status of the downstream user database. If the running status of the downstream user database is online, it means that the business system, as a transaction relay station, can normally execute the transaction initiated by the user. At this time, it responds to the transaction request initiated by the transaction initiator and executes the steps of determining the business transaction mode based on the running status of each transaction data sub-database.

[0092] Step S20: When the business transaction mode is a fault random mode, at least one available data shard is determined among multiple transaction data shards.

[0093] It should be noted that when the business transaction mode is the random failure mode, it means that at least one transaction data shard is in a downtime state. In this case, the transaction data shard that is in an online state will be regarded as the available data shard.

[0094] Step S30: Process the transaction request according to the transaction application corresponding to the available data shard.

[0095] It should be noted that transaction requests are processed through the transaction applications corresponding to the available data shards in the business system to ensure the normal operation of transactions.

[0096] The method in this embodiment includes: responding to a transaction request, determining a business transaction mode based on the operating status of each transaction data sub-database; when the business transaction mode is a fault-random mode, determining at least one available data sub-database among multiple transaction data sub-databases; and processing the transaction request according to the transaction application corresponding to the available data sub-database. Through this method, a corresponding transaction mode is selected based on the operating status of each transaction data sub-database, and in the fault-random mode, at least one available data sub-database is determined based on the operating status of each transaction data sub-database. The transaction request is processed using the transaction application of this available data sub-database. Flexible switching of transaction modes is achieved through the operating status of the sub-databases, improving the availability and stability of the business system, accelerating response speed, reducing transaction losses, and lowering the complexity of operation and maintenance.

[0097] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 The highly available online transaction method combining database sharding and dynamic multi-active switching further includes steps S31 to S33 in step S30:

[0098] Step S31: When there are multiple available data shards, obtain the current capacity of each available data shard.

[0099] It should be noted that when multiple available data shards exist in the business system, in order to ensure the even distribution of traffic and avoid excessive pressure on any one application or database, the current capacity of each available data shard is obtained. In this embodiment, the current capacity is used to reflect the number of transaction requests being processed by the transaction data shard.

[0100] In one feasible implementation, step S31 may further include steps E11 to E14:

[0101] Step E11: When there are multiple available data shards, obtain the transaction type of the transaction request.

[0102] Step E12: When the transaction type is a positive transaction, generate a duplicate verification request.

[0103] Step E13: Send the anti-duplicate verification request to the transaction application corresponding to each available data shard, so that each available data shard can return the anti-duplicate verification result according to the transaction application corresponding to each available data shard.

[0104] Step E14: When the anti-duplicate verification results returned by each available data shard are all preset results, obtain the current capacity of each available data shard.

[0105] It should be noted that when multiple available data shards exist and the transaction request is a forward transaction, anti-duplicate verification is required. In this case, an anti-duplicate verification request is generated based on the transaction request and sent to the transaction application corresponding to each available data shard. Each available data shard then provides a feedback on the anti-duplicate verification result based on the corresponding transaction application. In this embodiment, the anti-duplicate verification result includes two types: transaction found and no transaction found.

[0106] Understandably, if the anti-duplicate verification result returned by each available data shard is "no transaction can be found", it means that the anti-duplicate verification result returned by each available data shard is the preset result. At this time, it means that the anti-duplicate verification has passed. The current capacity of each available data shard is obtained, and a shard is randomly selected for transaction based on the current capacity of each available data shard.

[0107] In the specific implementation, when the transaction request is a related transaction, the related transaction needs to be broadcast to each available data shard. Based on the query results returned by each available data shard, a shard is selected from multiple available data shards for the transaction. Specifically: if an available data shard returns a query result indicating that a transaction has been found, then that available data shard will be used for the transaction; if no available data shard returns a query result indicating that a transaction has been found, then a shard is randomly selected for the transaction based on the current capacity of each available data shard.

[0108] It should be noted that for transactions in transit, reversal and query requests that originally occurred in the transaction application corresponding to the failed transaction data shard will respond abnormally and the transactions will be lost because there is no corresponding original transaction in the transaction application corresponding to the available data shard. If a transaction in transit occurs in transit in the failed application, the system cannot perform duplicate prevention, and the upstream system needs to use other means to implement duplicate prevention, sacrificing the reliability of the system's duplicate prevention in exchange for the system's stability.

[0109] Step S32: Determine the target data shard from among multiple available data shards based on the current capacity of each available data shard.

[0110] Step S33: Send the transaction request to the transaction application corresponding to the target data shard, so that the transaction application corresponding to the target data shard can process the transaction request.

[0111] It should be noted that, based on the current capacity of each available data shard, the available data shard with the lowest current capacity is selected as the target data shard. Transaction requests are then sent to the transaction application corresponding to the target data shard, and the transaction requests are processed by that application.

[0112] It is understandable that, such as Figure 6 As shown, when the hardware of transaction data shard 01 fails, transaction application 01 becomes unavailable. Only three applications, 02 to 04, remain available. Since the transaction application can be stateless and all four shards contain the basic data required to complete the transaction, customers can conduct transactions in any application and shard. Therefore, transaction requests are randomly distributed, and the uniformity of traffic distribution is ensured to avoid excessive pressure on any application or database.

[0113] This embodiment obtains the current capacity of each available data shard when multiple available data shards exist; determines the target data shard among the multiple available data shards based on the current capacity of each available data shard; and sends the transaction request to the transaction application corresponding to the target data shard, so that the transaction application corresponding to the target data shard can process the transaction request. Through this method, transaction losses are avoided, and customer experience and transaction success rate are guaranteed.

[0114] For example, to help understand the implementation process of the high-availability online transaction method combining database sharding and dynamic multi-active switching obtained by combining this embodiment with the above embodiment one, please refer to Figure 7 , Figure 7 A simplified flowchart illustrating a highly available online transaction method that combines database sharding and dynamic multi-active failover is provided. Specifically:

[0115] In this embodiment, the transaction initiator application maintains the state of the downstream system by starting a daemon thread in the background to continuously monitor the liveness of the downstream transaction application. Under normal circumstances, when all databases are online, a database sharding distribution mode is used; in the event of a single or multiple database failure, a fault random mode is adopted; within T1 (the maximum time interval between the query or reversal transaction and the original transaction) after a single or multiple database failure is recovered, a fault recovery mode is used; if all databases are available after T1, the system reverts to the database sharding distribution mode. This approach achieves the following advantages: 1. By using a database sharding deployment, under normal database conditions, routing can directly to the corresponding database shard. Duplicate prevention and finding the original transaction do not require searching multiple databases, eliminating redundant call chains, simplifying the application chain, and saving system resources. 2. Single point of failure is eliminated. When some databases fail, the system automatically switches to multi-active mode. Although there may be temporary transaction anomalies, it does not affect the normal operation of subsequent transactions. Although in multi-active mode, anti-duplicate and related transactions require simultaneous queries across multiple databases, resulting in significant call redundancy, this approach enhances system availability, optimizes customer experience under unstable cloud service conditions, minimizes transaction losses, and ensures transaction success rates. 3. The system automatically degrades and upgrades, accelerating response times without manual intervention, reducing transaction losses. 4. After fault recovery, a transition is performed using fault recovery mode before reverting to sharded distribution mode. Applications can automatically switch and determine their own actions, requiring no manual intervention and reducing operational burden. 5. Under normal conditions across all database shards, sharding mode ensures balanced transaction volume across each application and database shard, keeping the load within acceptable limits.

[0116] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the high-availability online transaction method combining database sharding and dynamic multi-active switching in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0117] This application also provides a highly available online transaction device that combines database sharding and dynamic multi-active failover. Please refer to [link / reference]. Figure 8 The high-availability online transaction device combining database sharding and dynamic multi-active switching includes:

[0118] Processing module 10 is used to respond to transaction requests and determine the business transaction mode based on the operating status of each transaction data sub-database.

[0119] The processing module 10 is further configured to determine at least one available data sub-database among multiple transaction data sub-databases when the business transaction mode is a fault random mode.

[0120] The processing module 10 is also used to process the transaction request according to the transaction application corresponding to the available data shard.

[0121] Optionally, the processing module 10 is further configured to:

[0122] When a transaction data shard is in a downtime state, the business transaction mode is determined to be the random fault mode; when all transaction data shards are in an online state within a preset historical time period, the business transaction mode is determined to be the shard distribution mode; when all transaction data shards are in an online state and there is a transaction data shard in a downtime state within a preset historical time period, the business transaction mode is determined to be the fault recovery mode.

[0123] Optionally, the processing module 10 is further configured to:

[0124] When multiple available data shards exist, the current capacity of each available data shard is obtained; based on the current capacity of each available data shard, a target data shard is determined among the multiple available data shards; the transaction request is sent to the transaction application corresponding to the target data shard, so that the transaction application corresponding to the target data shard processes the transaction request.

[0125] Optionally, the processing module 10 is further configured to:

[0126] When multiple available data shards exist, the transaction type of the transaction request is obtained; when the transaction type is a positive transaction, an anti-duplicate verification request is generated; the anti-duplicate verification request is sent to the transaction application corresponding to each available data shard, so that each available data shard can return the anti-duplicate verification result according to the transaction application corresponding to each available data shard; when the anti-duplicate verification results returned by each available data shard are all preset results, the current capacity of each available data shard is obtained.

[0127] Optionally, the processing module 10 is further configured to:

[0128] When the business transaction mode is the sharding distribution mode, the transaction identifier code of the transaction request is obtained; the target data shard is determined among multiple transaction data shards according to the sharding distribution rules and the transaction identifier code; the transaction request is sent to the transaction application corresponding to the target data shard so that the transaction application corresponding to the target data shard can process the transaction request.

[0129] Optionally, the processing module 10 is further configured to:

[0130] When the business transaction mode is fault recovery mode and the transaction request is a related transaction, the transaction request is broadcast so that each transaction data sub-database can provide transaction query results; based on the transaction query results provided by each transaction data sub-database, a target data sub-database is determined among multiple transaction data sub-databases; the transaction request is sent to the transaction application corresponding to the target data sub-database so that the transaction application corresponding to the target data sub-database can process the transaction request.

[0131] Optionally, the processing module 10 is further configured to:

[0132] Upon receiving a transaction request, the system obtains the operating status of the downstream user database; if the downstream user database is online, the system executes the step of determining the business transaction mode based on the operating status of each transaction data sub-database in response to the transaction request.

[0133] The high-availability online transaction apparatus combining database sharding and dynamic multi-active failover provided in this application, employing the high-availability online transaction method combining database sharding and dynamic multi-active failover in the above embodiments, can solve the technical problem in the prior art where, in a database sharding deployment, users stored in that database cannot perform transactions when a database shard goes down. Compared with the prior art, the beneficial effects of the high-availability online transaction apparatus combining database sharding and dynamic multi-active failover provided in this application are the same as those of the high-availability online transaction method combining database sharding and dynamic multi-active failover provided in the above embodiments, and other technical features in the high-availability online transaction apparatus combining database sharding and dynamic multi-active failover are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0134] This application provides a high-availability online transaction device that combines database sharding and dynamic multi-active switching. The high-availability online transaction device that combines database sharding and dynamic multi-active switching includes: at least one processor; and a memory communicatively connected to at least one processor; wherein the memory stores instructions that can be executed by at least one processor, and the instructions are executed by at least one processor to enable at least one processor to execute the high-availability online transaction method that combines database sharding and dynamic multi-active switching in the above embodiment 1.

[0135] The following is for reference. Figure 9This document illustrates a structural diagram of a highly available online transaction device suitable for implementing embodiments of this application, combining database sharding and dynamic multi-active switching. The highly available online transaction device combining database sharding and dynamic multi-active switching in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 9 The high-availability online transaction device combining database sharding and dynamic multi-active switching shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0136] like Figure 9 As shown, a high-availability online transaction processing device combining database sharding and dynamic multi-active switching may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the high-availability online transaction processing device combining database sharding and dynamic multi-active switching. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the highly available online trading equipment with database sharding and dynamic multi-active failover to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a highly available online trading equipment with database sharding and dynamic multi-active failover featuring various systems, it should be understood that implementing or having all of the systems shown is not required. More or fewer systems can be implemented alternatively.

[0137] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0138] The high-availability online transaction device combining database sharding and dynamic multi-active failover provided in this application, employing the high-availability online transaction method combining database sharding and dynamic multi-active failover in the above embodiments, can solve the technical problem in the prior art where, in a database sharding deployment, users stored in that database cannot perform transactions when a database shard goes down. Compared with the prior art, the beneficial effects of the high-availability online transaction device combining database sharding and dynamic multi-active failover provided in this application are the same as those of the high-availability online transaction method combining database sharding and dynamic multi-active failover provided in the above embodiments, and other technical features in this high-availability online transaction device combining database sharding and dynamic multi-active failover are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0139] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0140] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0141] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the high-availability online transaction method combining database sharding and dynamic multi-active switching in the above embodiments.

[0142] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0143] The aforementioned computer-readable storage medium may be included in a high-availability online transaction processing device that combines database sharding and dynamic multi-active switching; or it may exist independently and not be assembled into a high-availability online transaction processing device that combines database sharding and dynamic multi-active switching.

[0144] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a high-availability online transaction device that combines database sharding and dynamic multi-active switching, the high-availability online transaction device that combines database sharding and dynamic multi-active switching: responds to a transaction request by determining a business transaction mode based on the operating status of each transaction data shard; when the business transaction mode is a fault-random mode, it determines at least one available data shard among multiple transaction data shards; and processes the transaction request according to the transaction application corresponding to the available data shard.

[0145] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0146] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0147] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0148] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned high-availability online transaction method combining database sharding and dynamic multi-active switching. This solves the technical problem in existing database sharding deployments where users stored in a shard cannot conduct transactions when a shard fails. Compared to existing technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the high-availability online transaction method combining database sharding and dynamic multi-active switching provided in the above embodiments, and will not be elaborated upon here.

[0149] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the high-availability online transaction method combining database sharding and dynamic multi-active switching as described above.

[0150] The computer program product provided in this application can solve the technical problem in the prior art where, in a sharded deployment, users stored in that shard cannot conduct transactions when a shard goes down. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the highly available online transaction method combining sharding and dynamic multi-active switching provided in the above embodiments, and will not be repeated here.

[0151] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A highly available online transaction method combining database sharding and dynamic multi-active switching, characterized in that, The high-availability online transaction method combining database sharding and dynamic multi-active switching includes: In response to transaction requests, the business transaction mode is determined based on the operational status of each transaction data sub-database; When the business transaction mode is a random failure mode, at least one available data shard is determined from multiple transaction data shards. The transaction request is processed according to the transaction application corresponding to the available data shards; The steps for determining the business transaction mode based on the operational status of each transaction data sub-database include: When the operation status of the transaction data sharding database is down, the business transaction mode is determined to be the fault random mode; If all transaction data shards are online within a preset historical time period, the business transaction mode is determined to be the shard distribution mode. When all transaction data sub-databases are in an online state and there is a transaction data sub-database in an offline state during a preset historical time period, the business transaction mode is determined to be the fault recovery mode. Following the step of determining the business transaction mode based on the operational status of each transaction data shard in response to a transaction request, the method further includes: When the business transaction mode is the sharding and distribution mode, obtain the transaction identifier code of the transaction request; The target data shard is determined from multiple transaction data shards based on the sharding distribution rules and the transaction identifier code. The transaction request is sent to the transaction application corresponding to the target data shard, so that the transaction application corresponding to the target data shard can process the transaction request; Following the step of determining the business transaction mode based on the operational status of each transaction data shard in response to a transaction request, the method further includes: When the business transaction mode is fault recovery mode and the transaction request is a related transaction, the transaction request is broadcast so that each transaction data sub-database can return the transaction query results; The target data sub-database is determined from among multiple transaction data sub-databases based on the transaction query results fed back from each transaction data sub-database. The transaction request is sent to the transaction application corresponding to the target data shard, so that the transaction application corresponding to the target data shard can process the transaction request.

2. The method as described in claim 1, characterized in that, The step of processing the transaction request according to the transaction application corresponding to the available data sharding includes: When multiple available data shards exist, obtain the current capacity of each available data shard; The target data shard is determined from multiple available data shards based on the current capacity of each available data shard. The transaction request is sent to the transaction application corresponding to the target data shard, so that the transaction application corresponding to the target data shard can process the transaction request.

3. The method as described in claim 2, characterized in that, When multiple available data shards exist, the step of obtaining the current capacity of each available data shard includes: When multiple available data shards exist, the transaction type of the transaction request is obtained; When the transaction type is a positive transaction, a duplicate verification request is generated; Send the anti-duplicate verification request to the transaction application corresponding to each available data shard, so that each available data shard can return the anti-duplicate verification result according to the transaction application corresponding to each available data shard; When the anti-duplicate verification results returned by each available data shard are all preset results, obtain the current capacity of each available data shard.

4. The method according to any one of claims 1 to 3, characterized in that, Before the step of determining the business transaction mode based on the operating status of each transaction data sub-database in response to a transaction request, the method further includes: Upon receiving a transaction request, obtain the running status of the downstream user database; When the downstream user database is in an online state, the step of responding to the transaction request and determining the business transaction mode based on the operating status of each transaction data sub-database is executed.

5. A highly available online transaction device combining database sharding and dynamic multi-active switching, characterized in that, The high-availability online transaction device that combines database sharding and dynamic multi-active switching includes: The processing module is used to respond to transaction requests and determine the business transaction mode based on the operating status of each transaction data sub-database. The processing module is also used to determine at least one available data shard among multiple transaction data shards when the business transaction mode is a fault random mode. The processing module is also used to process the transaction request according to the transaction application corresponding to the available data sharding; The processing module is further configured to determine the business transaction mode as a fault random mode when the operating status of a transaction data shard is down; determine the business transaction mode as a shard distribution mode when the operating status of each transaction data shard is online within a preset historical time period; and determine the business transaction mode as a fault recovery mode when the operating status of each transaction data shard is online and the operating status of a transaction data shard is down within a preset historical time period. The processing module is further configured to: obtain the transaction identifier code of the transaction request when the business transaction mode is the sharding distribution mode; determine the target data sharding among multiple transaction data shardings according to the sharding distribution rules and the transaction identifier code; and send the transaction request to the transaction application corresponding to the target data sharding so that the transaction application corresponding to the target data sharding can process the transaction request. The processing module is further configured to broadcast the transaction request when the business transaction mode is fault recovery mode and the transaction request is a related transaction, so that each transaction data sub-database can provide transaction query results; determine the target data sub-database among multiple transaction data sub-databases based on the transaction query results provided by each transaction data sub-database; and send the transaction request to the transaction application corresponding to the target data sub-database so that the transaction application corresponding to the target data sub-database can process the transaction request.

6. A highly available online transaction processing device combining database sharding and dynamic multi-active switching, characterized in that, The high-availability online transaction device combining database sharding and dynamic multi-active switching includes: a memory, a processor, and a high-availability online transaction program combining database sharding and dynamic multi-active switching stored on the memory and executable on the processor. The high-availability online transaction program combining database sharding and dynamic multi-active switching is configured to implement the high-availability online transaction method combining database sharding and dynamic multi-active switching as described in any one of claims 1 to 4.

7. A storage medium, characterized in that, The storage medium stores a high-availability online transaction program that combines database sharding and dynamic multi-active switching. When the processor executes the high-availability online transaction program that combines database sharding and dynamic multi-active switching, it implements the high-availability online transaction method that combines database sharding and dynamic multi-active switching as described in any one of claims 1 to 4.

Images