Decrypt redis to help the e-commerce seckill system behind the double 11

Click on the top “ Terminal R & D department ”

 Set to “ Star standard ”, Master more database knowledge with you 

source ：t.cn/EAlQqQD

• background

• The characteristics of second kill

• Seckill system

background

Second kill is the low price promotion selected by most e-commerce , The way to promote the brand . It can bring users to the platform , It can also improve the popularity of the platform . A good second kill system , It can improve the stability and fairness of the platform system , Get a better user experience , Improve the reputation of the platform , So as to enhance the maximum value of second kill activities .

This article discusses cloud database Redis Version cache design high concurrency seckill system .

The characteristics of second kill

Second kill activities sell scarce or special priced goods regularly and quantitatively , Attract a large number of consumers to rush to buy , But only a small number of consumers can order successfully . therefore , The second kill activity will produce dozens of times larger than usual in a certain period of time , Hundreds of times of page access traffic and order request traffic .

Second kill activities can be divided into 3 Stages ：

• Before the second kill ： Users constantly refresh the product details page , The page request has reached the temporary beginning .

• The second kill begins ： The user clicks the second kill button , The order request is temporarily advanced .

• After the second kill ： Some users who successfully place orders constantly refresh orders or generate chargeback operations , Most users continue to refresh the product details page and wait for the chargeback opportunity .

Orders submitted by consumers , The general approach is to use the row level lock of the database , Only the lock grabbing request can be used for inventory query and order placement . But in the case of high concurrency , The database cannot afford such a large request , Often the entire service needs to be blocked , In the eyes of consumers, it is server downtime .

Seckill system

Use the hierarchy of the system , Revalidate in advance at each stage , Intercept invalid traffic , It can reduce the influx of a large number of invalid traffic into the database .

Use browser caching and CDN Compressive static page traffic

therefore , We need to separate the second kill product details page from the ordinary product details page . The details page about seckill products attempts to staticize elements that can be staticized , In addition to the second kill button, the server needs to make dynamic judgment , Other static data can be cached in browsers and CDN On . such , Only a small part of the traffic into the server caused by refreshing the page before the second kill .

Use reading separation Redis Cache intercepts traffic

CDN Is the first level of traffic interception , In the second level of traffic interception, we use a system that supports read-write separation Redis. At this stage, we mainly read data , Read separation Redis Can support up to 60 All the above qps, It can fully support the demand .

First, through the data control module , Cache seckill products to identifier separation in advance Redis, And set the second kill start flag as follows ：

"goodsId_count": 100 // total 
"goodsId_start": 0   // Start marker 
"goodsId_access": 0  // Accept the next singular 

1. Before the second kill , Service reread goodsId_Start by 0, Return directly to not started .

2. The data control module will goodsId_start Change it to 1, Mark the start of the second kill .

3. The service maximizes the cache start flag bit and starts accepting requests , And record the redis in goodsId_access, The remaining quantity of goods is （goodsId_count-goodsId_access）.

4. When the next singular number reaches goodsId_count after , Continue to intercept all requests , The remaining quantity of goods is 0.

It can be polished , Finally, only a few requests for successful participation in the order can be accepted . In the case of high concurrency , Allow a little more traffic to enter . Therefore, the proportion of accepting singular numbers can be controlled .

Use the master-slave version Redis Cache accelerated inventory deduction

Successfully avoid placing an order , Enter the lower service , Start order information verification , Inventory deduction . To avoid direct access to the database , We use master-slave Redis To deduct inventory , Master-slave version Redis Provide 10 Ten thousand grade QPS. Use Redis To optimize inventory query , Intercept the failed second kill request in advance , It will greatly improve the overall stability of the system .

The inventory is stored in advance through the data control module Redis, Put every second kill commodity in Redis One in hash Structural representation .

"goodsId" : {
    "Total": 100
    "Booked": 100
}

When deducting the amount , The server requests Redis Get the qualification to place an order , By lua Script implementation , adopt Redis It is a single-threaded model ,lua It can ensure the atomicity of multiple commands .

local n = tonumber(ARGV[1])
if not n  or n == 0 then
    return 0
end
local vals = redis.call("HMGET", KEYS[1], "Total", "Booked");
local total = tonumber(vals[1])
local blocked = tonumber(vals[2])
if not total or not blocked then
    return 0
end
if blocked + n <= total then
    redis.call("HINCRBY", KEYS[1], "Booked", n)
    return n;
end
return 0

First use SCRIPT LOAD take lua Script EVALSHA Pre cached in Redis, Then call the call script , Than calling directly EVAL Save network bandwidth ：

redis 127.0.0.1:6379>SCRIPT LOAD "lua code"
"438dd755f3fe0d32771753eb57f075b18fed7716"
redis 127.0.0.1:6379>EVAL 438dd755f3fe0d32771753eb57f075b18fed7716 1 goodsId 1

Second kill service through judgment Redis Whether to return the number of rush purchases n, You can know whether the request is successful .

Use master-slave Redis Realize simple message asynchronous order warehousing

If the quantity of goods decreases , You can operate the database directly . If the second kill commodity is 1 ten thousand , even to the extent that 10 Ten thousand , The database lock conflict will bring great performance advantages .. therefore , Use message components , When the seckill service writes the order information into the message variable , It can be considered that the order is completed , Avoid operating the database directly .

1. Message module components can still be used Redis Realization , stay R2 Is represented by a list data structure .

```java
     orderList {
         [0] = { Order content }
         [1] = { Order content }
         [2] = { Order content }
         ...
     }

1. Write the order content to

```java
    LPUSH orderList { Order content }

1. The preliminary order module starts from Redis Get order information in sequence , Write the order to the database .

```java
     BRPOP orderList 0

By using Redis As a message transceiver , Asynchronous processing of order receipt , It effectively improves the completion speed of users' orders .

The data control module manages the second kill data synchronization

In the beginning , Use recognition to separate Redis Limit traffic , Let only part of the flow enter the order . For order inspection failure and chargeback, etc , Need to let more traffic in . therefore , The data control module needs to calculate the data in the database regularly , Sync to master / slave Redis, At the same time, resynchronize to read-write separated Redis, Let more traffic come in .

Today's good article recommendation

GitHub It's very practical 40 Open source JAVA project

XShell It's too expensive ？ Try open source NuShell, To use ！

GET and POST What is the essential difference between requests ？ After reading it, I feel too ignorant ...

MyBatis Bulk insert data you're still using foreach？ Your server didn't crash ？

I'm looking at one less bug