preface

The structure of this article is simple:

5 pictures send you 5 seconds to kill the system, and then add SAO operation, and then take some heart 🤷♀️.

A simple seckill system

Implementation principle: Inventory reduction through the Redis atomic operation

FIG. 1

advantages disadvantages
Simple to use Test redis service ability
Whether fair
fair
First come first served basis

We call this type of seckill system:

Simple seckill system

If the INITIAL QPS is not high, Redis can completely resist the situation down, can rely on the “simple seckill system”.

An adequate seckill system

Implementation principle: service memory flow limiting algorithm + Redis atomic operation inventory reduction

Figure 2

advantages disadvantages
Simple to use –
Whether fair
It’s not very fair
Relatively first come, first served

We call this type of seckill system:

Enough for the seckill system

A better performance seckill system

Implementation principle: service local memory atomic operation destocking

Where does the inventory for serving local memory come from?

The inventory of each machine is allocated before the event and pushed to the machine.

FIG. 3

advantages disadvantages
A high performance Dynamic scaling (during an activity) is not supported because the inventory is allocated before the activity begins
Release the pressure on Redis –
Whether fair
It’s not very fair
It’s not always first come, first served

We call this type of seckill system:

Prepare inventory seckill system

Supports dynamically scalable seckill system

Implementation principle: service local Coroutine timing Redis atomic operation to reduce part of the inventory to local memory + service local memory atomic operation to reduce inventory

FIG. 4

advantages disadvantages
A high performance –
Release the pressure on Redis –
Support for dynamic scaling (during activity) –
Generality –
Whether fair
It’s not fair, but it’s better
Almost first come, first served

We call this type of seckill system:

Real-time reserve inventory seckill system

Fair seckill system

Implementation principle: service whether local Goroutine timing synchronization is sold out to local memory + queue + queue successful rotation (or active Push) results

Figure 5

advantages disadvantages
A high performance High development cost (need to actively inform or train queuing results)
Really fair –
Generality –
Whether fair
Very fair
It’s absolutely first come, first served

We call this type of seckill system:

Fair queuing seckill system

SAO operation

Isn’t the seckill system up there perfect enough?

Answer: Yes.

Where is the room for optimization?

Answer: Static interface for obtaining seckill activity information.

What does statics mean?

Answer: such as seconds kill activity information through interfaces, https://seckill.skrshop.tech/v1/acticity/get. Now, we need the interface to get via https://static-api.skrshop.tech/seckill/v1/acticity/get. What’s the difference? See the following:

The service name interface Data storage location
Seconds kill service Seckill. Skrshop. Tech/v1 / acticity… Seckill service memory or Redis etc
Interface static service The static – API. Skrshop. Tech/seckill/v1 /… CDN, local file

It used to be

It turns into something like this

Results: through interface https://static-api.skrshop.tech/seckill/v1/acticity/get to kill activity information, traffic is to share the CDN, seconds kill service itself didn’t this part of the load.

Whisper point say: “seconds kill result I also dare to push CDN😏😏😏.”

Note: Later we will share how to design a good "interface static service" with Golang.Copy the code

conclusion

Above, we get the following types of seckill systems

Seconds kill system
Simple seckill system
Enough for the seckill system
Prepare inventory seckill system
Real-time reserve inventory seckill system
Fair queuing seckill system

What I want to say is that there is no best solution, there is no worst solution, only what works for you.

Take first come first served, must see your product external publicity, do not chase absolute first come first served. In fact, if you look at all the schemes, relatively speaking, they are “first come, first served”. For example, if you come to the event one hour after the start of the event, you will naturally not be able to rob, compared with punctual users, right?

Such as reserve inventory seconds kill system, although does not support dynamic expansion capacity. But if your environment meets any of the following conditions, it is perfectly adequate.

  • Seckill scenes end quickly, usually in a few seconds, and the following can happen in real life:
    • Service pressure is not hanging: there is no time to dynamically expand capacity
    • Service pressure has been suspended: the activity can be suspended first, service up & after capacity expansion, push again with the remaining inventory
  • O&m does not have the capacity for dynamic expansion

So:

Fit and use the line, do not overdesign.

The last

This is the old Ben out of the mouth, really panic.

[Skr Shop] Project address Long press to enter: github.com/skr-shop/ma…

Skr Shop Series more articles:

  • SkrShop | shopping cart design of requirement analysis
  • The architectural design of SkrShop | a shopping cart
  • SkrShop | system design of general drawing tools
  • SkrShop | general demand analysis of drawing tools
  • SkrShop | coder, you can design the trading system (work)?
  • SkrShop | coder, you can design the trading system (concept)?
  • SkrShop | third-party payment process analysis and summary
  • SkrShop | electrical design manual of basic goods information
  • SkrShop | electric business users of the system design manual