CN113742355A

CN113742355A - Method, device, equipment and computer readable medium for updating inventory

Info

Publication number: CN113742355A
Application number: CN202010604422.5A
Authority: CN
Inventors: 石朝阳; 赵辉; 任银龙
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Priority date: 2020-06-29
Filing date: 2020-06-29
Publication date: 2021-12-03

Abstract

The invention discloses a method, apparatus, device and computer-readable medium for updating inventory, and relates to the field of computer technology. A specific implementation of the method includes: in the process of locking a single thread in the database, writing a verification key after updating the inventory quantity; using the verification key to learn the operation result of updating the inventory quantity, and returning the Operation result; release the single thread after a preset processing time threshold, and store the inventory quantity based on the operation result and the preset processing time threshold. This embodiment can reduce occupation of more resources and avoid waste of resources.

Description

Method, device, equipment and computer readable medium for updating inventory

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a computer-readable medium for updating an inventory.

Background

At present, the stock updating mode generally focuses on queuing a large number of stock requests by using various locking mechanisms and then updating the requests in sequence, thereby achieving the purpose of controlling the stock and preventing superdistribution.

In addition, higher throughput can be achieved with lock-free mechanisms. As one example, for deducting inventory, if inventory is sufficient, deducting; if the inventory is insufficient, the deduction is not executed.

In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art: whether a locking mechanism or a non-locking mechanism exists, more resources are occupied, and a great deal of resource waste is caused.

Disclosure of Invention

In view of this, embodiments of the present invention provide a method, an apparatus, a device, and a computer-readable medium for updating an inventory, which can reduce occupation of more resources and avoid waste of resources.

To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a method of updating an inventory, including:

in the processing process of locking a single thread in a database, writing a check key after updating the inventory quantity;

acquiring an operation result of updating the inventory quantity by using the check secret key, and returning the operation result;

releasing the single thread after a preset processing time threshold, and storing the inventory quantity based on the operation result and the preset processing time threshold.

The obtaining, by using the check key, an operation result of updating the inventory quantity, and returning the operation result includes:

and under the condition of abnormal execution, verifying that the verification secret key is successful, and returning the operation result, wherein the operation result comprises successful stock quantity updating.

and under the condition of execution abnormity, detecting that the verification secret key has no abnormity, verifying that the verification secret key is successful, and returning the operation result, wherein the operation result comprises that the inventory quantity is successfully updated.

and under the condition of abnormal execution, detecting that the checking secret key has abnormality, obtaining that the stock quantity updating fails, and returning the operation result, wherein the operation result comprises the stock quantity updating failure.

After detecting that the check key has an abnormality, the method further includes:

and in a message queue for checking the inventory quantity, if the checking secret key exists, rolling back the inventory quantity.

The detecting that the checking key exists in the message queue for checking the inventory quantity includes:

in the message queue for checking the inventory quantity, after the fact that the stored quantity information is checked to be not the repeated information is determined through the anti-repeated key, the checking key is detected to exist.

The storing the inventory quantity based on the operation result and the preset processing time threshold value comprises:

and returning the operation result within the preset processing time threshold, wherein the operation result comprises that the inventory quantity is successfully updated, and synchronously storing the updated inventory quantity in a data synchronization message queue.

The method further comprises the following steps:

and returning the operation result after presetting a processing time threshold, wherein the check secret key exists in the database, and synchronously storing the updated inventory quantity in a data synchronous message queue.

According to a second aspect of the embodiments of the present invention, there is provided an apparatus for updating an inventory, including:

the loading module is used for writing the verification secret key after updating the inventory quantity in the locking single-thread processing process of the database;

the sending module is used for acquiring an operation result of updating the inventory quantity by using the check secret key and returning the operation result;

and the processing module is used for releasing the single thread after a preset processing time threshold value and storing the inventory quantity based on the operation result and the preset processing time threshold value.

According to a third aspect of embodiments of the present invention, there is provided an electronic device that updates an inventory, including:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method as described above.

According to a fourth aspect of embodiments of the present invention, there is provided a computer readable medium, on which a computer program is stored, which when executed by a processor, implements the method as described above.

One embodiment of the above invention has the following advantages or benefits: in the processing process of locking a single thread in a database, writing a check key after updating the inventory quantity; acquiring an operation result of updating the inventory quantity by using the check secret key, and returning the operation result; releasing the single thread after the preset processing time threshold, and storing the inventory quantity based on the operation result and the preset processing time threshold. The inventory is updated by adopting the locked single thread and the single thread is automatically released, so that on one hand, the accuracy of updating the inventory is ensured, on the other hand, the whole throughput is improved, meanwhile, the CPU idle consumption is avoided, more resources are occupied, and the resource waste is avoided.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

FIG. 1 is a schematic diagram of a main flow of a method of updating inventory according to an embodiment of the invention;

FIG. 2 is a flow diagram of deducting inventory quantities in a lua script, according to an embodiment of the present invention;

FIG. 3 is a flow chart illustrating the result of operations to update inventory quantities according to embodiments of the invention;

FIG. 4 is a flow chart illustrating the result of another operation for updating inventory quantities according to an embodiment of the present invention;

FIG. 5 is a schematic flow chart illustrating checking inventory quantities according to an embodiment of the present invention;

FIG. 6 is a flow diagram of processing inventory quantities according to an embodiment of the invention;

FIG. 7 is a flow diagram of a method of updating inventory according to an embodiment of the invention;

fig. 8 is a schematic diagram of the main structure of an apparatus for updating an inventory according to an embodiment of the present invention;

FIG. 9 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

fig. 10 is a schematic block diagram of a computer system suitable for use in implementing a terminal device or server according to an embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

The current inventory anti-overblocker mechanism, high concurrency, results in higher request latency and throughput impairment. Even if some systems are changed to be provided with a lock-free mechanism, the CPU is seriously wasted due to the lock-free mechanism, and a large amount of resources are wasted due to high resource occupation.

For inventory reduction with lock mechanisms, higher request delays result because a large number of requests come in and need to be queued for resources. The subsequent operation can be performed only when the resource is allowed to be acquired, so that the queuing mechanism has a waiting action and the throughput of the system is inevitably greatly influenced.

The high CPU idle consumption is caused for the inventory reduction method without the lock mechanism because the implementation principle of the lock mechanism is based on the CAS atomic operation at the bottom of the system. The method comprises the steps of taking a mark of a request, comparing the mark, releasing if the mark is suitable, and continuing the next round of comparison, wherein the occupation of a CPU is obvious, and the high CPU occupation can lead other business logics to be influenced slightly. The CAS atomic operation is a lock-free algorithm, which can ensure the accuracy of multi-request execution under high concurrency and avoid confusion.

However, in the process of updating inventory in a Redis cluster, whether there is a lock or no lock, since Redis update fails or is successfully updated due to various network reasons, but results return fails and the like, effective ascertainment cannot be achieved, and therefore, superdistribution or underdistribution is often caused.

In order to solve the technical problems of occupying more resources and wasting resources, the following technical scheme in the embodiment of the invention can be adopted.

Referring to fig. 1, fig. 1 is a schematic diagram of a main flow of a method for updating an inventory according to an embodiment of the present invention, in a process of locking a single thread in a database, an operation result of updating an inventory amount is obtained by checking a secret key, and then the single thread is released after a preset processing time threshold, and the data is stored. As shown in fig. 1, the method specifically comprises the following steps:

s101, in the process of locking a single thread in a database, the inventory quantity is updated and then the check key is written in.

A single thread is locked in the database. As one example, the database may be a detect Remote Dictionary service (Redis) cluster. The Redis is an open source log-type and Key-Value database which is written by using ANSI C language, supports network, can be based on memory and can also be persistent, and provides API of multiple languages.

A single thread is a locked thread whose purpose is to: without being disturbed by any other command. As one example, the locked single thread may be a lua script.

In the embodiment of the invention, the characteristic of single-thread processing of the Redis cluster is utilized, and the Redis cluster is directly put into a Redis cluster channel for processing. Therefore, the overall throughput is improved on a certain level, and the problem of CPU idle consumption is not involved.

Upon receiving an update inventory request, lua scripts may be loaded in the Redis cluster. Due to the fact that the built-in lua script is used for updating the stock, the stock is updated to be atomicity operation, and the execution process is not interfered by any other commands. And returning the lua script after the script is executed. The atomic operation of the lua script and the request are executed in sequence, so that the condition of excessive or short stock can be prevented. lua is a programming language widely used in Redis, and can be used to write Redis integration modules.

In the embodiment of the present invention, a technical scheme for updating an inventory is exemplarily described by taking loading of a lua script in a Redis cluster as an example.

In an embodiment of the present invention, updating inventory includes both deducting inventory and adding inventory. The following is an exemplary description of the reduction of the stock quantity.

Referring to fig. 2, fig. 2 is a schematic flowchart of reducing the inventory count in the lua script according to an embodiment of the present invention, which specifically includes:

s201, the user performs inventory quantity deduction operation.

The user sends a request to perform a deduct inventory amount operation.

S202, loading the lua script in the Redis cluster.

In a Redis cluster, lua scripts are loaded from caches to execute the lua scripts.

And S203, the current inventory quantity meets the deduction quantity.

Since the inventory reduction operation is performed, it is necessary to determine whether the current inventory amount can satisfy the reduction amount. If the current inventory quantity can meet the deduction quantity, executing S204; if the current inventory count fails to satisfy the deduction count, S205 is performed.

It should be noted that, in the case that the inventory update request is specifically an inventory increase condition, S203 and S205 may not be executed, and S204 may be executed after the lua script is loaded.

S204, writing the checking secret key after deducting the inventory quantity in the lua script.

In the case where the current stock quantity satisfies the deducted quantity, the check key may be written after deducting the stock quantity in the lua script. That is, after the inventory amount is deducted in the lua script, the check key is written in the Redis cluster.

It should be noted that, when the stock is deducted and the check key is written, it can be regarded as an operation that cannot be disassembled. This is because: the check key is used for detecting whether inventory deduction is successful or not, and the two operations are either successful or failed.

And S205, the stock deduction fails.

In the case where the current inventory quantity does not satisfy the deduction quantity, it is determined that the inventory deduction fails.

In the embodiment of fig. 2, taking the reduction of the stock quantity as an example, whether the stock reduction is successful can be detected by writing the check key. Likewise, whether the inventory increase is successful or not can be detected by writing the check key.

S102, obtaining an operation result of updating the inventory quantity by using the verification secret key, and returning the operation result.

It is considered that deduction of stock and writing of the check key can be regarded as one operation that cannot be disassembled. Either both operations succeed or both operations fail. Error trapping can be added for both operations. Whether the operation is abnormal in execution, the checking secret key can be used for judging whether the inventory is updated successfully. Illustratively, if a check password exists in the Redis cluster, the inventory update is successful; if the checking secret key does not exist in the Redis cluster, the inventory updating fails.

And finally, acquiring an operation result of updating the inventory quantity by using the check key. Meanwhile, the inventory quantity is updated by adopting the built-in lua script, namely S101 and S102 belong to atomic operation, and the execution process is not interfered by any other command. Returning the lua script after the lua script is executed. Return lua script. That is, the returned lua script includes the operation result of updating the stock quantity.

Referring to fig. 3, fig. 3 is a schematic flowchart of an operation result of updating the inventory quantity according to an embodiment of the present invention, which specifically includes:

s301, an execution exception occurs.

In the operation of updating the stock quantity in the lua script and writing the check password in the Redis description, it is judged whether an execution abnormality occurs. In the normal execution process of a program, due to network reasons and the like, the execution fails, and the thrown exception is called an execution exception.

If the execution exception occurs, it needs to confirm again whether the checking key exists in the Redis cluster, that is, S302 is executed; in the case where the execution abnormality has not occurred, S303 is executed.

S302, whether a checking secret key exists in the Redis cluster or not is judged.

And in the case of execution exception, verifying the check key in the Redis cluster so as to obtain an operation result of updating the inventory quantity. Specifically, the operation result of updating the stock quantity may be determined by determining whether a check key exists in the Redis cluster.

Checking the secret key in the Redis cluster, and executing S303; if the checking key does not exist in the Redis cluster, S304 is performed.

And S303, successfully updating the inventory.

And in the operation of updating the stock quantity in the lua script and writing the verification password in the Redis record, if no execution exception occurs, determining that the stock updating is successful. And if the checking secret key exists in the Redis cluster, determining that the inventory updating is successful.

And S304, failing to update the inventory.

If the checking key does not exist in the Redis cluster, determining that the inventory updating fails.

In the embodiment of fig. 3, the checking key is detected in the Redis cluster, and then the inventory update result is determined, so that the inventory can be updated in time.

Referring to fig. 4, fig. 4 is a flow chart illustrating another operation result of updating the inventory quantity according to the embodiment of the invention. The technical solution in fig. 4 differs from the technical solution in fig. 3 in that: in order to improve the accuracy of the inventory updating result, the check key is detected before judging whether the check key exists in the Redis cluster. The method specifically comprises the following steps:

s401, execution abnormity occurs.

In the operation of updating the stock quantity in the lua script and writing the check password in the Redis description, it is judged whether an execution abnormality occurs.

When the execution is abnormal, the check key needs to be detected again, and S402 is executed; in the case where the execution exception has not occurred, S404 is executed.

S402, detecting whether the check key is abnormal or not.

Detecting the execution of the check key, and executing S405 if the abnormity occurs; the execution of the check key is detected, and if there is no exception, S403 is executed.

S403, judging whether a check key exists in the Redis cluster.

And under the condition of execution abnormity, detecting that the verification secret key is not abnormal, and verifying the verification secret key in the Redis cluster to obtain an operation result of updating the inventory quantity. Specifically, the operation result of updating the stock quantity may be determined by determining whether a check key exists in the Redis cluster.

Checking the secret key in the Redis cluster, and executing S404; if the checking key does not exist in the Redis cluster, S405 is performed.

And S404, successfully updating the inventory.

S405, the inventory updating fails.

In the embodiment of fig. 4, in the case of an execution exception, in order to improve the accuracy of determining the inventory update result, the check key may be detected.

In an embodiment of the present invention, after detecting that there is an exception in the checking key, it may be detected whether there is a checking key in the Redis cluster in the message queue for checking the inventory amount to rollback the inventory amount.

Referring to fig. 5, fig. 5 is a schematic flow chart of checking the inventory quantity according to the embodiment of the present invention, which specifically includes:

and S501, entering an inventory updating message into a message queue.

If an anomaly occurs during the process of checking the check key, the inventory update message requested this time may be entered into a Message Queue (MQ) that checks the inventory quantity. And checking the inventory quantity through a post-worker node (worker). MQ is a generic term for a message channel that pushes or puts messages into a queue and then processes them by distribution to consumers.

S502, determining that the inventory updating message is not a repeated message.

Considering that the inventory update message may be repeatedly transmitted many times, in order to avoid resource waste caused by repeated transmission, it is necessary to determine whether the update message is a repeated message.

As one example, it may be determined that the update message is not a duplicate message by the anti-duplication key. Such as: and when the inventory updating message is received for the first time, generating a corresponding anti-duplication secret key aiming at the inventory updating message. And receiving the inventory update message again, wherein the inventory update message generates a corresponding anti-duplication key, so that the inventory update message received again does not need to be processed.

S503, judging whether the checking secret key exists in the Redis cluster.

If the checking secret key exists in the Redis cluster, the request inventory is successfully updated in the lua script, and S504 is executed; if the checking key does not exist in the Redis cluster, it is proved that the request inventory update fails in the lua script, and then S505 is executed.

And S504, rolling back the stock quantity.

If the requested inventory update is successful in the lua script, the inventory amount is rolled back. As one example, updating the inventory quantity includes deducting the inventory quantity by 2 pieces. The original stock quantity is 10, and the updated quantity is 8. And if the stock quantity is rolled back, rolling back the stock quantity to 10 pieces.

And S505, no action is performed.

This request inventory update fails in the lua script without doing anything.

And after executing S504 or S505, assembling a feedback message according to the inventory quantity.

In the embodiment of fig. 5, the inventory amount is checked by detecting whether a check key is present in the Redis cluster. The short-cut of the stock quantity can be guaranteed to the maximum extent.

S103, releasing the single thread after the preset processing time threshold value, and storing the inventory quantity based on the operation result and the preset processing time threshold value.

In the embodiment of the invention, the locking single thread does not need to be unlocked according to the instruction, but automatically unlocks after the preset processing time threshold value passes. Thereby reducing the use of resources and avoiding the waste of resources.

In the embodiment of the present invention, in case of normal network condition, the lua script will return within the preset processing time threshold. As an example, the preset processing time threshold is 5 seconds. The operation result is included in the lua script so that the inventory data can be processed in the database based on the operation result. Wherein, the operation result comprises the success of the stock update or the failure of the stock update.

In an embodiment of the present invention, the stock quantity may be stored based on the operation result and a preset processing time threshold.

In an embodiment of the present invention, the lua script returns within a preset processing time threshold, and the update result includes that the update of the inventory quantity is successful, and the updated inventory quantity is synchronously stored in the data synchronization message queue.

In one embodiment of the invention, the lua script is returned within a preset processing time threshold, and the update result includes failure to update the inventory quantity, then no processing is required.

It should be noted that the message queue for data synchronization may be an asynchronous message queue. That is, the updated inventory quantity is asynchronously warehoused through the message queue of data synchronization, so that network congestion caused by synchronous warehousing of more lua scripts is avoided.

In one example of the present invention, the lua script returns after a preset processing time threshold, the verification key exists in the Redis cluster, and the updated inventory number is synchronously stored in the message queue of the data synchronization.

If the lua script returns overtime, it indicates that the update of the inventory quantity may fail, and in order to confirm whether the update of the inventory quantity is updated, it may be confirmed whether the check key is stored in the Redis cluster.

In one example of the present invention, the lua script returns after a preset processing time threshold, and the verification key does not exist in the Redis cluster, and then no processing is needed.

Referring to fig. 6, fig. 6 is a schematic flow chart of processing the inventory quantity according to the embodiment of the present invention, which specifically includes:

s601, judging whether the return of the lua script is overtime.

If the lua script returns not overtime, executing S602; if the lua script returns a timeout indicating that the update of the inventory count may fail, S603 is executed.

And S602, successfully updating the inventory.

If the inventory update is successful, executing S604; if the inventory update fails, the process is not performed.

S603, whether the checking secret key exists in the Redis cluster or not.

If the checking secret key exists in the Redis cluster, if the updating of the inventory is successful, executing S604; in the case where no check key exists in the Redis cluster, failure of inventory update is explained.

And S604, storing the inventory quantity.

And under the condition that the inventory updating is successful, synchronously storing the updated inventory quantity in a message queue of data synchronization.

It should be noted that only in the case that the lua script returns a timeout, it is determined whether the inventory update is successful by whether the check key exists in the Redis cluster. This is because, if it is determined that the inventory update is successful by checking the key, network congestion may be caused in the case of high concurrency of requests, resulting in a crash. In general, most lua scripts do not time out, and it is most convenient and economical to know the inventory update results from the lua scripts.

In the embodiment, in the process of locking a single thread in the database, the inventory quantity is updated and then the check key is written in; acquiring an operation result of updating the inventory quantity by using the check secret key, and returning the operation result; releasing the single thread after the preset processing time threshold, and storing the inventory quantity based on the operation result and the preset processing time threshold. The inventory is updated by adopting the locked single thread and the single thread is automatically released, so that on one hand, the accuracy of updating the inventory is ensured, on the other hand, the whole throughput is improved, meanwhile, the CPU idle consumption is avoided, more resources are occupied, and the resource waste is avoided.

Meanwhile, whether the inventory updating is successful or not can be definitely known through checking the secret key. The use of the check key can ensure that the inventory updating notice is sent to the calling party so as to facilitate the subsequent processing. Such as: if the deduction is successful, no processing is carried out; if the deduction fails, rollback processing and the like can be carried out.

The technical solution in the embodiments of the present invention is exemplarily described below with reference to the accompanying drawings. The update inventory request is specifically a deduct inventory request.

Referring to fig. 7, fig. 7 is a schematic flowchart of a method for updating an inventory according to an embodiment of the present invention, which specifically includes:

s701, the user performs inventory quantity deduction operation.

The user sends a request to perform a deduct inventory amount operation.

S702, loading the lua script in the Redis cluster.

And S703, the current inventory quantity meets the deduction quantity.

If the current inventory quantity can meet the deduction quantity, writing a check key after deducting the inventory quantity in the lua script, and executing S704; if the current inventory quantity fails to satisfy the deduction quantity, S709 is executed.

S704, an execution exception occurs.

When the execution is abnormal, the check key needs to be detected again, and S705 is executed; in the case where the execution exception has not occurred, S708 is executed.

S705, whether the check key is abnormal or not is detected.

Detecting the execution of the check key, and if the exception occurs, executing S706 and S709; the execution of the check key is detected, and if there is no exception, S707 is executed.

S706, judging whether the checking secret key exists in the Redis cluster.

If an abnormality occurs in the process of checking the secret key, the inventory update message requested this time may be input into the message queue for checking the inventory quantity. And checking the inventory quantity through a postposition worker.

After determining that the inventory update message is not a duplicate message, determining whether a check key exists in the Redis cluster.

If the checking secret key exists in the Redis cluster, the request inventory is proved to be updated successfully in the lua script, and the quantity of the request inventory is rolled back; if the checking key does not exist in the Redis cluster, the request inventory update fails in the lua script, and no action is taken.

And S707, judging whether the checking secret key exists in the Redis cluster.

Checking the secret key in the Redis cluster, and executing S708; if the Redis cluster does not have the check key, S709 is performed.

And S708, successfully deducting the inventory.

And in the operation of updating the stock quantity in the lua script and writing the verification password in the Redis record, if no execution exception occurs, determining that the stock updating is successful. If the checking secret key exists in the Redis cluster, the inventory deduction is determined to be successful.

S709, stock deduction fails.

If the checking key does not exist in the Redis cluster, determining that the inventory deduction fails. And if the checking secret key is detected to be abnormal, determining that the stock deduction fails.

S710, judging whether the return of the lua script is overtime.

If the lua script returns not overtime, S711 is executed; if the lua script returns a time-out indicating that the update of the inventory count may fail, S712 is executed.

And S711, successfully deducting the inventory.

In the case where the stock deduction is successful, S713 is executed; if the inventory update fails, the process is not performed.

S712, judging whether the checking secret key exists in the Redis cluster.

If the checking secret key exists in the Redis cluster, if the stock deduction is successful, executing S713; in the case where no check key exists in the Redis cluster, failure of stock deduction is demonstrated.

And S713, storing the stock quantity.

In the case of successful inventory deduction, the synchronization deducts the inventory amount in the message queue of the data synchronization.

Referring to fig. 8, fig. 8 is a schematic diagram of a main structure of an apparatus for updating an inventory according to an embodiment of the present invention, where the apparatus for updating an inventory can implement a method for updating an inventory, as shown in fig. 8, the apparatus for updating an inventory specifically includes:

the loading module 801 is configured to write the check key after updating the inventory amount in the locking single-thread processing process of the database.

The sending module 802 is configured to obtain an operation result of updating the inventory amount by using the check key, and return the operation result.

And the processing module 803 is configured to release the single thread after the preset processing time threshold, and store the inventory amount based on the operation result and the preset processing time threshold.

In an embodiment of the present invention, the sending module 802 is specifically configured to, in a case that the execution exception occurs, verify that the verification key is successful, and return an operation result, where the operation result includes that the update of the inventory amount is successful.

In an embodiment of the present invention, the sending module 802 is specifically configured to, in a case that the execution exception occurs, detect that the verification key does not have an exception, and verify that the verification key is successful, and return an operation result, where the operation result includes that the update of the inventory number is successful.

In an embodiment of the present invention, the sending module 802 is specifically configured to, in a case that an execution exception occurs, detect that the checking key has an exception, acquire that the stock quantity updating fails, and return an operation result, where the operation result includes that the stock quantity updating fails.

In an embodiment of the present invention, the sending module 802 is further configured to, in a message queue for checking the inventory quantity, detect that a checking key exists, and roll back the inventory quantity.

In an embodiment of the present invention, the sending module 802 is specifically configured to, in a message queue for checking the inventory quantity, determine, through the anti-duplication key, that the message for checking the storage quantity is not a duplicate message, and then detect that the checking key exists.

In an embodiment of the present invention, the processing module 803 is specifically configured to return an operation result within a preset processing time threshold, where the operation result includes that the update of the inventory quantity is successful, and synchronously store the updated inventory quantity in a data synchronization message queue.

In an embodiment of the present invention, the processing module 803 is further configured to return an operation result after a preset processing time threshold, where the check key exists in the database, and the updated inventory number is synchronously stored in the data synchronization message queue.

Fig. 9 illustrates an exemplary system architecture 900 to which the method of updating inventory or the apparatus for updating inventory of an embodiment of the invention may be applied.

As shown in fig. 9, the system architecture 900 may include

end devices

901, 902, 903, a network 904, and a server 905. Network 904 is the medium used to provide communication links between

terminal devices

901, 902, 903 and server 905. Network 904 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

A user may use the

terminal devices

901, 902, 903 to interact with a server 905 over a network 904 to receive or send messages and the like. The

terminal devices

901, 902, 903 may have installed thereon various messenger client applications such as, for example only, a shopping-like application, a web browser application, a search-like application, an instant messaging tool, a mailbox client, social platform software, etc.

The

terminal devices

901, 902, 903 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 905 may be a server providing various services, such as a background management server (for example only) providing support for shopping websites browsed by users using the

terminal devices

901, 902, 903. The backend management server may analyze and perform other processing on the received data such as the product information query request, and feed back a processing result (for example, target push information, product information — just an example) to the terminal device.

It should be noted that the method for updating the inventory provided by the embodiment of the present invention is generally performed by the server 905, and accordingly, the apparatus for updating the inventory is generally disposed in the server 905.

It should be understood that the number of terminal devices, networks, and servers in fig. 9 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 10, a block diagram of a computer system 1000 suitable for use with a terminal device implementing an embodiment of the invention is shown. The terminal device shown in fig. 10 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.

As shown in fig. 10, the computer system 1000 includes a Central Processing Unit (CPU)1001 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)1002 or a program loaded from a storage section 1008 into a Random Access Memory (RAM) 1003. In the RAM 1003, various programs and data necessary for the operation of the system 1000 are also stored. The CPU 1001, ROM 1002, and RAM 1003 are connected to each other via a bus 1004. An input/output (I/O) interface 1005 is also connected to bus 1004.

The following components are connected to the I/O interface 1005: an input section 1006 including a keyboard, a mouse, and the like; an output section 1007 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 1008 including a hard disk and the like; and a communication section 1009 including a network interface card such as a LAN card, a modem, or the like. The communication section 1009 performs communication processing via a network such as the internet. The driver 1010 is also connected to the I/O interface 1005 as necessary. A removable medium 1011 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1010 as necessary, so that a computer program read out therefrom is mounted into the storage section 1008 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication part 1009 and/or installed from the removable medium 1011. The computer program executes the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 1001.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes a transmitting unit, an obtaining unit, a determining unit, and a first processing unit. The names of these units do not in some cases constitute a limitation to the unit itself, and for example, the sending unit may also be described as a "unit sending a picture acquisition request to a connected server".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise:

According to the technical scheme of the embodiment of the invention, in the process of locking a single thread in a database, the inventory quantity is updated and then the check key is written in; acquiring an operation result of updating the inventory quantity by using the check secret key, and returning the operation result; releasing the single thread after the preset processing time threshold, and storing the inventory quantity based on the operation result and the preset processing time threshold. The inventory is updated by adopting the locked single thread and the single thread is automatically released, so that on one hand, the accuracy of updating the inventory is ensured, on the other hand, the whole throughput is improved, meanwhile, the CPU idle consumption is avoided, more resources are occupied, and the resource waste is avoided.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method of updating inventory, comprising:

2. The method for updating the inventory according to claim 1, wherein the obtaining the operation result of updating the inventory quantity by using the check key and returning the operation result comprises:

3. The method for updating the inventory according to claim 1, wherein the obtaining the operation result of updating the inventory quantity by using the check key and returning the operation result comprises:

4. The method for updating the inventory according to claim 1, wherein the obtaining the operation result of updating the inventory quantity by using the check key and returning the operation result comprises:

5. The method for updating the inventory of claim 4, wherein after detecting the abnormality of the checking key, further comprising:

6. The method of updating inventory of claim 5, wherein detecting the presence of the check key in the message queue of checking inventory quantities comprises:

7. The method of updating inventory of claim 1, wherein said storing an inventory quantity based on the operation result and the pre-set processing time threshold includes:

8. The method of updating inventory of claim 1, further comprising:

9. An apparatus for updating an inventory, comprising:

10. An electronic device for updating inventory, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-8.

11. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-8.