Personally design a highly concurrent seckill system

One 、 demand

1. There are a number of products , Every product has 100 Pieces of , You can buy at most one item per person .
2. stay X month X Japan X when X branch 0 Seconds to start buying . Before the appointed time , You can only see the product page , The buy button is grayed out .

Two 、 Activity estimates

1. It is estimated that tens of thousands of people will participate in each commodity
2. Within half a minute of the start of the activity , Expect each item to receive 10W This transaction request , Estimated total TPS：20W/s
3. Half a minute after the activity started , Most of the goods are expected to be sold out , The rest of the products still support seckill , Estimated total TPS：2000/s

3、 ... and 、 System status

1. The system can maintain a long-term stable operation of the maximum TPS：1000/s
2. short time 「1 Within minutes 」 The highest number of system non denial of service TPS：1500/s

Four 、 Design pre research

Scheme 1 ： Revamp the existing system , The overall number of micro service systems has increased significantly TPS

advantage ：

1. A substantial increase TPS after , The business system can directly carry a large number of transaction requests , It's easier to deal with the second kill demand .

shortcoming ：

1. The number of second kill activities is less , Transformation cost 、 Risk is bigger , Low cost performance
2. After transformation , The system architecture will be more complex , Reduced maintainability

Option two ： Develop new applications , Carrying the demand ; Transform existing applications to support new ones

advantage ：

1. The transformation of the existing business system is small , The cost is low .
2. Use the new application to carry the second kill transaction request , High flexibility , Don't think too much about backward compatibility .

shortcoming ：

1. The user experience needs to be sacrificed to a certain extent .

Conclusion

Based on cost and feasibility considerations , Scheme 2 is adopted

5、 ... and 、 Architecture design

5.1 Existing architecture design

1. The foreground application directly undertakes user access 、 Transaction request , nothing CDN service .
2. After the foreground application receives the transaction request , direct RPC Synchronous request middle application
3. After the middle application receives the transaction request , Synchronous completion of order creation 、 payment 、 Number of goods deducted 、 Complete business processes such as transactions
4. The front application receives the processing result of the middle application , Show users the logistics information of trading goods .

5.2 Latest architecture design

5.2.1 Architecture design at a glance

5.2.2 Service module design

1. front end 、 The client discards the transaction request randomly

1. According to the number of times users view the product details page , Estimate the popularity of the product , Set different discard ratios for different products , Design fields ：discard, The value is [0, 100), As a commodity attribute .
2. front end 、 client , When a user submits a transaction request , Generate [0, 100] Random numbers in the range ,discard < Orders with random numbers are discarded directly , But show users the queuing page , line up 10 Seconds later, the transaction failed .

2. Provide CDN service

1. Static resources are preserved CDN In service
2. Special seckill page displayed on the front end , except 「 The deal was initiated 」 Out of request , No user's operation will be requested to the company's microservice business system .

3. Develop specialized 「 Second kill app 」, Provide fusing service

1. The seckill application directly carries the front end 、 Transaction request from client , The authorization request is sent to the foreground application for processing , Authorization denied requests are intercepted directly , Return transaction failed .
2. Second kill application through configuration center , Get the latest configuration in real time . Configurable discard ratio for transactions , Development colleagues in the second kill period , Adjust configuration , Guarantee transaction requests to business systems ,TPS Stay in 10000/s within .
3. Seckill application has no database , No state , After horizontal expansion, the throughput can be increased proportionally .

4. The existing business system optimizes throughput

1. The front desk 、 In the middle of the application , Optimize the throughput by optimizing the design , There are the following optimization methods ：
   • Adopt the horizontal splitting method of sub database and sub table , Scale out the database , It can also be greatly increased at this time POD Count
   • Static data is cached in Redis in , Data from Redis To take , Ensure that the database will not be read , Background scheduled task update cache .「 Ensure that the cache is updated regularly without cache breakdown 」
2. Library sub-table policy ：
   • Split database and application according to commodity
   • According to the user id Second split database and application
3. After the above optimization , At least the short-term development of the middle platform business system can be realized 「1 Within minutes 」 The highest number of system non denial of service TPS, from 2000/s Up to the 4000/s
4. Because the foreground application logic is simple ,TPS It can be promoted to 10000/s, No need to optimize .
5. Because of the barrel effect , The short time of the whole business system 「1 Within minutes 」 The highest number of system non denial of service TPS, by 4000/s

5. Asynchronous queues

1. The foreground application efficiency is high , Just optimize the mid platform application here .
2. The foreground application sends all the second kill transaction requests to Kafka, The application of the middle platform is through Kafka News consumption , Carry out the actual business processing .
3. As the peak period of business is only half a minute at most ~ 1 minute , The middle platform is used in 2 It's acceptable to process all the transactions in about minutes .
4. Kafka Of TPS For dozens of W/s, The front desk 5000/s ~ 10000/s Of TPS No pressure .
5. After this optimization , The short time of the whole business system 「1 Within minutes 」 The highest number of system non denial of service TPS, Can be obtained from 4000/s Up to the 10000/s

shortcoming ： In extreme cases , The deal will be slow .

6. service degradation

1. Half an hour before the start of the second kill to half an hour after the end of the second kill , In this time period , Some services are degraded
2. Within the time frame , Don't show logistics information 、 Invoice generation and display are not supported , Ensure the stability of the core business system