1. If you were asked to design a flash sale system, how would you design it?
answer:
(1) Flash sale activities are usually very short-lived and have high concurrency. If deployed together with the original website, the original website may be paralyzed instantly. So I will deploy the flash sale program separately and assign an independent domain name.
(2) Before the flash sale, in order not to miss the flash sale activity, users will frequently refresh the screen, which puts a lot of pressure on the backend system. Therefore, in addition to using database clusters, redis clusters, and load balancing, the flash sale page must be static. Prevent the background system from consuming too many resources when rendering dynamic pages.
(3) During flash sales, network bandwidth must be increased in a short period of time. On the one hand, temporary bandwidth resources can be rented in the cloud. On the other hand, you can put the flash sale page on the CDN node. This will save bandwidth on the flash kill server.
(4) In order to prevent users from obtaining the URL path of the order page in advance before the flash sale, we need to dynamize the order page. For example, after the flash sale starts, the server generates random numbers with special specifications, and then saves these random numbers in on redis. Then during the flash sale, the URL address must contain these random numbers to enter the order page. This will avoid the problem of placing orders in advance before the flash sale. If the flash sale has not started, no one is allowed to enter the order page.
(5) The flash kill countdown also requires special design. Before the flash sale starts, the function of the JS file on the CDN node is to first obtain the Beijing time, and then generate a countdown clock on the HTML page. Until the flash sale starts, refresh the page and reload it into the JS file, that is, when the flash sale starts At that moment, the background program updates the content of the JS file on the CDN node. When the flash sale starts, the user's browser will automatically refresh and the latest js file can be loaded. Therefore, the js file generates a flash sale button. After the user clicks the button , js will send a flash kill request to the background program.
Let’s put it this way, no customer can initiate a flash sale request before the flash sale.
(6) The method of deducting inventory also requires reasonable design. There are currently two options for deducting inventory: The first option is to deduct inventory after payment, but problems will arise. For example, Huawei mobile phones have 100 restocks in stock, but during the flash sale, 2,000 people successfully placed orders. Then 100 people successfully paid, and the remaining 1,900 people will be prompted that there is no inventory when paying. Obviously the user placed the order successfully, but when paying, it will be prompted that there is no inventory, resulting in a very bad customer experience. So this solution is not advisable. Another inventory deduction solution is to deduct inventory when an order is placed. This situation means that the user placed the order successfully and the goods will be available when paying. There will be no prompt that there is no stock. So this is the solution I adopted. Furthermore, if the user does not pay within 10 minutes after placing the order, the system will automatically release the inventory occupied by the order.
(7) Design related to overbooking phenomenon. Optimistic locking can be used at the database level to solve this problem. Transactions can be used in redis to solve this problem.
(8) Cluster design. During the flash sale, although database clusters, redis clusters, load balancing, and CDN acceleration and other technologies were used, in the face of massive requests, we still had to limit the flow, such as introducing message queues in the background system. Block a large number of requests.
The above module is my design of the flash sale module.
2. It is easy for product flash sale activities to cause oversales. How will you solve it?
1. Before the flash sale activity starts, we first use a program (see the flash sale program I wrote in my previous article) to create an inventory record in redis. For the next flash sale program, first watch the inventory in redis and the list of users who successfully purchased the product, then start the redis transaction to deduct the inventory and record the user IDs who successfully purchased the product, and finally submit the redis transaction. If the batch processing instructions for transaction submission are sent to redis and are not queued for execution by other flash kill programs. Therefore, the redis single thread will execute the batch processing instructions submitted by the current transaction, and the inventory will be deducted without overbooking.