Nowadays, in the e-commerce industry, flash salesrush buying activities have become a common promotional method for merchants. However, the inventory quantity is limited, and if the number of people placing orders at the same time exceeds the inventory quantity, it will cause the product to be oversold or even the inventory to become negative. Another example: rush to buy train tickets, rush to buy real estate in forums, lottery and even popular Weibo comments can also cause blocking high concurrency problems. If no measures are taken, the server may be paralyzed in an instant. How to solve this problem?
Here are some ideas that I think are more feasible:
Option 1: Use message
queue
to implement can be based on messages
queue
such as MemcacheQ. The specific implementation plan is as follows Let’s express itFor example, if there are 100 tickets for users to grab, then they can put these 100 tickets in the cache and do not lock them when reading and writing. When the amount of concurrency is large, about 500 people may successfully grab tickets, so that requests after 500 can be directly transferred to the static page at the end of the event. It is impossible for 400 out of 500 people to get the goods. Therefore, only the first 100 people can purchase successfully according to the order in which they enter the
queue
. The next 400 people will go directly to the event end page. Of course, entering 500 people is just an example. You can adjust the number yourself. The activity end page must use a static page, not a database. This reduces the pressure on the database. Option 2: When there are multiple servers, it can be implemented in the form of offloading
Suppose there are m tickets, n product servers receive requests, and x requests are forwarded randomly by the routing server
Directly Allocate m/n tickets to each product server
Make
counter
in the memory of each product server, for example, allow m/n*(1+0.1) people to come in. When the memory
counter
is full: People who enter later will jump directly to the static page where the activity ends,
notify the routing server that it will no longer be routed to this server (this is worth discussing).
The m/n*(1+0.1) individuals who come in from all the product servers are then forwarded to a payment server and enter the payment process to see who is faster. There are few people at this time, so locking and so on is simple.
Option 3. If it is a single server, you can use Memcache lock to implement
product_key is the ticket key
product_lock_key is the ticket lock key
When product_key exists in memcached, all users can Enter the order process.
When entering the payment process, first store add(product_lock_key, “1″) in memcached,
If the return is successful, enter the payment process.
If it fails, it means that someone has already entered the payment process, and the thread waits for N seconds and performs the add operation recursively.
Option 4: Use file exclusive lock
When processing an order request, use flock to lock a file. If the lock fails, it means that other orders are being processed. At this time, either wait or directly prompt the user "Server is busy" "
This article is going to talk about the fourth solution. The approximate code is as follows
Blocking (waiting) mode:
Non-blocking mode:
The above introduces PHP's ideas and methods to solve blocking high-concurrency inventory prevention and control overflows such as rush buying, flash sales, property grabbing, lottery, etc., including queues, flash sales, number of people, and counters. I hope friends who are interested in PHP tutorials can helped.
