Second kill design of 100 million level traffic architecture

1 brief introduction

I have written a lot of articles on billion level traffic , In the middle, we talked about various treatment ideas , Here we combine these ideas with the business , Situation one is the second kill , When it comes to second kill , Many people will think that this is a matter of high technical requirements , Because it involves a lot of traffic ( It's possible that tens of millions of users will visit the product instantly )、 Maintain data consistency ( Not oversold ), The former has very high performance requirements , The latter just lowers the performance , This article talks about the design idea of seckill , At the end of the paper, a simple model of seckill design is given .

2 Second kill scene

There are many second kill scenes in life , For example, business promotion , Like one yuan for Maotai , Fifty cents for BMW ( Here's just an example ), If a million people come to rob ten bottles of Maotai , You can't sell more at this time , That is, it cannot be greater than 10 The number of people in the market is up to , Usually there is a countdown button at the last time , 30...29...28......3...2...1 GO! After that, eager people began to grab .

At this time, the following questions need to be considered :

The first is the How to keep the time of multiple clients synchronized , In other words, let us see that the time is the same , You can't show 3, And I also show that 30 .

The second is How to ensure that there are no scalpers robbing with robots .

The third is How to ensure that the back-end server can support this huge traffic .

3 Second kill solution

With the above scenario and the questions , Let's take a look at the design idea of the seckill scheme , How do our servers respond to this million dollar TPS Well ?

The first thing I think of is expansion , For details, please refer to Server expansion ideas and problem analysis , But it's not realistic , Because expansion needs a lot of machines , TPS The increase of 10000 times requires more than 10000 times the performance of physical servers , In addition, for a business , It's not cost-effective to buy a server for this promotion , At ordinary times, there are bound to be many machines in idle state .

No way to expand , That means using other methods , If all the requests to access a physical machine will not work , A million data accesses anyway Sub database and sub table To no avail , Because every one of them is hot data , So we need to use the idea of distributed architecture .

4 Second kill technical scheme

Distributed , Can reduce the pressure on the server , The following is the design idea of seckill .

4.1 Scheme 1

Obviously , To enable a million users to open the website of looting at the same time , It is bound to be used to CDN( Content distribution network , If you are not clear about this concept, you can refer to : Global load balancing and CDN content distribution ), CDN There are two main functions , One is to put some static resources that will not change on the edge server close to the client , In this way, when the client requests data, it can get it directly from the edge server , Reduce the pressure on the central server , On the other hand, small services can be deployed to CDN Go up to the node , such , At the beginning of the current page , In addition to telling the front end whether to start the service , It also counts how many people are online . Each small service will send back to our data center the number of people waiting for the second kill online at regular intervals , So we know how many people are online in the whole network

hypothesis , We know about 100 Tens of thousands of people are online waiting to rob , that , When we were about to start , From the data center to the various deployment in CDN Passing a probability value to a small service on a node , The probability value is CDN The weight of the number of nodes multiplied by the winning probability , For instance, 𝑒e. therefore , When the second kill starts , this 100 Ten thousand users are clicking the order button , The first thing they ask for is CDN These services on the Internet , These little services are based on 𝑒e Put users in the back of the data center , That is, put it over The number of ∗𝑒 The number of ∗e, The rest goes straight back. The second kill is over .

4.2 Option two

Using our distributed current limiter 、 Gateway and other knowledge , Filter requests layer by layer , Reduce the last request to connect to the database .

The first is to use CDN Distribute static resources to edge servers , When making a service request , Authentication first , Authentication is mainly used to screen robots and other non artificial rush buying , According to practical experience , Authentication can screen a large number of users , For example, whether to log in .

After the authentication is determined to be a real and valid user , Through load balancing ( For details, please refer to LVS Summary of load balancing theory and algorithm ) That is to say LVS+Keepalived Assign requests to different Nginx On , Generally, it will establish Nginx colony , And then through Gateway cluster , Even so, some current limiting measures should be added , If there are still many requests pressing into the database at this stage, it is bound to be unsustainable , Then you can take Service restriction 、 service degradation Etc , Carry out peak cutting treatment . Theoretically, the traffic is not high here , If it's still very high , Then put the hot data into Cache cluster To preheat , At the same time, set the timing task , On the one hand, focus on the consistency between database and cache , On the other hand, close orders that are overdue , When the order is submitted Give it to the task queue , Generate order 、 modify the database 、 Do a good job of persistence .

Architecture diagram :

This is the whole “ seckill ” Technical details of , I can't believe it ？

Similar to this kind of second kill business is 12306 Grab tickets , This is also an instant high flow , But the architecture mentioned above is not suitable for , because 12306 I don't know which train ticket the user wants to buy . I don't know the information , It's hard to filter users , And users need to have a lot of query operations before buying tickets , Then select your own ticket in the query . That means you can't filter users in the beginning .

12306 The best way to deal with it , Except don't release all the tickets at once , Instead, the tickets are released in batches at different times , So that people don't focus on one point in time to grab tickets , Human flesh separation , Can reduce some concurrency .

in addition ,12306 It's best to use pre-sale , Let's input our tickets into the system first . The system doesn't really release tickets , It's about collecting everyone's needs , Then make overall arrangement , The number of additional trains that should be increased , The car that should be added , It's going to make sure that everybody can go . Really not line , Just draw lots .

5 summary

We can see , Solve the specific business scenario of seckill , have access to CDN To carry the traffic , Then filter user requests （ Current limiting user requests ）, To protect data center systems , Only in this way can the whole second kill be carried out smoothly . You can also filter requests layer by layer as in scheme 2 , Is this kind of business scenario the same as double eleven ? If it's like a pair of 11 like that , Want to sell as much as possible ,

Then it's not like a second kill . This is to take as many orders as possible , But it can't exceed the inventory , There's also a lot of bank payments , Inventory query and distribution of each warehouse , These are very slow operations . To ensure consistency , But also to be able to carry like a pair of 11 Such large-scale concurrent access , that , What should be done ？

It's basically unscientific to use a solution like seckill . At this time, we need to seriously do high concurrency architecture and testing , Each system needs to adjust its own performance , And be careful with performance planning , We should also do a good job in distributed elastic design , Finally, keep doing performance testing , Find the system bottleneck of the whole architecture , And then continue to do horizontal expansion , To solve large-scale concurrency .

Sometimes , We're always thinking about data center solutions . Actually , We need to change our mind sometimes , Maybe , It's not necessarily the best way to solve it in a data center , It might be better to put it on the edge . Especially for businesses with regional characteristics , Like take out 、 Shared bicycle 、 Taxi business . Actually , Put some simple business logic on the edge , It's better than being in a data center , And there's a cheaper cost . I think , With more and more requests , More and more data , The data center is a bit of a bottleneck , But need edge knot I'm here to help . and , The trend of this marginalization solution will also be more and more advantageous .