Video resource recommendation implemented by PHP e-commerce website product flash sale function

As we all know, for a product flash sale function with fierce traffic and extremely high stability requirements, traditional PHP technology is difficult to meet the requirements, so it requires the help of website architecture design, server configuration, load balancing, CDN acceleration, cloud analysis, redis It can be realized by various means. This course is an advanced PHP course. It mainly introduces the ideas of function implementation and does not involve the specific implementation of the code. Newbies should be careful!

Course playback address: //m.sbmmt.com/course/279.html

The teacher’s teaching style:

The lectures are friendly and natural, unpretentious, not pretentious, nor deliberately exaggerated, but talk eloquently and carefully, and the relationship between teachers and students is In an atmosphere of equality, collaboration, and harmony, silent emotional exchanges are carried out, and the desire and exploration of knowledge are integrated into simple and real teaching situations. Students gain knowledge through quiet thinking and silent approval

The more difficult point in this video is the flash sale project architecture - the data processing layer:

1 Flash Sale Business Analysis

Normal Electronics Business process (1) Query products; (2) Create orders; (3) Deduct inventory; (4) Update orders; (5) Payment; (6) Seller shipment

Characteristics of flash sale business (1 ) Low price; (2) Massive promotion; (3) Instantaneous sell-out; (4) Generally on the shelves at a scheduled time; (5) Short time, high instantaneous concurrency;

2 Flash Kill Technical Challenge

Assume that a website’s flash sale event only launches one product and is expected to attract 10,000 people to participate in the event. In other words, the maximum number of concurrent requests is 10,000. The technical challenges that the flash sale system needs to face are:

Impact on website business The Flash Sale activity is just an additional activity of website marketing. This activity has the characteristics of short time and large number of concurrent visits. If deployed together with the original application of the website, it will inevitably have an impact on the existing business and cause slight discomfort. Caution may cause the entire website to crash. Solution: Deploy the flash sale system independently, or even use an independent domain name to completely isolate it from the website.

Application and database load under high concurrency. Before the flash sale starts, users should constantly refresh the browser page to ensure that they will not miss the flash sale. If these requests follow the general website application architecture, access the application server and connect to the database. , which will cause load pressure on the application server and database server. Solution: Redesign the flash sale product page, do not use the original product detail page of the website, the page content is static, and user requests do not need to go through the application service.

Sudden increase in network and server bandwidth Assume that the product page size is 200K (mainly the product image size), then the required network and server bandwidth is 2G (200K×10000). These network bandwidths are due to the new increase in flash sale activities , exceeding the bandwidth normally used by the website. Solution: Because of the new network bandwidth added by the flash sale, you must re-purchase or lease it from the operator. In order to reduce the pressure on the website server, the flash sale product pages need to be cached in CDN, and the newly added export bandwidth also needs to be temporarily rented from the CDN service provider.

The rule of the game for direct ordering and flash sales is that you can only start placing orders for products after the flash sale. Before this time point, you can only browse product information and cannot place orders. The order page is also a normal URL. If you get this URL, you can place an order without waiting for the flash sale to start. Solution: In order to prevent users from directly accessing the order page URL, the URL needs to be made dynamic. Even the developers of the flash sale system cannot access the order page URL before the flash sale starts. The method is to add a random number generated by the server as a parameter in the order page URL, which can only be obtained when the flash sale starts.

How to control the lighting of the purchase button on the flash sale product page. The purchase button can only be lit when the flash sale starts. Before that, it is gray. If the page is dynamically generated, of course you can construct a response page output on the server side to control whether the button is gray or lit. However, in order to reduce the load pressure on the server side and make better use of performance optimization methods such as CDN and reverse proxy, this Pages are designed as static pages and cached on CDNs, reverse proxy servers, and even on user browsers. When the flash sale starts, the user refreshes the page and the request never reaches the application server. Solution: Use JavaScript script control to add a JavaScript file reference to the flash sale product static page. The JavaScript file contains the flash sale start flag; when the flash sale starts, a new JavaScript file is generated (the file name remains the same, but The content is different), update the flash sale start flag to Yes, add the URL of the order page and the random number parameters (this random number will only generate one, that is, the URL seen by everyone is the same, the server side can use redis Distributed cache server to save random numbers) and loaded by the user's browser to control the display of flash sale product pages. This JavaScript file can be loaded with a random version number (for example, xx.js?v=32353823) so that it will not be cached by browsers, CDNs, and reverse proxy servers. This JavaScript file is so small that even accessing the JavaScript file server every time the browser refreshes does not put much pressure on the server cluster and network bandwidth.

How to only allow the first submitted order to be sent to the order subsystem. Since there is only one user who can successfully flash sale the product, it is necessary to check whether an order has been submitted when the user submits the order. If an order has been submitted successfully, you need to update the JavaScript file, update the flash sale start flag to No, and the buy button turns gray. In fact, since only one user can successfully submit an order in the end, in order to reduce the load pressure on the order page server, the entrance to the order page can be controlled. Only a few users can enter the order page, and other users directly enter the flash sale end page. Solution: Assume that the order server cluster has 10 servers, and each server only accepts a maximum of 10 order requests. Before anyone successfully submits an order, if a server already has ten orders and some orders have not been processed, the possible user experience scenario is that the user clicks the purchase button for the first time and enters the completed page. If you refresh the page again, it may be processed by a server that has not processed any orders. When you enter the page for filling in orders, you can consider using cookies to deal with it, which is consistent with the principle of consistency. Of course, the least-connected load balancing algorithm can be used, and the probability of the above situation is greatly reduced.

How to check before placing an order

If there are more than 10 items, the completed page will be returned directly to the user;

If there are not more than 10 items, the user can enter and fill in the order and confirmation page;

has exceeded the total number of flash sale products, and the completed page will be returned to the user;

has not exceeded the total number of flash sale products, and is submitted to the sub-order system;

Check that the global Number of orders submitted:

The order server checks the number of order requests processed by the machine:

Flash sales are generally scheduled to be put on the shelves. There are many ways to implement this function. However, the better way at present is to set the shelf time of the product in advance. The user can see the product on the front desk, but cannot click the "Buy Now" button. But what needs to be considered is that someone can bypass the front-end restrictions and initiate a purchase directly through the URL. This requires clock synchronization on the front-end product page, as well as the bug page and the back-end database. The more control is on the back end, the higher the security. For timed flash sales, it is necessary to avoid unexpected effects caused by sellers editing the products before the flash sale. This particular change requires multiple evaluations. Editing is generally prohibited. If changes are needed, you can go through the process of data correction.

There are two options for reducing inventory. One is to take photos to reduce inventory. The other is to pay to reduce inventory. The currently adopted method of "photographing to reduce inventory" takes just a moment. The user experience will be better.

Inventory will cause the problem of "oversold": the quantity sold is more than the quantity in stock. Due to the problem of concurrent inventory updates, when the actual inventory is already insufficient, the inventory is still decreasing, resulting in the seller's product The number of units sold exceeded the flash sale expectation.

The above is the detailed content of Video resource recommendation implemented by PHP e-commerce website product flash sale function. For more information, please follow other related articles on the PHP Chinese website!