Shulou(Shulou.com)06/03 Report--

Preface

Recently, I have shared the overall idea of doing flash sale activity in e-commerce business within the department, and everyone's feedback on this sharing is not bad, so I simply tidied it up and shared it for your reference.

Business introduction

What is a second kill? In popular terms, it is the online time-limited rush buying activities organized by online merchants for sales promotion and other purposes.

For example, JD.com second kill, is a fixed-time quantitative second kill, within a specified period of time, no matter whether the product is finished or not, the flash sale activity of the show will end. This kind of second kill is not particularly strict with time, as long as it is done quickly, the probability in the second is still relatively large.

Taobao has done an one-yuan rush to buy before, usually a limited number of goods, while the price is as low as "hair-raising". This kind of second kill is generally snatched up within 1 to 3 seconds. Participating in this second kill usually depends on luck. You don't have to be too forced.

Business characteristics

Large instantaneous concurrency

During the second kill, a large number of users will rush to buy at the same time, and the number of instantaneous concurrent visits will suddenly increase by 10 times, or even more than 100 times.

Low inventory

Generally speaking, the volume of flash sale activity goods is very small, which results in only a very small number of users who can successfully buy it.

Business is simple

The process is relatively simple, usually placing orders, withholding inventory and paying orders.

Technical difficulties

The impact of existing business

Second kill is one of the marketing activities. if it is deployed on the same server as other marketing activities, it will certainly have an impact on other existing activities. in extreme cases, it may lead to service downtime of the entire e-commerce system.

Place an order directly

The order page is a normal URL address, which needs to be controlled before the second kill starts. You cannot place an order and can only browse the information of the corresponding active goods. Simply put, you need the Disable order button

A sudden increase in page traffic

Before and after the start of flash sale activity, many users will request the corresponding product page, which will cause a sudden increase in the traffic of the background server and the corresponding network bandwidth. The need to control the flow of the commodity page will not cause excessive pressure on the background server, DB, Redis and other components.

Architecture design idea

Current limit

As the amount of active inventory is generally very small, only a small number of users can succeed in seconds. Therefore, we need to limit most user traffic and allow only a small amount of user traffic to enter the back-end server.

Peak clipping

At the beginning of the second kill, there will be a large number of users coming in, so there will be an instant traffic peak at the beginning. How to flatten the instantaneous peak flow is a key factor in the successful design of the second kill system. To realize peak cutting and valley filling, cache and MQ middleware are generally used to solve the problem.

Async

In fact, second kill can be treated as a highly concurrent system. At this time, we can consider doing business compatibility, designing synchronous business as asynchronous processing tasks, and improving the overall usability of the website.

Caching

The bottleneck of the second kill system is mainly reflected in the process of placing orders and deducting inventory. OLTP databases are mainly used in these processes, such as MySQL, SQLServer, and Oracle. Because the storage structure of B + tree is adopted at the bottom of the database, the efficiency of random writing and reading is relatively low. If we migrate part of the business logic to the memory cache or Redis, it will greatly improve the concurrency efficiency.

Overall architecture

Client optimization

There are two main problems in client optimization.

Second kill page

Many users actually visited the page before flash sale activity started. If some of the resources on this page, such as CSS, JS, pictures, product details, and so on, visit the back-end server, or even DB, the service will definitely be unavailable. So in general, we will static the page as a whole, and distribute the static page to the CDN edge node, which plays the role of pressure dispersion.

Prevent orders from being placed in advance

The main way to prevent early order issuance is to add a reference to the JS file in the static page, which contains the tag whether the activity starts or not and the URL parameter of the dynamic order release page at the beginning. At the same time, the JS file will not be cached by the CDN system, and the back-end service will always be requested, so the JS file must be very small. When the activity is about to start (for example, in advance), modify the JS file through the background interface to make it effective.

Optimization of API access layer

Client-side optimization can be prevented for users who are not engaged in computers. However, users with a certain network foundation will not play a role, so the server also needs to add some corresponding control, can not trust any operation of the client. General control can be divided into two categories.

Limit the access frequency of user dimensions

For the same user (Userid dimension), do page-level caching, uniformly walk the cache and return the same page for requests within the unit time.

Limit the access frequency of commodity dimensions

When a large number of requests query the same product at the same time, you can do page-level caching. No matter who visits it next time, as long as it is this page, it will be returned directly.

SOA service layer optimization

The above two layers can only restrict the access of abnormal users. If flash sale activity operates well and many users participate, it will cause excessive system pressure or even downtime, so back-end flow control is needed.

The control of the back-end system can be solved by message queue, asynchronous processing, improving concurrency and so on. For requests that exceed the system water level, directly adopt the "Fail-Fast" principle and reject it.

Second kill overall flow chart

The core of the second kill system lies in layer by layer filtering, gradually reducing the instantaneous access pressure and reducing the final impact on the database. Through the above flow chart, you will find out where the most stressful place is.

For MQ queuing service, as long as the MQ queuing service can withstand, you can control the pressure of placing orders and deducting inventory. According to the pressure of the database, you can customize the number of order consumers to avoid excessive consumer data, resulting in excessive database pressure or direct downtime.

Inventory service is designed to provide inventory management for second-killed goods to lock inventory in advance and avoid overselling. At the same time, through the overtime processing task, it is found that the goods have been grabbed but not paid, and after the specified payment time, processing these orders will restore the corresponding inventory of the order goods.

Summary

Core idea: layer by layer filtering

Intercept requests upstream as far as possible, reduce downstream pressure, make full use of cache and message queue, improve request processing speed and the role of peak cutting and valley filling, refer to the way to optimize business architecture.

"http://www.infoq.com/cn/articles/flash-deal-architecture-optimization" Internet second kill service design "https://baijia.baidu.com/s?old_id=108134" High concurrent second kill system architecture design "https://zhuanlan.zhihu.com/p/25368538"

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.