Design e-commerce seckill system

One 、 background

technology

• Technical team  Java  Technology oriented

• Microservices have been launched

• At present, single room

• Yes  APP  Follow wechat applet , Requires only  APP  Users can participate in the second kill

Business

• Selling goods  <=10&nbsp; Categories  *20&nbsp; A commodity

• This second kill &nbsp;2&nbsp; A commodity （1000&nbsp; A power bank 、10&nbsp; platform &nbsp;iphone12）

• The normal daily life is about &nbsp;100w&nbsp; user

• At present, there are only single rooms

• The boss needs to be foolproof

Two 、 Business analysis

This second kill  2  A commodity （1000  A power bank 、10  platform  iphone12）,  Second kill orders generated  1000+10 = 1010  individual .

Millions a day , It is estimated that participating in the second kill may be the usual traffic  1.5~2  times .

The boss needs to be foolproof , We need to sort out the core processes , Ensure the availability of core processes .

3、 ... and 、 Design ideas

• Do a good job of isolation ： Including seckill service isolation 、 Isolation of middleware . Deploy the service cluster separately , Prevent the collapse of other services .

• Multi layer current limiting ： Make sure you arrive &nbsp;DB&nbsp; Layer can be in controllable flow .

• Try to cache ： Preheat the goods to the cache in advance , Including inventory data .

• High availability design ： Including current limiting 、 line up 、 Downgrade 、 Fuse .

Storage architecture design

Not a lot of data , Because it's second kill  2  A commodity （1000  A power bank 、10  platform  iphone12）, Only a thousand pieces of seckill data have been generated .

Mysql  Just be an active standby .

Redis  Mainly cache , Search seckill product information

6、 ... and 、 Computing architecture design

6.1、 Load balancing design

Because the daily life of the system has  100w, The second kill is assumed to be normal  1.5  times ~2  times .LVS  Can resist dozens of  w  Concurrent , Through the front-end plus legitimacy verification （ For example, verification code , Anti robot ）, arrive  LVS  It can resist all legal traffic .

6.2、 Cache design

7、 ... and 、 High availability design

In order to ensure the high availability of the interface , General idea points ：1、 Current limiting + line up  2、 Fuse + Downgrade

7.1、 Current limiting design

All links requested by users can be current limited ：

• 1、 Current limit at the requester ： Limit the current when making a request , Requests that are throttled are not actually sent to the back-end server

• 2、 Current limiting at the access end ： Conduct current limiting when receiving a service request , Avoid requests going into the actual business process

• 3、 A single service protects itself , If there are too many requests , New requests can be discarded

7.2、 Queuing design

Description of each role ：

• 1、 Queuing module . Use &nbsp;Kafka&nbsp; Message queue , Save the request first in first out , The size of the queue can be more than that of the second kill commodity .

• 2、 Scheduling module . Test according to the processing capacity of seckill service , Ability to handle , Put the messages in the queue under the seckill service .

• 3、 Other services . Real business processing module , If you place an order 、 Close the deal .

7.3、 Degraded design

The degraded service is mainly to give priority to ensuring the normal core business , For example, the order trading service of secsha is guaranteed to be normal . Other services are degraded as appropriate .

7.4、 Fuse design

In order to prevent fault chain west effect , Play the self-protection of service