A method and device for managing inventory consistency based on distributed transactions

Abstract

The application relates to the technical field of distributed system transaction management, and discloses a kind of inventory consistency management method and device based on distributed transaction, method includes the following steps: pre-occupy to inventory, the state information of inventory is recorded to Redis hash structure;When pre-occupy inventory successfully, generate pre-deduct snapshot, generate compensation identifier, and pre-deduct snapshot is written into MySQL transaction log together with compensation identifier;The uniqueness of compensation identifier is checked, after confirming the uniqueness of compensation identifier, the current database transaction is submitted;When the current database transaction fails, compensation operation is executed to the current database transaction;When compensation operation is executed, data consistency check is carried out to MySQL transaction log and Redis hash structure.The application has higher guarantee effect on the consistency of inventory management when processing distributed transaction.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of distributed system transaction management, and particularly relates to a stock consistency management method and device based on a distributed transaction. BACKGROUND

[0002] With the popularity of microservice architecture and distributed systems, stock management is transforming from traditional monolithic architecture to distributed architecture, facing the problem of transaction coordination between multiple service nodes (such as order, stock, and payment services). In e-commerce, logistics, and other scenarios with high concurrency, high availability, and strict data consistency requirements, distributed transaction management has become a core challenge to ensure business continuity. The centralized transaction mechanism under the traditional monolithic architecture cannot adapt to the network delay and node failure problems in the distributed environment, making it difficult to guarantee the cross-service consistency of stock pre-occupancy, deduction, and rollback operations.

[0003] The prior art attempts to improve stock management performance by combining Redis cache and a database (such as MySQL), using Redis's high-performance atomic operations to handle stock pre-occupancy and real-time deduction, and using database transactions to ensure persistent consistency. Although this type of solution can improve system throughput, it has a fundamental flaw: the lack of strong consistency between Redis operations and database transactions, which causes distributed transactions to be fragmented into independent operations, failing to meet the atomicity and consistency requirements of the ACID characteristics.

[0004] In the traditional solution, Redis operations are separated from database transactions (such as MySQL), and network jitter or service crashes may result in "Redis deduction success but database commit failure" (overselling) or "database commit success but Redis update failure" (underselling), causing the stock account and actual available quantity to deviate; in the pre-occupancy phase, Redis shows that the stock is sufficient, but because the database and cache data are not synchronized, the final out-of-stock verification fails, forming a "pre-occupied and out-of-stock fault". This makes it difficult to guarantee the consistency of stock management, affecting the overall performance and user experience of the system. SUMMARY

[0005] Therefore, the present application provides a stock consistency management method and device based on a distributed transaction to solve the problem of difficult guarantee of stock management consistency when handling distributed transactions.

[0006] In a first aspect, a stock consistency management method based on a distributed transaction is provided, applied to a distributed stock consistency management platform, the method comprising:

[0007] Pre-occupy the stock through a first atomic operation of Redis, and record the state information of the stock to a Redis hash structure, the state information including the pre-occupied quantity, the remaining quantity of the stock, and a version number;

[0008] When the inventory pre-occupancy is successful, a pre-deduction snapshot is generated, a compensation identifier is generated by splicing according to the original business code, a timestamp, a host identifier and a serial number in a pre-defined format, and the pre-deduction snapshot and the compensation identifier are written into a MySQL transaction log, the pre-deduction snapshot contains all data before the inventory change;

[0009] The uniqueness of the compensation identifier is verified by using a Redis distributed lock, and after confirming the uniqueness of the compensation identifier, the current database transaction is submitted;

[0010] When the current database transaction fails to be submitted, the current database transaction is marked as unfinished, the unfinished records in the MySQL transaction log are scanned by a timing service, and a compensation operation is performed on the current database transaction based on the pre-deduction snapshot and the compensation identifier;

[0011] When the compensation operation is completed, data consistency verification is performed on the MySQL transaction log and the Redis hash structure.

[0012] Through the above technical solutions, the inventory pre-occupancy is first performed in Redis and the state information (pre-occupied quantity, inventory remaining quantity and version number) of the segmented inventory is recorded, and then the associated pre-deduction snapshot and compensation identifier are written into the MySQL transaction, the two-stage operation of "fast pre-occupancy and slow writing to the database" is combined, which not only guarantees the inventory response performance in a high-concurrency scenario, but also atomically binds the business snapshot and the transaction log, realizes the strong association between pre-occupation and persistent operation, and thus balances the performance and transaction consistency in a distributed environment.

[0013] Optionally, the compensation identifier is generated by splicing according to the original business code, a timestamp, a host identifier and a serial number in a pre-defined format, including:

[0014] Hashing the original business code to obtain a business code of a preset length;

[0015] The timestamp is obtained by a system clock or a distributed clock synchronization service;

[0016] The host identifier is generated by combining the device MAC address and the machine room number and performing a hash operation;

[0017] Based on the Redis counter, and prefixed with the timestamp, a monotonically increasing serial number is generated within a preset time window;

[0018] The business code, the timestamp, the host identifier and the serial number are combined into a four-segment compensation identifier.

[0019] By the above technical solution, through multi-layer hashing and time window self-increment processing of the original service code, timestamp, host identifier and sequence number, and splicing the four-segment compensation identifier with verification, an identifier with high uniqueness, traceability and fast verification characteristics can be generated in the global range; the identifier can be used for idempotency control, and can also accurately locate the transaction source in log audit and fault diagnosis, significantly reducing the risk of repeated execution in a distributed environment.

[0020] Optionally, the uniqueness of the compensation identifier is verified by using a Redis distributed lock, including:

[0021] obtaining a distributed lock through a second atomic operation of Redis;

[0022] if the distributed lock is successfully obtained, reading the execution state field of the compensation identifier in the MySQL transaction log;

[0023] if the execution state field is in a completed state, releasing the distributed lock, intercepting a request identical to the compensation identifier, and returning an idempotent success response;

[0024] if the execution state field is in an uncompleted state, retaining the distributed lock.

[0025] Through the above technical solution, the uniqueness of the compensation identifier is verified by using the distributed lock of Redis, and different processing is performed between the "completed" and "uncompleted" states, realizing idempotent interception and safe flow continuation under multi-instance concurrent operation. This mechanism not only avoids repeated submission of the same compensation identifier, but also ensures correct release of the distributed lock before and after transaction execution through lock life cycle management, ensuring transaction safety and resource leakage in a concurrent scenario.

[0026] Optionally, when the current database transaction fails, the current database transaction is marked as uncompleted, including:

[0027] determining the exception type of the current database transaction through a preset exception classification dictionary table in the database, recording the retry count and the exception type, and the exception type includes a recoverable exception and an unrecoverable exception;

[0028] when the exception type is a recoverable exception, performing multiple retries through an exponential backoff algorithm;

[0029] when the exception type is an unrecoverable exception, terminating the request for retry through a fuse, and marking the current database transaction as an uncompleted state.

[0030] By the above technical scheme, the preset abnormal classification dictionary is introduced, the abnormality when the transaction is submitted is subdivided into two categories of "recoverable" and "unrecoverable", and the transaction is marked and processed according to the classification; the design enables the system to automatically select the retry or fast failure strategy for different fault sources, maximizes the transaction success rate while avoiding invalid retries for permanent business errors, and improves the availability and fault isolation capability of the system.

[0031] Optionally, when the abnormal type is a recoverable abnormality, the multiple retries are performed by an exponential backoff algorithm, including:

[0032] A preset initial retry interval, a maximum retry interval and a maximum retry number are set;

[0033] After the first retry is performed, the retry interval is increased exponentially until the maximum retry interval is reached;

[0034] When the retry number exceeds a preset retry number threshold, the request is terminated by a fuse, and the current database transaction is marked as an unfinished state;

[0035] When the retry is successful, the retry counter is reset to zero, and the abnormal type and the retry number are written into the MySQL transaction log.

[0036] By the above technical scheme, the exponential backoff algorithm is implemented for the recoverable abnormality, the retry rhythm is dynamically adjusted according to the preset initial interval, maximum interval and maximum retry number, and the fuse mechanism is used to forcibly terminate when the threshold is reached, which can effectively balance the fast recovery and overload protection; this strategy not only tolerates transient faults by short-term retries, but also degrades in time under high concurrency or continuous faults, reduces system pressure and guarantees overall stability.

[0037] Optionally, the compensation operation is performed based on the pre-deducted snapshot and the compensation identifier, including:

[0038] An unfinished transaction is retrieved from the MySQL transaction log;

[0039] According to the pre-deducted snapshot content, a compensation task entity is constructed, the compensation task entity includes a target inventory identifier, pre-deducted state data, a compensation type and a trigger time, and the compensation type includes Redis pre-occupation rollback and MySQL data compensation;

[0040] When the compensation type is Redis pre-occupation rollback, the remaining inventory quantity is restored to the pre-occupation value in the snapshot record by a first atomic operation for the pre-occupied quantity to be released, and the version number in Redis is updated to the version number recorded in the snapshot;

[0041] When the compensation type is MySQL data compensation, if the transaction is successfully committed but the target inventory is not deducted, the deduction is performed on the target inventory according to the pre-deduction snapshot content, and the compensation result, the actual change amount and the execution time are recorded to the compensation log table in each compensation operation.

[0042] Through the above technical solution, the compensation task entity is constructed based on the unfinished transaction record, and the rollback or pre-deduction operation is respectively executed at the two ends of Redis and MySQL, thereby realizing the bidirectional compensation for the inconsistent state of pre-occupation and database storage. Whether the excessive pre-occupied quantity in Redis is released or the inventory in MySQL which is not deducted or improperly deducted is corrected, the traceability, auditability and idempotent execution of the compensation process are guaranteed at the task level, and the business recovery capability is greatly enhanced.

[0043] Optionally, the data consistency check according to the MySQL transaction log and the Redis hash structure comprises:

[0044] extracting the inventory change amount in the MySQL transaction log and the atomic operation log in the Redis hash structure;

[0045] dividing the inventory change amount and the atomic operation log into preset time windows according to the time stamp;

[0046] comparing the accumulated pre-occupied or released increment in the Redis hash structure in each time window with the total inventory change amount in the same time window;

[0047] if the deviation in any window exceeds the preset threshold, performing Redis pre-occupation rollback or MySQL data compensation according to the pre-deduction snapshot.

[0048] Through the above technical solution, the MySQL transaction log and the Redis atomic operation log are grouped and accumulated in parallel according to the time window, and the inventory quantity deviation in the high-concurrency environment can be accurately located, and the secondary compensation is automatically triggered when the threshold value exception is found. The verification mechanism realizes the final consistency guarantee of the whole link, and the potential "false availability" or "inventory leakage" risk is pre-positioned in the automatic detection and compensation process, so that the system can also maintain high accuracy and reliability of inventory data in extreme scenarios.

[0049] In a second aspect of the present application, an inventory consistency management system based on distributed transactions is provided, comprising an inventory pre-occupation module, a snapshot generation module, a distributed lock verification module, a compensation execution module and a data verification module, wherein:

[0050] The inventory pre-occupation module is configured to pre-occupy the inventory through the first atomic operation of Redis, and record the state information of the inventory to the Redis hash structure, the state information including the pre-occupied quantity, the remaining quantity of the inventory and the version number.

[0051] The snapshot generation module is configured to generate a pre-deduction snapshot after the inventory pre-occupancy is successful, splice a compensation identifier according to the original business code, a timestamp, a host identifier and a serial number in a pre-defined format, and write the pre-deduction snapshot and the compensation identifier into a MySQL transaction log.

[0052] The distributed lock verification module is configured to verify the uniqueness of the compensation identifier by using a Redis distributed lock, and submit the current database transaction after confirming the uniqueness of the compensation identifier.

[0053] The compensation execution module is configured to mark the current database transaction as unfinished when the current database transaction fails to be submitted, scan the unfinished records in the MySQL transaction log by using a timing service, and perform a compensation operation on the current database transaction based on the pre-deduction snapshot and the compensation identifier.

[0054] The data verification module is configured to perform data consistency verification on the MySQL transaction log and a Redis hash structure after the compensation operation is completed.

[0055] In a 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 configured to store instructions, the user interface and the network interface are configured to communicate with other devices, and the processor is configured to execute the instructions stored in the memory to enable the electronic device to perform the method according to any one of the preceding aspects.

[0056] In a fourth aspect of the present application, a computer readable storage medium is provided, and the computer readable storage medium stores instructions, when the instructions are executed, the method according to any one of the preceding aspects is performed.

[0057] In summary, the one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages:

[0058] In the present application, the inventory pre-occupancy is first performed in Redis, and the state information (pre-occupied quantity, inventory remaining quantity and version number) of the segmented inventory is recorded, then the associated pre-deduction snapshot and compensation identifier are written in the MySQL transaction, the two-stage operation of "fast pre-occupancy - slow writing to the database" is combined, the inventory response performance in a high-concurrency scenario is ensured, the business snapshot and the transaction log are atomically bound, the strong association between the pre-occupancy and the persistent operation is realized, and thus the performance and the transaction consistency are considered in the distributed environment. BRIEF DESCRIPTION OF DRAWINGS

[0059] Figure 1is an exemplary system architecture diagram of applying a kind of inventory consistency management method based on distributed transaction or a kind of inventory consistency management system based on distributed transaction in the present application;

[0060] Figure 2 is a flow schematic diagram of a kind of inventory consistency management method based on distributed transaction in the embodiment of the present application;

[0061] Figure 3 is a module schematic diagram of a kind of inventory consistency management system based on distributed transaction in the embodiment of the present application;

[0062] Figure 4 is a structural schematic diagram of an electronic device disclosed in the embodiment of the application.

[0063] Figure legend: 100, system architecture;101, first terminal device;102, second terminal device;103, third terminal device;104, network;105, server;301, inventory pre-occupancy 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

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

[0065] In the description of the embodiments of the present application, the words such as "for example" or "for instance" are used to represent an example, illustration or description. Any embodiment or design scheme described as "for example" or "for instance" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words such as "for example" or "for instance" are intended to present the relevant concept in a specific way.

[0066] In the description of the embodiments of the present application, the term "a plurality of" means two or more. For example, a plurality of systems means two or more systems, and a plurality of screen terminals means two or more screen terminals. In addition, the terms "first" and "second" are used for descriptive purposes only, and should not be interpreted as indicating or implying relative importance or implicitly indicating the indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more features. The terms "include", "contain", "have" and their variants mean "include but are not limited to", unless otherwise specifically emphasized.

[0067] The embodiment discloses a distributed transaction-based inventory consistency management method and device, Figure 1 An exemplary system architecture diagram of an embodiment of a distributed transaction-based inventory consistency management method or a distributed transaction-based inventory consistency management system to which the present application can be applied is shown.

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

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

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

[0071] When the terminal devices 101, 102, 103 are hardware, a video capture device can also be installed thereon. The video capture device can be various devices capable of capturing video, such as a camera, a sensor, etc. A user can use the video capture device on the terminal devices 101, 102, 103 to capture video.

[0072] The server 105 can be a server providing various services, such as a background server for processing data displayed on the terminal devices 101, 102, and 103. The background server can perform analysis and the like on received data, and can feed back a processing result (such as a recognition result) to the terminal device.

[0073] It should be noted that the server can be hardware or software. When the server is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software or software modules (such as multiple software or software modules for providing distributed services), or as a single software or software module. No specific limitation is made herein.

[0074] It should be understood that Figure 1 The number of terminal devices, networks, and servers in the system architecture is merely illustrative. Any number of terminal devices, networks, and servers can be provided according to implementation needs. In particular, in the case where target data does not need to be acquired from a remote location, the above system architecture can not include a network, but only include a terminal device or a server.

[0075] Figure 2 is a flowchart of a method for inventory consistency management based on a distributed transaction disclosed by an embodiment of the present application, as shown in Figure 2 The embodiment includes the following steps:

[0076] In step S201, the first atomic operation of Redis is used to preoccupy the inventory, and the state information of the inventory is recorded to the Redis hash structure. The state information includes the preoccupied quantity, the remaining quantity of the inventory, and the version number.

[0077] For example, when a user submits a seckill order, the system triggers the inventory preoccupation logic.

[0078] The first atomic operation of Redis (such as an atomic operation performed by using the HINCRBY instruction) is used to preoccupy the inventory, and the key is seckill:stock:product_id (product ID, such as 1001).

[0079] For example, HINCRBY seckill:stock:1001 reserved_stock 1 is executed each time an order is placed, the reserved_stock (preoccupied quantity) is initially 0, the preoccupied quantity is increased by 1, HINCRBY seckill:stock:1001 total_stock-1 is executed, the total_stock (remaining quantity of the inventory) is initially 1000, and the remaining quantity of the inventory is reduced by 1 to 999.

[0080] version (version number): initially V1, each operation executes SET seckill: stock: 1001: version V2 (version increment through GETSET);

[0081] Ensure that the update operation of the three fields is either all successful or all failed through Redis transaction (MULTI / EXEC);

[0082] If total_stock≥0, the pre-occupation is successful, and the order ID is returned; if total_stock<0, the pre-occupation fails, and the insufficient stock is returned.

[0083] The stock state information after the pre-occupation is executed is stored in the Redis hash structure: {reserved_stock: 1, total_stock: 999, version: V1}.

[0084] Step S202, when the stock pre-occupation is successful, a pre-deduction snapshot is generated, a compensation identifier is generated according to the original business code, timestamp, host identifier and sequence number in a pre-defined format, and the pre-deduction snapshot and the compensation identifier are written into the MySQL transaction log, and the pre-deduction snapshot contains all the data before the stock change.

[0085] Exemplarily, the pre-occupation state is captured: stock total_stock=1000, pre-occupation quantity reserved_stock=0, version number version=V1, and the pre-deduction snapshot is generated: {product_id: 1001, total_stock: 1000, reserved_stock: 0, version: V1};

[0086] The pre-deduction snapshot is written into the snapshot_log table in the MySQL transaction log, and the snapshot ID (snapshot_id=SNAP202505231400) is associated;

[0087] The original business code "SECKILL_ORDER" is hashed as "SKO_1234";

[0088] The timestamp is rounded to "202505231400" (minute level);

[0089] Host identifier: MAC address hash + machine room number "IDC_A_01";

[0090] Redis counter generates sequence number "0001";

[0091] Spliced into a compensation identifier: SKO_1234-202505231400-IDC_A_01-0001;

[0092] Write the compensation identifier into the transaction_log table in the MySQL transaction log: {compensation_id: SKO_1234-202505231400-IDC_A_01-0001}.

[0093] Step S203, the uniqueness of the compensation identifier is verified by using the Redis distributed lock, and after confirming the uniqueness of the compensation identifier, the current database transaction is submitted.

[0094] Exemplarily, the distributed lock is obtained through the SETNX instruction of Redis: SETNX lock:SKO_1234-202505231400-IDC_A_01-0001 “LOCKED” EX 30;

[0095] If 0 is returned (lock acquisition fails), it means that the compensation identifier has been processed, and the current request is intercepted;

[0096] If 1 is returned (lock acquisition succeeds), it means that the compensation identifier is unique, and the compensation operation is allowed to be executed;

[0097] Then query the status field (status) corresponding to the compensate_id in the transaction_log table;

[0098] If the status field is completed (‘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;

[0099] If the status field is not completed (‘PENDING’), continue to execute the order creation and real inventory deduction MySQL transaction, and finally update the status field to completed in the same transaction.

[0100] Step S204, when the current database transaction fails, mark the current database transaction as not completed, and scan the uncompleted records in the MySQL transaction log through the timing service, and execute the compensation operation on the current database transaction based on the pre-deduction snapshot and the compensation identifier.

[0101] Exemplarily, the database transaction fails due to network timeout, and the exception type is “network timeout” (recoverable exception), which is recorded to the exception_classification table;

[0102] Update the status field in the transaction_log table to not completed;

[0103] The timing service scans the transaction whose state field is not completed, acquires the MySQL transaction log of the current transaction according to the compensation identifier, acquires the pre-deduction snapshot from the snapshot_log table in the MySQL transaction log, and executes Redis pre-occupation rollback according to the pre-deduction snapshot:

[0104] The instruction HINCRBY seckill:stock:1001 reserved_stock -1 is used to release the pre-occupied amount;

[0105] The instruction HINCRBY seckill:stock:1001 total_stock 1 is used to restore the remaining inventory;

[0106] After the Redis pre-occupation rollback is completed, the state field of the transaction is updated to completed.

[0107] In step S205, after the compensation operation is executed, the data consistency of the MySQL transaction log and the Redis hash structure is checked.

[0108] For example, the data of the Redis hash structure is obtained: seckill:stock:1001 reserved_stock=50 (unpaid pre-occupation), total_stock=950;

[0109] The data in the MySQL transaction log is obtained: inventory:available_stock=950, order_detail.locked_stock=50;

[0110] The consistency of the data of the Redis hash structure and the data in the MySQL transaction log is checked:

[0111] According to the 5-minute window statistics, the Redis pre-occupation increment=1000 times, the MySQL total deduction=950 times (50 times of unpaid release), the deviation=0, and the data is consistent.

[0112] If Redistotal_stock=940, MySQL=950 (deviation=10), trigger MySQL compensation deduction: UPDATEinventory SET available_stock=940 WHERE product_id=1001.

[0113] Optionally, the compensation identifier is generated by splicing according to the original business code, timestamp, host identifier, and sequence number in a pre-defined format, including:

[0114] Perform a hash operation on the original business code to obtain a business code of a preset length;

[0115] Obtain the timestamp through the system clock or distributed clock synchronization service;

[0116] The device's MAC address is combined with the data center number, and a host identifier is generated through a hash operation.

[0117] Based on a Redis counter, and prefixed with a timestamp, a monotonically increasing sequence number is generated according to a preset time window;

[0118] The business code, timestamp, host identifier, and serial number are combined into a four-segment compensation identifier.

[0119] For example, the first 8 bits of the original business code "SECKILL_ORDER" are hashed using SHA-256: SKO_1234;

[0120] Get the timestamp via the system clock: 202505231400 (current minute);

[0121] Host identifier: The hash of the combination of MAC address 00:1A:2B:3C:4D:5E and the data center number "01" is IDC_A_01;

[0122] The Redis counter generates the sequence number "0001" within this minute;

[0123] The data obtained above are combined to obtain the final identifier: SKO_1234-202505231400-IDC_A_01-0001.

[0124] Optionally, using Redis distributed locks to verify the uniqueness of the compensation identifier includes:

[0125] Acquire a distributed lock through Redis's second atomic operation;

[0126] If the distributed lock is successfully acquired, read the execution status field of the compensation identifier from the MySQL transaction log;

[0127] If the execution status field indicates a completed state, release the distributed lock, intercept requests with the same compensation identifier, and return an idempotent success response.

[0128] If the execution status field is incomplete, the distributed lock is retained.

[0129] Exemplarily, a distributed lock is acquired through a second atomic operation of Redis (such as performing an atomic operation through a SET instruction): SET lock:SKO_1234-202505231400-IDC_A_01-0001 "locked" NX EX 30, wherein NX is set only when the key does not exist (atomicity), and EX 30 is a lock expiration time of 30 seconds (to prevent a deadlock);

[0130] First request: return 1 (lock acquisition success), indicating that the compensation identifier is unique, and the compensation operation is allowed to be performed;

[0131] Repeated request: return 0 (lock already exists, acquisition fails), indicating that the compensation identifier has been processed, and the current request is intercepted;

[0132] When the first request acquires the lock successfully, the state field corresponding to the compensate_id in the transaction_log table is queried;

[0133] If the state field is completed, the lock is immediately released through DEL lock:SKO_1234-202505231400-IDC_A_01-0001 "LOCKED" EX 30, and the subsequent request with the same compensation identifier is intercepted and a idempotent success response is returned;

[0134] If the state field is not completed, the order creation and real inventory deduction MySQL transaction are continued to be executed, and finally the state field is updated to completed in the same transaction;

[0135] When the lock is acquired successfully and the node crashes during transaction processing (the lock is not released), the Redis automatically releases the lock after 30 seconds, and a rollback is performed on the timeout transaction that is not completed, and the pre-occupied inventory is released.

[0136] Optionally, when the current database transaction fails to be submitted, the current database transaction is marked as not completed, including:

[0137] The type of the exception of the current database transaction is determined through a preset exception classification dictionary table in the database, the number of retries and the type of the exception are recorded, and the type of the exception includes a recoverable exception and an unrecoverable exception;

[0138] When the type of the exception is the recoverable exception, multiple retries are performed through an exponential backoff algorithm;

[0139] When the type of the exception is the unrecoverable exception, the request for retry is terminated through a fuse, and the current database transaction is marked as not completed.

[0140] Exemplarily, an exception classification dictionary table is designed in advance:

[0141] The database table exception_classification has the following structure:

[0142] Field Name Type Example Value Description exception_code VARCHAR(10) E001 Exception Code exception_class VARCHAR(255) java.net.SocketTimeoutException Exception Class Name is_recoverable TINYINT(1) 1 Is Recoverable (1 = Yes, 0 = No) description TEXT Exception Description exception_code

[0143] For example:

[0144] exception_class is_recoverable description java.net.SocketTimeoutException E001 Network Timeout 1 org.springframework.dao.DuplicateKeyException E003 Duplicate Key 0 Figure 3

[0145] When a transaction commit times out due to a MySQL master-slave switch (exception type: E001, recoverable);

[0146] The system throws a SocketTimeoutException, which is matched with the exception_classification table to identify it as a recoverable exception;

[0147] Start exponential backoff retry: set the initial parameters base_delay=500ms, max_retries=3, and 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.

[0148] When a user repeatedly submits the same order, causing a unique key conflict for order_id (exception type: E003, non-recoverable);

[0149] MySQL throws a DuplicateKeyException, which is matched with the exception_classification table to identify it as a non-recoverable exception;

[0150] Mark the service as "unavailable" through the Hystrix circuit breaker, reject subsequent requests within 30s, and return a prompt: "Order has been submitted, please do not repeat the operation";

[0151] Mark the current transaction state as incomplete.

[0152] Optionally, when the exception type is a recoverable exception, perform multiple retries through the exponential backoff algorithm, including:

[0153] Set the initial retry interval, maximum retry interval, and maximum number of retries;

[0154] After the first retry, increase the retry interval exponentially until the maximum retry interval is reached;

[0155] When the number of retries exceeds the preset retry threshold, terminate the retry request through the circuit breaker and mark the current database transaction as incomplete;

[0156] When the retry is successful, the retry counter is reset to zero, and the exception type and the number of retries are written to the MySQL transaction log.

[0157] For example, when the transaction commit times out due to MySQL master-slave switching (exception type: E001, recoverable);

[0158] The system throws SocketTimeoutException, which is matched with the exception_classification table through the exception class name, and is identified as a recoverable exception;

[0159] Start exponential backoff retry: set the initial parameters base_delay=500ms, max_delay=30s, max_retries=3, and the exponential factor is set 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;

[0160] After triggering the exponential backoff retry, wait for 500ms and then start the retry, and record the retry log: retry_log (compensation_id, retry_count, delay, exception_type) as (SKO_1234-202505231400-IDC_A_01-0001, 1, 500, TIMEOUT);

[0161] If waiting for 500ms fails, then waiting for 1000ms also fails, and waiting for 2000ms succeeds, reset the counter retry_count to 0, and mark the transaction state as completed.

[0162] If the third retry still fails, mark the service as "unavailable" through the Hystrix circuit breaker, reject the same request within the next 30s, and mark the transaction state as incomplete.

[0163] Optionally, the compensation operation based on the pre-deducted snapshot and the compensation identifier includes:

[0164] Retrieve the transaction in an incomplete state from the MySQL transaction log;

[0165] According to the pre-deducted snapshot content, build a compensation task entity, which includes target inventory identifier, pre-deducted state data, compensation type and trigger time, and the compensation type includes Redis pre-occupation rollback and MySQL data compensation;

[0166] When the compensation type is Redis pre-occupation rollback, the remaining inventory quantity is restored to the pre-occupation value in the snapshot record through a first atomic operation for the pre-occupied quantity that needs to be released, and the version number in Redis is updated to the version number recorded in the snapshot.

[0167] When the compensation type is MySQL data compensation, if the transaction is successfully submitted but the target inventory is not deducted, the target inventory is deducted according to the pre-deduction snapshot content, and the compensation result, actual change amount and execution time are recorded to the compensation log table.

[0168] Exemplarily, the timing service scans the transaction_log table every 5 minutes for transaction records with a state flag of unfinished;

[0169] The pre-deduction snapshot {product_id: 1001, total_stock: 1000, reserved_stock: 0, version: V1} is returned, and the pre-occupation product ID, inventory quantity, pre-occupied inventory quantity and version number are obtained;

[0170] The compensation task entity is constructed as: {target inventory identifier, pre-deduction state data, compensation type, trigger time};

[0171] When the compensation type is Redis pre-occupation rollback, a first atomic operation of Redis is executed (such as an atomic operation through a HINCRBY instruction);

[0172] The original inventory remaining quantity is increased by 1 to restore to the pre-occupation inventory quantity 1000 through the execution of the instruction HINCRBY seckill: stock: 1001 total_stock 1;

[0173] The pre-occupied inventory quantity is reduced by 1 to restore to the pre-occupation pre-occupied inventory quantity 0 through the execution of the instruction HINCRBY seckill: stock: 1001 reserved_stock -1;

[0174] The rollback version number is rolled back to V1 of the snapshot record through the execution of the instruction SET seckill: stock: 1001: version V1;

[0175] Verify inventory consistency:

[0176] If the return value of the execution instruction GET seckill: stock: 1001: total_stock is 1000, which is equal to the pre-occupation inventory quantity 1000;

[0177] The return value of GET seckill: stock: 1001: eserved_stock is 0, which is equal to the pre-occupied inventory quantity 0 before pre-occupation, indicating that the pre-occupation rollback is executed successfully.

[0178] When the transaction is successfully committed but the inventory is not deducted, MySQL data compensation is executed: the pre-deducted inventory quantity 1000 in the pre-deducted snapshot is deducted by 1 to obtain the compensated inventory quantity 999;

[0179] And record the compensation log compensation_log (compensation_id, type, result, change_qty, execute_time) as (SKO_1234-202505231400-IDC_A_01-0001, MYSQL_COMPENSATION, SUCCESS, 1, 2025-05-26 15:15:00);

[0180] Update the transaction state to completed.

[0181] Optionally, the data consistency check according to the MySQL transaction log and the Redis hash structure includes:

[0182] Extract the inventory change quantity in the MySQL transaction log and the atomic operation log in the Redis hash structure;

[0183] Divide the inventory change quantity and the atomic operation log into preset time windows according to the timestamp;

[0184] Compare the cumulative pre-occupation or release increment in the Redis hash structure in each time window with the total inventory change in the same time window;

[0185] If the deviation in any window exceeds the preset threshold, execute Redis pre-occupation rollback or MySQL data compensation according to the pre-deducted snapshot.

[0186] Illustratively, the change quantity of the completed transaction in the transaction_log table of the MySQL transaction log is obtained, such as 1000 records in total, and the actual deduction quantity is 990;

[0187] Get all operation logs about the product 1001 in Redis, such as 1000 pre-occupation operations and 10 release operations, with a net pre-occupation increment of 990.

[0188] All data within one hour is divided into 12 time windows by 5 minutes time, the change amount of completed transaction in the MySQL transaction log and the operation log about the commodity 1001 in Redis within the corresponding time are put into the corresponding time window, the data in each time window is compared, if the data in the 10:25-10:30 window is abnormal: the Redis pre-occupies increment is 200, the MySQL actually deducts 190, the deviation is 10, the compensation operation is triggered;

[0189] The query pre-deduction snapshot finds a snapshot of an unfinished transaction, the pre-occupied inventory before pre-occupation is 800, and the pre-occupied inventory after pre-occupation is 799, then the Redis pre-occupation rollback (CHECK_202505271025, REDIS_ROLLBACK, 2025-05-2710:25:00, 2025-05-2710:30:00, 200, 190, 10, SUCCESS) is executed,

[0190] After the Redis pre-occupation rollback is completed, the final verification is performed:

[0191] HGET seckill:stock:1001 total_stock returns the remaining inventory 10;

[0192] HGET seckill:stock:1001 reserved_stock returns the pre-occupied amount 0.

[0193] If the read MySQL current state inventory amount is 10 and the pre-occupied amount is 0, the verification is completed.

[0194] Figure 3 is a module schematic diagram of an inventory consistency management system based on a distributed transaction in the embodiment of the application, as shown in Figure 4 The system comprises 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:

[0195] The inventory pre-occupation module 301 is configured to pre-occupy the inventory through the first atomic operation of Redis, and record the state information of the inventory to the Redis hash structure, the state information comprising a pre-occupied amount, a remaining inventory amount and a version number;

[0196] The snapshot generation module 302 is configured to generate a pre-deduction snapshot when the inventory pre-occupation is successful, splice a compensation identifier according to the original business code, a timestamp, a host identifier and a sequence number in a pre-defined format, and write the pre-deduction snapshot and the compensation identifier into the MySQL transaction log, the pre-deduction snapshot comprising all data before inventory change;

[0197] The distributed lock checking module 303 is configured to check the uniqueness of the compensation identifier by using a Redis distributed lock, and submit the current database transaction after confirming the uniqueness of the compensation identifier.

[0198] The compensation execution module 304 is configured to mark the current database transaction as unfinished when the current database transaction fails to be submitted, scan the unfinished records in the MySQL transaction log by using a timing service, and perform a compensation operation on the current database transaction based on the pre-deduction snapshot and the compensation identifier.

[0199] The data checking module 305 is configured to perform data consistency checking on the MySQL transaction log and the Redis hash structure after the compensation operation is performed.

[0200] Optionally, the snapshot generation module 302 is further configured to:

[0201] perform a hash operation on the original business code to obtain a business code of a preset length;

[0202] obtain a timestamp by using a system clock or a distributed clock synchronization service;

[0203] combine the device MAC address and the machine room number, and perform a hash operation to generate a host identifier;

[0204] generate a monotonically increasing serial number based on a Redis counter and prefixed with the timestamp in a preset time window;

[0205] combine the business code, the timestamp, the host identifier, and the serial number into a four-segment compensation identifier.

[0206] Optionally, the distributed lock checking module 303 is further configured to:

[0207] obtain the distributed lock by using a second atomic operation of Redis;

[0208] if the distributed lock is successfully obtained, read the execution state field of the compensation identifier in the MySQL transaction log;

[0209] if the execution state field is in a completed state, release the distributed lock, intercept a request identical to the compensation identifier, and return an idempotent successful response;

[0210] if the execution state field is in an unfinished state, retain the distributed lock.

[0211] Optionally, the compensation execution module 304 is further configured to:

[0212] determine the exception type of the current database transaction by using an exception classification dictionary table preset in the database, record the retry count and the exception type, and the exception type includes a recoverable exception and an unrecoverable exception.

[0213] When the exception type is a recoverable exception, multiple retries are performed by an exponential backoff algorithm;

[0214] When the exception type is an unrecoverable exception, the request for retry is terminated by a fuse, and the current database transaction is marked as an unfinished state.

[0215] Optionally, the compensation execution module 304 is further configured to:

[0216] preset an initial retry interval, a maximum retry interval, and a maximum retry number;

[0217] After performing the first retry, the retry interval is increased exponentially until the maximum retry interval is reached;

[0218] When the retry number exceeds the preset retry number threshold, the request for retry is terminated by a fuse, and the current database transaction is marked as an unfinished state;

[0219] When the retry is successful, the retry counter is reset to zero, and the exception type and the retry number are written into the MySQL transaction log.

[0220] Optionally, the compensation execution module 304 is further configured to:

[0221] retrieve unfinished transactions from the MySQL transaction log;

[0222] According to the pre-deduction snapshot content, a compensation task entity is constructed, the compensation task entity including a target inventory identifier, pre-deduction state data, a compensation type, and a trigger time, the compensation type including Redis pre-occupation rollback and MySQL data compensation;

[0223] When the compensation type is Redis pre-occupation 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 by a first atomic operation, and the version number in Redis is updated to the version number recorded in the snapshot;

[0224] When the compensation type is MySQL data compensation, if the transaction is successfully committed but the target inventory is not deducted, the target inventory is deducted according to the pre-deduction snapshot content, and each compensation operation records the compensation result, the actual change amount, and the execution time to the compensation log table.

[0225] Optionally, the data verification module 305 is further configured to:

[0226] extract the inventory change amount in the MySQL transaction log and the atomic operation log in the Redis hash structure;

[0227] divide the inventory change amount and the atomic operation log into preset time windows according to timestamps;

[0228] Compare the accumulated pre-occupancy or release increment in the Redis hash structure within each time window with the total amount of inventory changes within the same time window;

[0229] If the deviation in any window exceeds the preset threshold, perform Redis pre-occupancy rollback or MySQL data compensation according to the pre-deducted snapshot.

[0230] It should be noted that: the system provided by the above embodiment, when realizing its function, only the above-mentioned division of each functional module is exemplified, and in actual application, the above-mentioned functions can be completed by different functional modules according to the needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided by the above embodiments belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be described here.

[0231] The embodiment further discloses an electronic device, which refers to Figure 4 The electronic device can 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.

[0232] The communication bus 402 is used to realize the connection and communication between the components.

[0233] The user interface 403 can include a display screen (Display) and a camera (Camera), and the optional user interface 403 can further include a standard wired interface and a wireless interface.

[0234] The network interface 404 can optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).

[0235] The processor 401 can include one or more processing cores. The processor 401 connects various parts within the server through various interfaces and lines, performs various functions of the server and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 405, and calling data stored in the memory 405. Alternatively, the processor 401 can be implemented in at least one of a hardware form of a digital signal processing (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The processor 401 can integrate a combination of one or more of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes operating systems, user interfaces, and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; and the modem is used for processing wireless communication. It can be understood that the above-mentioned modem can also not be integrated into the processor 401, but can be realized by a separate chip.

[0236] The memory 405 can include a random access memory (RAM) and a read-only memory (ROM). Alternatively, 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 can include a program storage area and a data storage area, wherein the program storage area can store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area can store data involved in the above-mentioned various method embodiments, etc. The memory 405 can alternatively be at least one storage device located away from the aforementioned processor 401. As shown in the figure, the memory 405 as a computer storage medium can include an operating system, a network communication module, a user interface module, and an application program of a library inventory consistency management method based on distributed transactions. Figure 4

[0237] In ​ ​In the electronic device shown, the user interface 403 is mainly used to provide an interface for user input, and obtain data input by the user; and the processor 401 can be used to invoke an application program of a distributed transaction-based inventory consistency management method stored in the memory 405, which, when executed by one or more processors 401, causes the electronic device to perform the method of one or more of the above-described embodiments.

[0238] It should be noted that, for the foregoing method embodiments, in order to simply describe, they are all described as a series of action combinations, but those skilled in the art should know that the present application is not limited to the order of the actions described, because according to the present application, certain steps can be performed in other order or at the same time. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0239] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0240] In several embodiments provided by the present application, it should be understood that the disclosed device can be implemented in other ways. For example, the device embodiments described above are only schematic. The division of the units is only a logical function division. There can be another division manner for actual implementation, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between different parts can be indirect couplings or communication connections through some interfaces, devices or units, and can be electrical or other forms.

[0241] The units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0242] In addition, each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically, or two or more units can be integrated into one unit. The integrated unit can be realized in the form of hardware, or in the form of a software functional unit.

[0243] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable memory. Based on such understanding, the technical solutions of the present application essentially or say the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a memory 405 and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the embodiments of the present application. The aforementioned memory 405 includes: a U disk, a mobile hard disk, a magnetic or optical disk and various media that can store program codes.

[0244] The above-described are only exemplary embodiments of the present disclosure, and cannot limit the scope of the present disclosure. That is, any equivalent changes and modifications made in accordance with the teachings of the present disclosure are still within the scope of the present disclosure. Other embodiments of the present disclosure will be readily apparent to those skilled in the art upon considering the disclosure. The present application is intended to cover any variations, uses or adaptive changes of the present disclosure that follow the general principles of the present disclosure and include common knowledge or conventional technical means in the art that are not described in the present disclosure. The scope and spirit of the present disclosure are defined by the claims.

Claims

1. A method for managing inventory consistency based on distributed transactions, characterized by, The method is applied to a distributed inventory consistency management platform, and comprises the following steps: Pre-occupying the inventory through a first atomic operation of Redis, and recording state information of the inventory to a Redis hash structure, wherein the state information comprises a pre-occupied quantity, a remaining inventory quantity, and a version number; After successfully pre-occupying the inventory, generating a pre-deduction snapshot, splicing a compensation identifier according to an original business code, a timestamp, a host identifier, and a serial number in a pre-defined format, and writing the pre-deduction snapshot and the compensation identifier to a MySQL transaction log, wherein the pre-deduction snapshot contains all data before the inventory is changed; Verifying the uniqueness of the compensation identifier by using a Redis distributed lock, and submitting a current database transaction after confirming the uniqueness of the compensation identifier; When the current database transaction fails to be submitted, marking the current database transaction as unfinished, scanning unfinished records in the MySQL transaction log through a timing service, and performing a compensation operation on the current database transaction based on the pre-deduction snapshot and the compensation identifier; When the compensation operation is completed, performing data consistency verification on the MySQL transaction log and the Redis hash structure, wherein The compensation operation on the current database transaction based on the pre-deduction snapshot and the compensation identifier comprises the following steps: Retrieving a transaction in an unfinished state from the MySQL transaction log; According to the pre-deduction snapshot content, constructing a compensation task entity, wherein the compensation task entity comprises a target inventory identifier, pre-deduction state data, a compensation type, and a trigger time, and the compensation type comprises Redis pre-occupation rollback and MySQL data compensation; When the compensation type is the Redis pre-occupation rollback, restoring the remaining inventory quantity to the pre-occupation value in the snapshot record through the first atomic operation for the pre-occupied quantity that needs to be released, and updating the version number in Redis to the version number recorded in the snapshot; When the compensation type is the MySQL data compensation, if the transaction is successfully submitted and the target inventory is not deducted, performing deduction on the target inventory according to the pre-deduction snapshot content, and recording the compensation result, the actual change amount, and the execution time to a compensation log table for each compensation operation.

2. The method of claim 1, wherein, The compensation identifier is spliced according to the original business code, the timestamp, the host identifier, and the serial number in a pre-defined format, comprising the following steps: Performing a hash operation on the original business code to obtain a business code with a preset length; Obtaining a timestamp through a system clock or a distributed clock synchronization service; Combining a device MAC address and a machine room number to generate a host identifier through a hash operation; Generating a monotonically increasing serial number based on a Redis counter and taking the timestamp as a prefix in a preset time window; Combining the business code, the timestamp, the host identifier, and the serial number into a four-segment compensation identifier.

3. The method of claim 1, wherein, The verification of the uniqueness of the compensation identifier by using the Redis distributed lock comprises the following steps: Obtaining a distributed lock through a second atomic operation of the Redis; if the distributed lock is acquired successfully, reading an execution state field of the compensation identifier in the MySQL transaction log; if the execution state field is in a completed state, releasing the distributed lock, intercepting a same request as the compensation identifier, and returning an idempotent successful response; if the execution state field is in an uncompleted state, retaining the distributed lock.

4. The method of claim 1, wherein, The marking the current database transaction as uncompleted when the current database transaction fails to be committed comprises: determining an exception type of the current database transaction through a preset exception classification dictionary table in the database, recording a retry number and the exception type, and the exception type including a recoverable exception and an unrecoverable exception; when the exception type is the recoverable exception, performing multiple retries through an exponential backoff algorithm; when the exception type is the unrecoverable exception, terminating the retry request through a fuse, and marking the current database transaction as an uncompleted state.

5. The method of claim 4, wherein, The performing multiple retries through the exponential backoff algorithm when the exception type is the recoverable exception comprises: presetting an initial retry interval, a maximum retry interval, and a maximum retry number; after performing a first retry, increasing a retry interval exponentially until the maximum retry interval is reached; when the retry number exceeds a preset retry number threshold, terminating the retry request through the fuse, and marking the current database transaction as an uncompleted state; when the retry is successful, resetting a retry counter to zero, and writing the exception type and the retry number into the MySQL transaction log.

6. The method of claim 1, wherein, The data consistency check according to the MySQL transaction log and the Redis hash structure comprises: extracting an inventory change amount in the MySQL transaction log and an atomic operation log in the Redis hash structure; dividing the inventory change amount and the atomic operation log into preset time windows according to the time stamp; comparing a cumulative pre-occupancy or release increment in the Redis hash structure in each time window with an inventory change total amount in the same time window; if a deviation in any window exceeds a preset threshold, performing Redis pre-occupancy rollback or MySQL data compensation according to the pre-deduction snapshot.

7. A distributed transaction-based inventory consistency management system, characterized by, The system comprises an inventory pre-occupancy module, a snapshot generation module, a distributed lock check module, a compensation execution module, and a data check module, wherein: The inventory pre-occupancy module is configured to pre-occupy an inventory through a first atomic operation of Redis, and record state information of the inventory into a Redis hash structure, the state information including a pre-occupied quantity, a remaining inventory quantity, and a version number. The snapshot generation module is configured to generate a pre-deduction snapshot when the inventory pre-occupancy is successful, splice a compensation identifier according to an original business code, a time stamp, a host identifier, and a sequence number in a pre-defined format, and write the pre-deduction snapshot and the compensation identifier into a MySQL transaction log, the pre-deduction snapshot containing all data before the inventory change. The distributed lock checking module is configured to check the uniqueness of the compensation identifier by using a Redis distributed lock, and submit the current database transaction after confirming the uniqueness of the compensation identifier; The compensation execution module is configured to mark the current database transaction as unfinished when the current database transaction fails to be submitted, scan unfinished records in the MySQL transaction log by using a timing service, and perform a compensation operation on the current database transaction based on the pre-deduction snapshot and the compensation identifier, wherein, The compensation operation based on the pre-deduction snapshot and the compensation identifier includes: retrieving a transaction in an unfinished state from the MySQL transaction log; constructing a compensation task entity according to the pre-deduction snapshot content, the compensation task entity including a target inventory identifier, pre-deduction state data, a compensation type, and a trigger time, the compensation type including Redis pre-occupation rollback and MySQL data compensation; when the compensation type is the Redis pre-occupation rollback, restoring a remaining inventory quantity to a pre-occupation value in the snapshot record by using the first atomic operation for a pre-occupation quantity to be released, and updating a version number in the Redis to a version number recorded in the snapshot; when the compensation type is the MySQL data compensation, if the transaction is successfully submitted and the target inventory is not deducted, performing deduction on the target inventory according to the pre-deduction snapshot content, and recording a compensation result, an actual change amount, and an execution time to a compensation log table for each compensation operation; The data checking module is configured to perform data consistency checking on the MySQL transaction log and the Redis hash structure after the compensation operation is completed.

8. An electronic device, comprising: The electronic device includes a processor, a memory, a user interface, and a network interface, the memory is configured to store instructions, the user interface and the network interface are configured to communicate with other devices, and the processor is configured to execute the instructions stored in the memory to enable the electronic device to perform the method of any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method of any one of claims 1-6.

Images