preface
How to design SEC kill system under high concurrency? This is a common interview question. This question seems simple, but it is deep, it examines the high concurrency scenario, from the front end to the back end of various aspects of knowledge.
Seckill usually appears in the promotional activities of the mall, specifying a certain number of goods (such as 10) (such as mobile phone) at a very low price (such as 0.1 yuan), allowing a large number of users to participate in the activity, but only a very few users can buy successfully. This kind of activity is the vast majority of businesses do not make money, to put it bluntly is to find a stunt to promote their own.
Instantaneous high concurrency
The number of concurrent requests generally spikes a few minutes before the seckill time (for example, 12 o ‘clock), and peaks when the seckill time is reached.
But because this kind of activity is the scene of a large number of users grabbing a small number of goods, there will be a lot of meat Wolf situation, so in fact, the vast majority of users will fail to kill seconds, only a few users can succeed.
Under normal circumstances, most users will receive an alert that the item is out of stock, and after receiving this alert, they will most likely not stay on the active page, which will lead to a sharp drop in user concurrency. Therefore, the duration of this peak value is actually very short, which leads to instantaneous high concurrency. The following figure is used to intuitively feel the change of flow:
Such instantaneous high concurrency scenarios are difficult for traditional systems to cope with, so we need to design a whole new system. We can start from the following aspects:
- Page statics
- The CDN to accelerate
- The cache
- Mq asynchronous processing
- Current limiting
- A distributed lock
Page statics
The active page is the first point of entry for user traffic, so it is where the most concurrency occurs.
If all this traffic can access the server directly, I am afraid that the server will not be able to bear so much pressure, and directly hang.
The vast majority of the content of the activity page is fixed, such as: product name, product description, picture, etc. In order to reduce unnecessary server requests, active pages are typically statically processed. Normal operations, such as browsing for items, are not requested to the server. Access to the server is allowed only when the user presses the kill button at the kill time.
This will filter out most invalid requests.
But static page is not enough, because users are distributed across the country, some people in Beijing, some people in Chengdu, some people in Shenzhen, the region is far away, the Internet speed is different.
How to get users to the active page the fastest?
This requires the use of a CDN, which stands for Content Delivery Network.Users can obtain the required content nearby, reducing network congestion and improving user access response speed and hit ratio.
Seconds kill button
Most users are afraid of missing the second kill time point, generally enter the active page in advance. See the second kill button is gray, not click. Only when the second kill point is reached, the second kill button will automatically light up and become clickable.
But at this point, many users can’t wait to see the second kill button light up in the first time by constantly refreshing the page.
As you know, the active page is static. So how do we control the second kill button on a static page to only light up at the second kill point?
That’s right, use JS file control.
For the sake of performance, static resource files such as CSS, JS, and images are generally cached on the CDN in advance, so that users can access the seconds killing page nearby.
See here, some smart friends, may ask: CDN js file is how to update?
Before the seckill starts, the js flag is false and there is another random parameter.
When seckill starts, the system will generate a new JS file with a flag of true, and a random parameter will generate a new value, which will be synchronized to the CDN. Because of this random parameter, the CDN does not cache data and gets the latest JS code from the CDN every time.
In addition, a timer can be added to the front end to control, say, 10 seconds, only one request can be made. If the user clicks the second kill button once, it will be dimmed within 10 seconds and is not allowed to click it again. When the time limit expires, the user is allowed to click the button again.
Read more to write less
In the process of the second kill, the system will generally check whether the inventory is enough, if enough to allow the order, write database. If not, return that the item has been sold.
Because a large number of users grab a small number of goods, only a few users can grab success, so the vast majority of users in the second kill, inventory is actually insufficient, the system will directly return that the goods have been robbed.
This is very typical: read more than write less scenario. To reduce Mysql stress, cache Redis should be used.
The cache problem
Cache breakdown
Preheat data and set distributed locksCopy the code
The cache to penetrate
Data that does not exist in the Bloom filter and cache is nullCopy the code
Cache avalanche
The expiration time of cache data is set randomly to prevent a large number of data from expiring at the same time.Copy the code