This article is participating in “Java Theme Month – Java Development in Action”, see the activity link for details

This is the fourth day of my participation in the Gwen Challenge.

Hello, I am Wukong.

I am a seckill request, escaping from this planet…

Today we are going to discuss the plan of inventory reduction.

In daily life, we always use various e-commerce apps to buy up goods, but the inventory is very small, especially in the second kill scenario, the goods may only be one, so how to ensure that there will not be oversold situation?

First, three schemes of inventory deduction

1.1 Order and reduce inventory

Reduce inventory when users place an order

Advantages: real-time inventory reduction, avoid the problem of inventory reduction due to shortage of payment

Disadvantages: malicious buyers place large orders, will use up the inventory, but do not pay, really want to buy people can not buy

1.2 Payment to reduce inventory

The order page displays the latest inventory, and inventory is not destocked immediately when the order is placed, but only when payment is made.

Advantages: prevent malicious buyers to place a large number of orders using up inventory, avoid the shortcomings of reducing inventory

Disadvantages: The inventory number displayed on the order page may not be the latest inventory number, and after the inventory number is used up, the inventory number on the order page is not refreshed, and the next order number exceeds the inventory number. If the paid order number exceeds the inventory number, there will be payment failure.

1.3 Withholding inventory

The order page displays the latest inventory. After placing the order, keep the inventory for a certain period of time (say 10 minutes). After the retention time, the inventory is released. If the payment is made after the retention time, if there is no stock, the payment fails.

Advantages: Combined with the advantages of ordering inventory reduction, real-time inventory reduction, and alleviate the problem of malicious buyers placing a large number of orders, the retention time is not paid, the release of inventory.

Disadvantages: retention time, a large number of malicious buyers will be out of stock orders. When concurrency is high, the number of orders still exceeds the number of inventories.

How to solve the problem of malicious buyers placing orders

Malicious buyers are those who place large orders in a short period of time to run out of inventory.

2.1 Limit the number of user orders

Advantages: limit malicious buyers order

Cons: Users who want to buy more are limited, which will reduce sales

2.2 Identify malicious buyers

Add users to the blacklist by identifying their device ID or member ID. The disadvantage is that some users are simulated and it is impossible to identify whether malicious buyers are real or not.

Iii. How to solve the problem of successful order but failed payment (shortage of inventory)

3.1 Reserve Stock

After the commodity inventory is used up, if there is still user payment, the reserve inventory is directly deducted.

Advantages: Alleviate the problem of payment failure of some users.

Disadvantages: Spare inventory can only alleviate the problem, not solve it fundamentally. In addition, the reserve inventory can be used for ordinary goods, but for special goods with small inventory, the reserve inventory will not be very large, or a large number of users will place successful orders but fail to pay due to insufficient inventory.

Iv. How to solve the scenario of oversold inventory under high concurrency

The simplest explanation for oversold inventory is that there are too many orders and not enough goods to ship.

scenario

When users A and B place orders successfully, the inventory is deducted during payment. The current inventory is 10. Since both A and B still have the inventory number when they check the inventory, both A and B can make payment.

A and B pay at the same time. After the payment of A and B is completed, it can be regarded as two requests to call back the background system to deduct inventory. There are two threads to process the request, and the inventory queried by the two threads is 10.

Then thread A updates the final inventory count lastInventory = inventory-1 = 9,

B Thread update inventory lastInventory = inventory-1 = 9

However, the actual final inventory should be 8, so the inventory is oversold and cannot be shipped.

So how to solve the situation of oversold inventory?

The following solutions are database – based. Some of you might ask if you can use Redis distributed locks, which we’ll talk about later.

Plan a

SQL statements update the inventory directly, rather than querying it and assigning values

UPDATE[Inventory table]SETThe inventory -1
Copy the code

Scheme 2

When the SQL statement updates the inventory, if the inventory number is negative after deduction, the exception is thrown directly, and the atomicity of the transaction is used for automatic rollback.

Plan 3

Use SQL statements to update inventory to prevent negative inventory

UPDATE[Inventory table]SETThe inventory -1 WHEREThe inventory -1 > 0
Copy the code

If the number of affected items is greater than 1, it indicates that the inventory reduction is successful. Otherwise, the inventory will not be updated and the refund will be made.

5. How to reduce inventory in the second kill scenario

5.1 Use order to reduce inventory

In the second kill scenario, most users want to purchase goods directly, so they can directly reduce inventory by placing orders.

A large number of users and malicious users are carried out at the same time, the difference is that normal users will directly purchase goods, malicious users in the competition for the quota, but get the same qualification as ordinary users, so ordering inventory reduction in the second kill scenario, malicious users ordering can not cause the disadvantages mentioned before.

And the order directly deducted inventory, this plan is simpler, in the first step of the deducted inventory.

5.2 the Redis cache

The query cache is faster than the database query, so the inventory number is placed in the cache and the inventory is deducted directly from the cache.

If concurrency is high, a distributed locking scheme can also be used. Distributed locks can be referenced in two previous articles I wrote:

Distributed Lock 1

Distributed Lock 2

5.3 current limiting

In the split-kill scenario, a lot of traffic limiting is done to requests, such as traffic limiting on front-end pages and traffic limiting on back-end token buckets. When it comes to inventory reduction, the number of requests is very low. Therefore, current limiting is often used in the second kill scheme.

In addition, in real projects, more mechanisms are used to ensure normal inventory reduction. This is the introduction of brick throwing, and I hope you can put forward valuable suggestions and plans ~.

Free a summary of seckill scenario scheme:

This article has been synchronized to: github.com/Jackson0714…

About the author: 8-year Veteran of Internet workplace | full stack engineer | super dad after 90 | open source practitioner | owner of public number 10,000 fans original number. Blue Bridge signed the author, the author of “JVM performance tuning practice” column, handwritten a set of 70,000 words SpringCloud practice summary and 30,000 words distributed algorithm summary. Welcome to follow my public account “Wukong Chat framework”, free access to learning materials.