Inventory consistency management method and device based on distributed transactions

Abstract

The invention relates to the technical field of distributed system transaction management, and discloses an inventory consistency management method and device based on distributed transactions, and the method comprises the following steps: pre-occupying an inventory, and recording the state information of the inventory to a Redis hash structure; after the inventory is pre-occupied successfully, generating a pre-deducted snapshot, generating a compensation identifier, and writing the pre-deducted snapshot and the compensation identifier into a MySQL transaction log together; verifying the uniqueness of the compensation identifier, and submitting the current database transaction after the uniqueness of the compensation identifier is confirmed; when the submission of the current database transaction fails, executing a compensation operation on the current database transaction; and after the compensation operation is executed, performing data consistency verification on the MySQL transaction log and the Redis hash structure. According to the method and the system, the consistency of inventory management during distributed transaction processing is highly guaranteed.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed system transaction management, and in particular to an inventory consistency management method and device based on distributed transactions. Background Art

[0002] With the prevalence of microservice architectures and distributed systems, inventory management is transitioning from traditional monolithic architectures to distributed ones. This presents challenges in coordinating transactions across multiple service nodes (such as order, inventory, and payment services). In scenarios like e-commerce and logistics, which require high concurrency, high availability, and data consistency, distributed transaction management has become a core challenge in ensuring business continuity. The centralized transaction mechanisms of traditional monolithic architectures struggle to adapt to distributed environments with network latency, node failures, and other challenges. This makes it difficult to ensure cross-service consistency for operations like inventory pre-orders, deductions, and rollbacks.

[0003] Existing technologies attempt to improve inventory management performance by combining Redis caching with databases (such as MySQL). This approach leverages Redis's high-performance atomic operations to handle inventory pre-orders and real-time deductions, while ensuring persistent consistency through database transactions. While this approach can improve system throughput, it suffers from a fundamental flaw: the lack of strong consistency between Redis operations and database transactions results in distributed transactions being fragmented into independent operations, failing to meet the atomicity and consistency requirements of the ACID signature.

[0004] In traditional solutions, such as MySQL, Redis operations are separated from database transactions. Network jitter or service crashes can lead to situations where "Redis deductions succeed but database commits fail" (overselling) or "database commits succeed but Redis updates fail" (underselling), causing discrepancies between book inventory and actual available inventory. During the pre-order phase, Redis may indicate sufficient inventory, but due to data being out of sync between the database and cache, verification fails during shipment, creating a "pre-order and shipment gap." This makes it difficult to ensure consistent inventory management, impacting overall system performance and user experience. Summary of the Invention

[0005] In view of this, the present application provides an inventory consistency management method and apparatus based on distributed transactions to solve the problem that the consistency of inventory management is difficult to ensure when processing distributed transactions.

[0006] In a first aspect, a distributed transaction-based inventory consistency management method is provided, which is applied to a distributed inventory consistency management platform. The method includes: Inventory is pre-occupied through Redis's first atomic operation, and inventory status information is recorded in the Redis hash structure. The status information includes the pre-occupied quantity, the remaining inventory quantity, and the version number. When inventory is successfully pre-occupied, a withholding snapshot is generated. The compensation identifier is generated based on the original business code, timestamp, host ID, and serial number in a predefined format. The withholding snapshot and the compensation identifier are written to the MySQL transaction log. The withholding snapshot contains all data before the inventory change. Use Redis distributed lock to verify the uniqueness of the compensation identifier. After confirming the uniqueness of the compensation identifier, commit the current database transaction. When the current database transaction fails to commit, the current database transaction is marked as incomplete. The unfinished records in the MySQL transaction log are scanned by the timing service, and compensation operations are performed on the current database transaction based on the withheld snapshot and compensation identifier. After the compensation operation is completed, the data consistency of the MySQL transaction log and the Redis hash structure is checked.

[0007] Through the above technical solution, by first pre-occupying inventory in Redis and recording the status information of the segmented inventory (pre-occupied quantity, remaining inventory quantity and version number), and then writing the associated withholding snapshot and compensation identifier in the MySQL transaction, the two-stage operation of "fast reading pre-occupation - slow writing storage" is combined. This not only ensures inventory responsiveness in high-concurrency scenarios, but also atomically binds business snapshots to transaction logs, realizing a strong association between pre-occupation and persistence operations, thereby taking into account both performance and transaction consistency in a distributed environment.

[0008] Optionally, the compensation identifier is generated by concatenating the original service code, timestamp, host identifier, and serial number in a predefined format, including: Perform hash operation on the original service code to obtain a service code of preset length; Get timestamps from the system clock or distributed clock synchronization service; Combine the device MAC address with the computer room number and generate a host ID through hash operation; Based on the Redis counter, it uses the timestamp as a prefix to generate a monotonically increasing sequence number according to the preset time window. The service code, timestamp, host identifier and sequence number are combined into a four-segment compensation identifier.

[0009] Through the above technical solution, by performing multi-layer hashing and time window auto-increment processing on the original business code, timestamp, host ID and serial number, and splicing a four-segment compensation identifier with verification, an identifier with high uniqueness, traceability and fast verification characteristics can be generated globally; this identifier can be used for idempotence control, and can also accurately locate the source of transactions in log auditing and fault diagnosis, significantly reducing the risk of duplicate execution in a distributed environment.

[0010] Optionally, using Redis distributed locks to verify the uniqueness of the compensation identifier includes: Obtain the distributed lock through Redis's second atomic operation; If the distributed lock is acquired successfully, read the execution status field of the compensation identifier in the MySQL transaction log; If the execution status field is in the completed state, release the distributed lock, intercept the request with the same compensation identifier, and return an idempotent success response; If the execution status field is in an unfinished state, the distributed lock is retained.

[0011] The above technical solution utilizes Redis's distributed locks to verify the uniqueness of compensation identifiers and differentiates between "completed" and "incompleted" states, achieving idempotent interception and secure flow continuation under multi-instance concurrent operations. This mechanism not only prevents duplicate submissions of the same compensation identifier but also ensures the correct release of distributed locks before and after transaction execution through lock lifecycle management, safeguarding transaction security and preventing resource leaks in concurrent scenarios.

[0012] Optionally, when the current database transaction fails to commit, marking the current database transaction as incomplete includes: Determine the exception type of the current database transaction through the exception classification dictionary table preset in the database, record the number of retries and the exception type, and the exception type includes recoverable exceptions and unrecoverable exceptions; When the exception type is recoverable, multiple retries are performed using the exponential backoff algorithm; When the exception type is unrecoverable, the retried request is terminated through the circuit breaker and the current database transaction is marked as incomplete.

[0013] Through the above technical solution, a preset exception classification dictionary is introduced to subdivide exceptions when transaction submission fails into "recoverable" and "unrecoverable" categories, and transactions are graded and marked and subsequently processed accordingly. This design enables the system to automatically select a retry or fast failure strategy for different failure sources, maximizing the transaction success rate while avoiding ineffective retries for permanent business errors, thereby improving the system's availability and fault isolation capabilities.

[0014] Optionally, when the exception type is recoverable, multiple retries are performed using an exponential backoff algorithm, including: Preset the initial retry interval, maximum retry interval, and maximum number of retries; After the first retry is performed, the retry interval is increased exponentially until the maximum retry interval is reached; When the number of retries exceeds the preset retry threshold, the retried request is terminated through the circuit breaker and the current database transaction is marked as incomplete; When the retry succeeds, the retry counter is reset to zero and the exception type and number of retries are written to the MySQL transaction log.

[0015] Through the above technical solution, an exponential backoff algorithm is implemented for recoverable exceptions, and the retry rhythm is dynamically adjusted according to the preset initial interval, maximum interval, and maximum number of retries. After reaching the threshold, the circuit breaker mechanism is used to force termination, which can effectively balance fast recovery and overload protection. This strategy not only uses short-term retries to tolerate transient faults, but also degrades in time in the event of high concurrency or continuous faults, reducing system pressure and ensuring overall stability.

[0016] Optionally, performing compensation operations based on the withholding snapshot and the compensation identifier includes: Retrieve incomplete transactions from the MySQL transaction log. Based on the withholding snapshot content, a compensation task entity is constructed. The compensation task entity includes the target inventory ID, pre-withholding status data, compensation type, and trigger time. Compensation types include Redis pre-occupancy rollback and MySQL data compensation. When the compensation type is Redis pre-occupancy rollback, for the pre-occupied quantity that needs to be released, the remaining inventory quantity is restored to the pre-occupation value in the snapshot record through the first atomic operation, and the version number in Redis is updated to the version number recorded in the snapshot; When the compensation type is MySQL data compensation, if the transaction commits successfully but the target inventory is not deducted, the target inventory is deducted based on the withholding snapshot content. Each compensation operation records the compensation result, actual change amount, and execution time in the compensation log table.

[0017] The above technical solution builds compensation task entities based on uncompleted transaction records and executes rollback or deduction operations on both Redis and MySQL, achieving bidirectional compensation for inconsistent inventory levels. Whether releasing excess inventory in Redis or correcting undeducted or improperly deducted inventory in MySQL, the compensation process is traceable, auditable, and idempotent at the task level, significantly enhancing business recovery capabilities.

[0018] Optional data consistency verification based on the MySQL transaction log and the Redis hash structure includes: Extract inventory changes from MySQL transaction logs and atomic operation logs from Redis hash structures; Divide inventory changes and atomic operation logs into preset time windows by timestamp; Compare the accumulated pre-occupied or released increments in the Redis hash structure within each time window with the total inventory change within the same time window. If the deviation in any window exceeds the preset threshold, Redis preemption rollback or MySQL data compensation is performed based on the withheld snapshot.

[0019] The above technical solution, through parallel grouping and cumulative comparison of MySQL transaction logs and Redis atomic operation logs by time window, can accurately locate inventory deviations in high-concurrency environments and automatically trigger secondary compensation when anomalies exceeding thresholds are detected. This verification mechanism ensures eventual consistency across the entire chain, preempting potential risks of "false availability" or "inventory leakage" into the automated detection and compensation process, ensuring the system maintains high accuracy and reliability of inventory data even in extreme scenarios.

[0020] In a second aspect of the present application, an inventory consistency management system based on distributed transactions is provided, comprising an inventory pre-occupancy module, a snapshot generation module, a distributed lock verification module, a compensation execution module, and a data verification module, wherein: An inventory pre-occupancy module is configured to pre-occupy inventory through the first atomic operation of Redis and record inventory status information to the Redis hash structure, the status information including the pre-occupied quantity, the remaining inventory quantity and the version number; A snapshot generation module is configured to generate a withholding snapshot after inventory pre-occupancy is successful, generate a compensation identifier based on the original business code, timestamp, host ID, and serial number in a predefined format, and write the withholding snapshot and the compensation identifier into the MySQL transaction log. The withholding snapshot contains all data before the inventory change; The distributed lock verification module is configured to use the Redis distributed lock to verify the uniqueness of the compensation identifier. After confirming the uniqueness of the compensation identifier, the current database transaction is committed; The compensation execution module is configured to mark the current database transaction as incomplete when the current database transaction fails to be committed, scan the incomplete records in the MySQL transaction log through the timer service, and perform compensation operations on the current database transaction based on the withheld snapshot and the compensation identifier; The data verification module is configured to perform data consistency verification on the MySQL transaction log and the Redis hash structure after the compensation operation is completed.

[0021] In the third aspect of the present application, an electronic device is provided, including a processor, a memory, a user interface and a network interface, the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory so that the electronic device performs any of the methods described above.

[0022] In a fourth aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores instructions. When the instructions are executed, any one of the methods described above is executed.

[0023] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: The present invention first pre-occupies inventory and records the status information of the segmented inventory (pre-occupied quantity, remaining inventory quantity and version number) in Redis, and then writes the associated withholding snapshot and compensation identifier in the MySQL transaction. This combines the two-stage operations of "fast reading pre-occupation and slow writing into the warehouse", which not only ensures the inventory responsiveness in high-concurrency scenarios, but also atomically binds the business snapshot with the transaction log, realizing a strong association between pre-occupation and persistence operations, thereby taking into account both performance and transaction consistency in a distributed environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is an exemplary system architecture diagram of an inventory consistency management method based on distributed transactions or an inventory consistency management system based on distributed transactions of the present application; Figure 2 This is a flow chart of an inventory consistency management method based on distributed transactions in an embodiment of the present application; Figure 3 This is a module diagram of an inventory consistency management system based on distributed transactions in an embodiment of the present application; Figure 4 It is a structural diagram of an electronic device disclosed in an application embodiment.

[0025] Explanation of the accompanying drawings: 100, system architecture; 101, first terminal device; 102, second terminal device; 103, third terminal device; 104, network; 105, server; 301, inventory pre-occupation module; 302, snapshot generation module; 303, distributed verification module; 304, compensation execution module; 305, data verification module; 401, processor; 402, communication bus; 403, user interface; 404, network interface; 405, memory. DETAILED DESCRIPTION

[0026] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments.

[0027] In the description of the embodiments of this application, words such as "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "for example" or "for instance" in the embodiments of this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "for example" or "for instance" is intended to present the relevant concepts in a concrete manner.

[0028] In the description of the embodiments of the present application, the term "multiple" means two or more. For example, multiple systems refer to two or more systems, and multiple screen terminals refer to two or more screen terminals. In addition, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0029] This embodiment discloses a method and device for inventory consistency management based on distributed transactions. Figure 1 A schematic diagram of an exemplary system architecture of an embodiment of an inventory consistency management method based on distributed transactions or an inventory consistency management system based on distributed transactions to which the present application can be applied is shown.

[0030] like Figure 1 As shown, system architecture 100 may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. Network 104 is a medium for providing communication links between terminal devices 101, 102, 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0031] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as model training applications, video recognition applications, web browser applications, social platform software, etc.

[0032] Terminal devices 101, 102, and 103 can be hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with display screens, including but not limited to smartphones, tablet computers, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III, Moving Picture Experts Group Audio Layer 3) players, MP4 (Moving Picture Experts Group Audio Layer IV, Moving Picture Experts Group Audio Layer 4) players, laptop computers, and desktop computers, etc. When terminal devices 101, 102, and 103 are software, they can be installed in the electronic devices listed above. They can be implemented as multiple software or software modules (for example, multiple software or software modules used to provide distributed services), or they can be implemented as a single software or software module. No specific limitation is made here.

[0033] When terminals 101, 102, and 103 are hardware, they may also be equipped with a video capture device. The video capture device may be any device capable of capturing video, such as a camera, a sensor, and the like. Users can use the video capture device on terminals 101, 102, and 103 to capture video.

[0034] The server 105 may be a server that provides various services, such as a background server that processes data displayed on the terminal devices 101, 102, and 103. The background server may analyze and process the received data, and may feed back the processing results (e.g., recognition results) to the terminal device.

[0035] It should be noted that a server can be either hardware or software. When a server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When a server is software, it can be implemented as multiple software programs or software modules (for example, multiple software programs or software modules used to provide distributed services), or as a single software program or software module. This is not specifically limited here.

[0036] It should be understood that Figure 1 The number of terminal devices, networks, and servers in the above description is merely illustrative. Any number of terminal devices, networks, and servers may be used as needed. In particular, if target data does not need to be acquired remotely, the above system architecture may not include a network, but may instead include only terminal devices or servers.

[0037] Figure 2 This is a flow chart of an inventory consistency management method based on distributed transactions disclosed in an embodiment of the present application. Figure 2As shown, this embodiment includes: Step S201: pre-occupy the inventory through the first atomic operation of Redis, and record the inventory status information into the Redis hash structure. The status information includes the pre-occupied quantity, the remaining inventory quantity and the version number.

[0038] For example, when a user submits a flash sale order, the system triggers the inventory pre-order logic; Use Redis's first atomic operation (e.g., using the HINCRBY instruction to execute an atomic operation) to pre-empt the inventory, with the key being seckill:stock:product_id (product ID, such as 1001). For example, each time you place an order, if you execute HINCRBY seckill: stock: 1001 reserved_stock 1, the reserved_stock (reserved quantity) is initially 0, and the reserved quantity is increased by 1. If you execute HINCRBY seckill: stock: 1001 total_stock - 1, the total_stock (remaining quantity in stock) is initially 1000, and the remaining quantity in stock is reduced by 1 to 999. Version: Initially V1, execute SET seckill:stock:1001:versionV2 for each operation (version increment is achieved through GETSET); Use Redis transactions (MULTI / EXEC) to ensure that all updates to the three fields succeed or fail. If total_stock ≥ 0, the reservation is successful and the order ID is returned; if total_stock < 0, the reservation fails and insufficient stock is returned; The inventory status information after pre-occupancy is stored in the Redis hash structure: {reserved_stock: 1, total_stock: 999, version: V1}.

[0039] Step S202: When the inventory is successfully pre-occupied, a withholding snapshot is generated. A compensation identifier is generated according to the original business code, timestamp, host identifier, and serial number in a predefined format. The withholding snapshot and the compensation identifier are written into the MySQL transaction log. The withholding snapshot contains all data before the inventory change.

[0040] For example, the state before reservation is captured: inventory total_stock=1000, reserved_stock=0, version number version=V1, and the withholding snapshot is generated as: {product_id: 1001, total_stock: 1000, reserved_stock: 0, version: V1}; Write the withholding snapshot to the snapshot_log table in the MySQL transaction log and associate it with the snapshot ID (snapshot_id=SNAP202505231400). Hash the original business code "SECKILL_ORDER" to "SKO_1234"; The timestamp is rounded to "202505231400" (minute level); Host ID: MAC address hash + data center ID "IDC_A_01"; The Redis counter generates the sequence number "0001"; Spliced ​​into compensation identifier: SKO_1234-202505231400-IDC_A_01-0001; Write the compensation identifier to the transaction_log table in the MySQL transaction log: {compensation_id: SKO_1234-202505231400-IDC_A_01-0001}.

[0041] Step S203: Use the Redis distributed lock to verify the uniqueness of the compensation identifier. After confirming the uniqueness of the compensation identifier, commit the current database transaction.

[0042] For example, a distributed lock is obtained through the Redis SETNX instruction: SETNX lock: SKO_1234-202505231400-IDC_A_01-0001 “LOCKED” EX 30; If 0 is returned (lock acquisition failed), it means that the compensation identifier has been processed and the current request is intercepted; If 1 is returned (lock acquisition is successful), it means that the compensation identifier is unique and the compensation operation is allowed; Then query the status field (status) corresponding to the compensate_id in the transaction_log table; If the status field is 'COMPLETED', immediately execute DEL lock: SKO_1234-202505231400-IDC_A_01-0001 "LOCKED" EX 30 to release the lock and return an idempotent success response; If the status field is not completed ('PENDING'), continue to execute the MySQL transactions of order creation and actual inventory deduction, and finally update the status field to completed in the same transaction.

[0043] Step S204: When the current database transaction fails to be committed, the current database transaction is marked as incomplete, the incomplete records in the MySQL transaction log are scanned by the timing service, and a compensation operation is performed on the current database transaction based on the withheld snapshot and the compensation identifier.

[0044] For example, if a database transaction fails to be submitted due to a network timeout, the exception type is "network timeout" (recoverable exception), which is recorded in the exception_classification table; Update the status field in the transaction_log table to incomplete; The timer service scans and finds an unfinished transaction in the status field. It obtains the MySQL transaction log of the current transaction based on the compensation identifier, obtains the withholding snapshot by obtaining the snapshot_log table in the MySQL transaction log, and performs a Redis preemption rollback based on the withholding snapshot: Release the reserved stock by issuing the command HINCRBY seckill:stock:1001 reserved_stock -1; Restore the remaining stock by commanding HINCRBY seckill:stock:1001 total_stock 1; After the Redis preemption rollback is completed, the status field of the transaction is updated to completed.

[0045] Step S205: After the compensation operation is completed, a data consistency check is performed on the MySQL transaction log and the Redis hash structure.

[0046] For example, obtain the data of the Redis hash structure: seckill: stock: 1001 reserved_stock = 50 (unpaid pre-occupancy), total_stock = 950; Get data from the MySQL transaction log: inventory: available_stock = 950, order_detail.locked_stock = 50; Perform consistency check on the data in the Redis hash structure and the data in the MySQL transaction log: Based on statistics in a 5-minute window, the Redis pre-occupancy increment is 1000 times, the total MySQL deduction is 950 times (50 unpaid releases), and the deviation is 0. The returned data is consistent. If Redistotal_stock = 940 and MySQL = 950 (deviation = 10), trigger MySQL deduction: UPDATEinventory SET available_stock = 940 WHERE product_id = 1001.

[0047] Optionally, the compensation identifier is generated by concatenating the original service code, timestamp, host identifier, and serial number in a predefined format, including: Perform hash operation on the original service code to obtain a service code of preset length; Get timestamps from the system clock or distributed clock synchronization service; Combine the device MAC address with the computer room number and generate a host ID through hash operation; Based on the Redis counter, it uses the timestamp as a prefix to generate a monotonically increasing sequence number according to the preset time window. The service code, timestamp, host identifier and sequence number are combined into a four-segment compensation identifier.

[0048] For example, the original business code "SECKILL_ORDER" is hashed with SHA-256 to obtain the first 8 digits: SKO_1234; Get the timestamp from the system clock: 202505231400 (current minute); Host ID: The MAC address 00:1A:2B:3C:4D:5E and the computer room number "01" are hashed to form IDC_A_01. The Redis counter generates the sequence number "0001" within that minute; The above acquired data are combined to obtain the final identifier: SKO_1234-202505231400-IDC_A_01-0001.

[0049] Optionally, using Redis distributed locks to verify the uniqueness of the compensation identifier includes: Obtain the distributed lock through Redis's second atomic operation; If the distributed lock is acquired successfully, read the execution status field of the compensation identifier in the MySQL transaction log; If the execution status field is in the completed state, release the distributed lock, intercept the request with the same compensation identifier, and return an idempotent success response; If the execution status field is in an unfinished state, the distributed lock is retained.

[0050] For example, a distributed lock is acquired through the second atomic operation of Redis (e.g., an atomic operation performed through the SET instruction): SET lock: SKO_1234-202505231400-IDC_A_01-0001 "locked" NX EX 30, where NX is set only when the key does not exist (atomicity), and EX 30 is the lock expiration time of 30 seconds (to prevent deadlock); First request: Returns 1 (lock acquisition successful), indicating that the compensation identifier is unique and the compensation operation is allowed; Repeat request: Returns 0 (the lock already exists and acquisition fails), indicating that the compensation identifier has been processed and the current request is intercepted; When the first request to acquire the lock succeeds, query the status field corresponding to the compensate_id in the transaction_log table; If the status field is Completed, immediately execute DEL lock: SKO_1234-202505231400-IDC_A_01-0001 “LOCKED” EX 30 to release the lock, intercept subsequent requests with the same compensation identifier and return an idempotent success response; If the Status field is Incomplete, continue executing the MySQL transactions for order creation and actual inventory deduction, and finally update the Status field to Completed in the same transaction; When the lock is acquired successfully and the node crashes during transaction processing (the lock is not released), Redis automatically releases the lock after 30 seconds and rolls back the incomplete transaction that has timed out, releasing the reserved inventory.

[0051] Optionally, when the current database transaction fails to commit, marking the current database transaction as incomplete includes: Determine the exception type of the current database transaction through the exception classification dictionary table preset in the database, record the number of retries and the exception type, and the exception type includes recoverable exceptions and unrecoverable exceptions; When the exception type is recoverable, multiple retries are performed using the exponential backoff algorithm; When the exception type is unrecoverable, the retried request is terminated through the circuit breaker and the current database transaction is marked as incomplete.

[0052] For example, an abnormal classification dictionary table is pre-designed: The database table exception_classification has the following structure: Field Name type Example Value illustrate exception_code VARCHAR(10) E001 Exception code exception_class VARCHAR(255) java.net.SocketTimeoutException Exception class name is_recoverable TINYINT(1) 1 Is it recoverable (1=yes, 0=no) description TEXT Network timeout Exception description for example: exception_code exception_class is_recoverable description E001 java.net.SocketTimeoutException 1 Network timeout E003 org.springframework.dao.DuplicateKeyException 0 Key conflict When transaction commit times out due to MySQL master-slave switchover (exception type: E001, recoverable); The system throws a SocketTimeoutException, which is identified as a recoverable exception by matching the exception class name to the exception_classification table. Start exponential backoff retry: Set the initial parameters base_delay=500ms, max_retries=3, max_delay=30s, where base_delay is the initial time interval, max_retries is the maximum number of retries, and max_delay is the maximum retry interval.

[0053] When a user submits the same order repeatedly, resulting in a unique key conflict for order_id (Exception type: E003, unrecoverable); MySQL throws a DuplicateKeyException, which matches the exception_classification table and is identified as an unrecoverable exception. The service is marked as "unavailable" through the Hystrix circuit breaker, and the same request within 30 seconds is rejected. The prompt "The order has been submitted. Do not repeat the operation" is returned. Marks the current transaction status as incomplete.

[0054] Optionally, when the exception type is recoverable, multiple retries are performed using an exponential backoff algorithm, including: Preset the initial retry interval, maximum retry interval, and maximum number of retries; After the first retry is performed, the retry interval is increased exponentially until the maximum retry interval is reached; When the number of retries exceeds the preset retry threshold, the retried request is terminated through the circuit breaker and the current database transaction is marked as incomplete; When the retry succeeds, the retry counter is reset to zero and the exception type and number of retries are written to the MySQL transaction log.

[0055] For example, when a transaction commit times out due to a MySQL master-slave switch (exception type: E001, recoverable); The system throws a SocketTimeoutException, which is identified as a recoverable exception by matching the exception class name to the exception_classification table. Start exponential backoff retry: set initial parameters base_delay=500ms, max_delay=30s, max_retries=3, and exponential factor to 2 (retry interval = base_delay×2 n-1 , n represents the nth retry), where base_delay is the initial time interval, max_delay is the maximum retry interval, and max_retries is the maximum number of retries; After triggering the exponential backoff retry, wait 500ms before starting the retry. Record the retry log: retry_log (compensation_id, retry_count, delay, exception_type) is (SKO_1234-202505231400-IDC_A_01-0001, 1, 500, TIMEOUT); If the retry fails after waiting for 500ms, then fails again after waiting for 1000ms, and succeeds after waiting for 2000ms, the counter retry_count is reset to 0 and the transaction status is marked as completed.

[0056] If the third retry still fails, the service is marked as "unavailable" through the Hystrix circuit breaker, the same request within the next 30 seconds is rejected, and the transaction status is marked as incomplete.

[0057] Optionally, performing compensation operations based on the withholding snapshot and the compensation identifier includes: Retrieve incomplete transactions from the MySQL transaction log. Based on the withholding snapshot content, a compensation task entity is constructed. The compensation task entity includes the target inventory ID, pre-withholding status data, compensation type, and trigger time. Compensation types include Redis pre-occupancy rollback and MySQL data compensation. When the compensation type is Redis pre-occupancy rollback, for the pre-occupied quantity that needs to be released, the remaining inventory quantity is restored to the pre-occupation value in the snapshot record through the first atomic operation, and the version number in Redis is updated to the version number recorded in the snapshot; When the compensation type is MySQL data compensation, if the transaction commits successfully but the target inventory is not deducted, the target inventory is deducted based on the withholding snapshot content. Each compensation operation records the compensation result, actual change amount, and execution time in the compensation log table.

[0058] For example, the timer service scans the transaction_log table for transaction records marked as incomplete every 5 minutes; Return the withholding snapshot {product_id: 1001, total_stock: 1000, reserved_stock: 0, version: V1} and obtain the product ID, inventory quantity, reserved inventory quantity, and version number before withholding. The compensation task entity is constructed as follows: {target inventory ID, pre-withholding status data, compensation type, trigger time}; When the compensation type is Redis preemption rollback, the Redis first atomic operation is executed (for example, the atomic operation is executed through the HINCRBY instruction): By executing the command HINCRBY seckill:stock:1001 total_stock 1, the original remaining stock quantity is restored from 999 to the pre-occupied stock quantity of 1000 by adding 1; By executing the command HINCRBY seckill:stock:1001 reserved_stock -1, the reserved stock quantity is reduced by 1 and restored to the reserved stock quantity before reservation, which is 0; By executing the command SET seckill:stock:1001:version V1, the version number is rolled back to V1 recorded in the snapshot; Verify inventory consistency: If the command GET seckill:stock:1001:total_stock is executed, the return value is 1000, which is equal to the inventory quantity before the reservation, 1000; If the return value of GET seckill:stock:1001:reserved_stock is 0, which is equal to the reserved stock quantity 0 before the reservation, the reservation rollback is executed successfully.

[0059] If the transaction is successfully submitted but the inventory is not deducted, MySQL data compensation is executed: the pre-deduction inventory quantity of 1000 in the withholding snapshot is deducted by 1 to obtain the compensated inventory quantity of 999; The compensation log compensation_log (compensation_id, type, result, change_qty, execution_time) is recorded as (SKO_1234-202505231400-IDC_A_01-0001, MYSQL_COMPENSATION, SUCCESS, 1, 2025-05-26 15:15:00). Update the status of the transaction with successful compensation to completed.

[0060] Optional data consistency verification based on the MySQL transaction log and the Redis hash structure includes: Extract inventory changes from MySQL transaction logs and atomic operation logs from Redis hash structures; Divide inventory changes and atomic operation logs into preset time windows by timestamp; Compare the accumulated pre-occupied or released increments in the Redis hash structure within each time window with the total inventory change within the same time window. If the deviation in any window exceeds the preset threshold, Redis preemption rollback or MySQL data compensation is performed based on the withheld snapshot.

[0061] For example, the change amount of completed transactions in the transaction_log table of the MySQL transaction log is obtained. For example, if there are 1000 records in total, the actual deduction amount is 990; Get all operation logs for product 1001 in Redis, such as 1000 pre-occupied operations and 10 release operations, with a net pre-occupied increment of 990.

[0062] Divide all data within an hour into 12 5-minute time windows. Place the changes in completed transactions in the MySQL transaction log and the operation log for item 1001 in Redis into the corresponding time windows. Compare the data within each time window. If the data in the window between 10:25 and 10:30 is abnormal (for example, Redis reserves an increment of 200, while MySQL actually deducts 190, resulting in a deviation of 10), a compensation action is triggered. The query of the withholding snapshot found a snapshot of an unfinished transaction. The inventory before withholding was 800 and after withholding was 799. Then the Redis withholding rollback was executed (CHECK_202505271025, REDIS_ROLLBACK, 2025-05-2710:25:00, 2025-05-2710:30:00, 200, 190, 10, SUCCESS). After completing the Redis pre-occupancy rollback, perform a final check: HGET seckill:stock:1001 total_stock returns remaining stock 10; HGET seckill:stock:1001 reserved_stock returns reserved_stock 0.

[0063] If the current inventory in MySQL is 10 and the reserved quantity is 0, the verification is returned as complete.

[0064] Figure 3This is a module diagram of an inventory consistency management system based on distributed transactions in an embodiment of the present application. Figure 3 As shown, the system includes: an inventory pre-occupation module 301, a snapshot generation module 302, a distributed lock verification module 303, a compensation execution module 304 and a data verification module 305, wherein: The inventory pre-occupancy module 301 is configured to pre-occupy inventory through the first atomic operation of Redis and record inventory status information to the Redis hash structure, where the status information includes the pre-occupied quantity, the remaining inventory quantity, and the version number; The snapshot generation module 302 is configured to generate a withholding snapshot after the inventory is successfully pre-occupied, generate a compensation identifier based on the original business code, timestamp, host identifier, and serial number in a predefined format, and write the withholding snapshot and the compensation identifier into the MySQL transaction log. The withholding snapshot contains all data before the inventory change; The distributed lock verification module 303 is configured to verify the uniqueness of the compensation identifier using the Redis distributed lock, and commit the current database transaction after confirming the uniqueness of the compensation identifier; The compensation execution module 304 is configured to mark the current database transaction as incomplete when the current database transaction fails to be committed, scan the incomplete records in the MySQL transaction log through the timing service, and perform a compensation operation on the current database transaction based on the withheld snapshot and the compensation identifier; The data verification module 305 is configured to perform data consistency verification on the MySQL transaction log and the Redis hash structure after the compensation operation is completed.

[0065] Optionally, the snapshot generation module 302 is further configured to: Perform hash operation on the original service code to obtain a service code of preset length; Get timestamps from the system clock or distributed clock synchronization service; Combine the device MAC address with the computer room number and generate a host ID through hash operation; Based on the Redis counter, it uses the timestamp as a prefix to generate a monotonically increasing sequence number according to the preset time window. The service code, timestamp, host identifier and sequence number are combined into a four-segment compensation identifier.

[0066] Optionally, the distributed lock verification module 303 is further configured to: Obtain the distributed lock through Redis's second atomic operation; If the distributed lock is acquired successfully, read the execution status field of the compensation identifier in the MySQL transaction log; If the execution status field is in the completed state, release the distributed lock, intercept the request with the same compensation identifier, and return an idempotent success response; If the execution status field is in an unfinished state, the distributed lock is retained.

[0067] Optionally, the compensation execution module 304 is further configured to: Determine the exception type of the current database transaction through the exception classification dictionary table preset in the database, record the number of retries and the exception type, and the exception type includes recoverable exceptions and unrecoverable exceptions; When the exception type is recoverable, multiple retries are performed using the exponential backoff algorithm; When the exception type is unrecoverable, the retried request is terminated through the circuit breaker and the current database transaction is marked as incomplete.

[0068] Optionally, the compensation execution module 304 is further configured to: Preset the initial retry interval, maximum retry interval, and maximum number of retries; After the first retry is performed, the retry interval is increased exponentially until the maximum retry interval is reached; When the number of retries exceeds the preset retry threshold, the retried request is terminated through the circuit breaker and the current database transaction is marked as incomplete; When the retry succeeds, the retry counter is reset to zero and the exception type and number of retries are written to the MySQL transaction log.

[0069] Optionally, the compensation execution module 304 is further configured to: Retrieve incomplete transactions from the MySQL transaction log. Based on the withholding snapshot content, a compensation task entity is constructed. The compensation task entity includes the target inventory ID, pre-withholding status data, compensation type, and trigger time. Compensation types include Redis pre-occupancy rollback and MySQL data compensation. When the compensation type is Redis pre-occupancy rollback, for the pre-occupied quantity that needs to be released, the remaining inventory quantity is restored to the pre-occupation value in the snapshot record through the first atomic operation, and the version number in Redis is updated to the version number recorded in the snapshot; When the compensation type is MySQL data compensation, if the transaction commits successfully but the target inventory is not deducted, the target inventory is deducted based on the withholding snapshot content. Each compensation operation records the compensation result, actual change amount, and execution time in the compensation log table.

[0070] Optionally, the data verification module 305 is further configured to: Extract inventory changes from MySQL transaction logs and atomic operation logs from Redis hash structures; Divide inventory changes and atomic operation logs into preset time windows by timestamp; Compare the accumulated pre-occupied or released increments in the Redis hash structure within each time window with the total inventory change within the same time window. If the deviation in any window exceeds the preset threshold, Redis preemption rollback or MySQL data compensation is performed based on the withheld snapshot.

[0071] It should be noted that the above embodiments provide systems that implement their functions using only the division of the above functional modules as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0072] This embodiment also discloses an electronic device, referring to Figure 4 The electronic device may include: at least one processor 401 , at least one communication bus 402 , a user interface 403 , a network interface 404 , and at least one memory 405 .

[0073] The communication bus 402 is used to implement the connection and communication between these components.

[0074] The user interface 403 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 403 may also include a standard wired interface and a wireless interface.

[0075] The network interface 404 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).

[0076] Processor 401 may include one or more processing cores. Using various interfaces and circuits, processor 401 connects to various components within the server. It executes instructions, programs, code sets, or instruction sets stored in memory 405, as well as accesses data stored in memory 405, to perform various server functions and process data. Optionally, processor 401 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). Processor 401 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing content displayed on the display screen; and the modem handles wireless communications. It is understood that the modem may also be implemented independently of the processor 401 and implemented as a separate chip.

[0077] Among them, the memory 405 may include a random access memory (RAM) or a read-only memory (Read-Only Memory). Optionally, the memory 405 includes a non-transitory computer-readable storage medium. The memory 405 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 405 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 405 may also be optionally at least one storage device located away from the aforementioned processor 401. As Figure 4 As shown, the memory 405 as a computer storage medium may include an operating system, a network communication module, a user interface module, and an application program of an inventory consistency management method based on distributed transactions.

[0078] exist Figure 4In the electronic device shown, the user interface 403 is mainly used to provide an input interface for the user and obtain data input by the user; and the processor 401 can be used to call an application stored in the memory 405 that stores an inventory consistency management method based on distributed transactions. When executed by one or more processors 401, the electronic device executes one or more methods in the above embodiments.

[0079] It should be noted that for the aforementioned method embodiments, for simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required for this application.

[0080] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0081] In the several embodiments provided in this application, it should be understood that the disclosed devices can be implemented in other ways. For example, the device embodiments described above are merely schematic, such as the division of units, which is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some service interface, and the indirect coupling or communication connection of devices or units can be electrical or other forms.

[0082] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0083] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0084] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of this application, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 405 and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the method of this application. The aforementioned memory 405 includes various media that can store program code, such as a USB flash drive, a mobile hard drive, a magnetic disk, or an optical disk.

[0085] The above is only an exemplary embodiment of the present disclosure and cannot be used to limit the scope of the present disclosure. That is, any equivalent changes and modifications made according to the teachings of the present disclosure are still within the scope of the present disclosure. After considering the disclosure of the specification, those skilled in the art will easily think of other embodiments of the present disclosure. This application is intended to cover any variations, uses or adaptive changes of the present disclosure, which follow the general principles of the present disclosure and include common knowledge or customary technical means in the technical field that are not recorded in the present disclosure. The description and examples are to be regarded as exemplary only, and the scope and spirit of the present disclosure are defined by the claims.

Claims

1. A method for inventory consistency management based on distributed transactions, characterized in that: Applied to a distributed inventory consistency management platform, the method includes: Pre-occupy the inventory through the first atomic operation of Redis, and record the status information of the inventory to the Redis hash structure, wherein the status information includes the pre-occupied quantity, the remaining quantity in the inventory, and the version number; When the inventory is pre-occupied successfully, a withholding snapshot is generated, and a compensation identifier is generated according to the original business code, timestamp, host identifier and serial number in a predefined format. The withholding snapshot and the compensation identifier are written into the MySQL transaction log. The withholding snapshot contains all data before the inventory change. Use the Redis distributed lock to verify the uniqueness of the compensation identifier, and after confirming the uniqueness of the compensation identifier, commit the current database transaction; When the current database transaction fails to be committed, marking the current database transaction as incomplete, scanning the incomplete records in the MySQL transaction log by a timing service, and performing a compensation operation on the current database transaction based on the withheld snapshot and the compensation identifier; After the compensation operation is completed, a data consistency check is performed on the MySQL transaction log and the Redis hash structure.

2. The method according to claim 1, characterized in that The generating of the compensation identifier by splicing the original service code, timestamp, host identifier and serial number in a predefined format includes: Performing a hash operation on the original service code to obtain a service code of a preset length; Get timestamps from the system clock or distributed clock synchronization service; Combine the device MAC address with the computer room number and generate a host ID through hash operation; Based on the Redis counter and with the timestamp as a prefix, a monotonically increasing sequence number is generated according to a preset time window; The service code, the timestamp, the host identifier, and the serial number are combined into a four-segment compensation identifier.

3. The method according to claim 1, characterized in that The verifying the uniqueness of the compensation identifier by using the Redis distributed lock includes: Acquire a distributed lock through the second atomic operation of Redis; If the distributed lock is acquired successfully, read the execution status field of the compensation identifier in the MySQL transaction log; If the execution status field is in the completed state, release the distributed lock, intercept the request with the same compensation identifier and return an idempotent success response; If the execution status field is in an unfinished state, the distributed lock is retained.

4. The method according to claim 1, wherein When the current database transaction fails to be committed, marking the current database transaction as incomplete includes: Determine the exception type of the current database transaction by using an exception classification dictionary table preset in the database, record the number of retries and the exception type, where the exception type includes recoverable exceptions and unrecoverable exceptions; When the exception type is the recoverable exception, performing multiple retries using an exponential backoff algorithm; When the exception type is the unrecoverable exception, the retry request is terminated through a fuse, and the current database transaction is marked as incomplete.

5. The method according to claim 4, characterized in that When the exception type is the recoverable exception, performing multiple retries using an exponential backoff algorithm includes: Preset the initial retry interval, maximum retry interval, and maximum number of retries; After the first retry is performed, the retry interval is increased exponentially until the maximum retry interval is reached; When the number of retries exceeds a preset retry threshold, the retry request is terminated through the fuse, and the current database transaction is marked as incomplete; When the retry succeeds, the retry counter is reset to zero, and the exception type and the number of retries are written into the MySQL transaction log.

6. The method according to claim 1, characterized in that The performing of the compensation operation based on the withholding snapshot and the compensation identifier includes: Retrieving transactions in an incomplete state from the MySQL transaction log; Construct a compensation task entity based on the withholding snapshot content. The compensation task entity includes the target inventory identifier, pre-withholding status data, compensation type, and trigger time. The compensation type includes Redis pre-occupancy rollback and MySQL data compensation. When the compensation type is the Redis pre-occupancy rollback, for the pre-occupancy quantity that needs to be released, the remaining inventory quantity is restored to the pre-occupancy value in the snapshot record through the first atomic operation, and the version number in Redis is updated to the version number recorded in the snapshot; When the compensation type is the MySQL data compensation, if the transaction is successfully submitted but the target inventory is not deducted, the target inventory is deducted according to the withholding snapshot content. Each compensation operation records the compensation result, actual change amount and execution time in the compensation log table.

7. The method according to claim 1, characterized in that The data consistency check based on the MySQL transaction log and the Redis hash structure includes: Extracting the inventory change amount in the MySQL transaction log and the atomic operation log in the Redis hash structure; Dividing the inventory change amount and the atomic operation log into a preset time window according to the timestamp; Compare the accumulated increments of pre-occupied or released data in the Redis hash structure during each time window with the total inventory change during the same time window; If the deviation in any window exceeds a preset threshold, the Redis pre-occupancy rollback or the MySQL data compensation is performed according to the withheld snapshot.

8. An inventory consistency management system based on distributed transactions, characterized in that: It includes an inventory pre-occupancy module, a snapshot generation module, a distributed lock verification module, a compensation execution module, and a data verification module, among which: The inventory pre-occupancy module is configured to pre-occupy inventory through a first atomic operation of Redis, and record status information of the inventory to a Redis hash structure, wherein the status information includes the pre-occupied quantity, the remaining quantity in inventory, and the version number; The snapshot generation module is configured to generate a withholding snapshot after the inventory is successfully pre-occupied, generate a compensation identifier based on the original business code, timestamp, host identifier and serial number in a predefined format, and write the withholding snapshot and the compensation identifier into the MySQL transaction log, wherein the withholding snapshot includes all data before the inventory change; The distributed lock verification module is configured to verify the uniqueness of the compensation identifier using the Redis distributed lock, and commit the current database transaction after confirming the uniqueness of the compensation identifier; The compensation execution module is configured to, when the current database transaction fails to be committed, mark the current database transaction as incomplete, scan the incomplete records in the MySQL transaction log through a timing service, and perform a compensation operation on the current database transaction based on the withheld snapshot and the compensation identifier; The data verification module is configured to perform data consistency verification on the MySQL transaction log and the Redis hash structure after the compensation operation is completed.

9. An electronic device, characterized in that: The electronic device comprises a processor, a memory, a user interface and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory so that the electronic device executes the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, and when the instructions are executed, the method according to any one of claims 1 to 7 is executed.

Images