During an interview with Ali, I was asked how to design a spike system

Spike activity architecture

The spike activity is a common activity in e-commerce projects. For example, concert tickets are snapped up, and Jingdong Taobao rushes for merchandise. At the moment of panic buying, there will be a large number of users simultaneously requesting the application system with high concurrency, which may reach tens of thousands or hundreds of thousands of requests per second. If the system cannot handle such a high request, it will crash and cause the system to become unusable.

For the spike activity, it is required that the system does not appear to be over-stressed and collapsed, and there is no oversold or undersold situation.

So in the spike system we need to think about:

  • How does the system handle high concurrent requests

  • How does the system ensure that it is not oversold and other issues

My solution to this is:

  • On the server side, use cache to reduce database access

  • Block the request traffic upstream, you can use current limiting technology

  • Use distributed queues for traffic peak clipping and serialize concurrency

Spike architecture diagram

The spike architecture diagram is as above.

Client

The port where the user initiates the request. At present, the main clients of the e-commerce project spike activity include WeChat applet, H5 (browser), and various platform apps (such as Android, iOS, Windows). We can implement a current limiting mechanism on the client side, so that users can avoid sending a large number of requests to the server side.

The client's current limit can control the click frequency of the button, such as graying the button.

Reverse proxy

We can use Nginx to implement request shunting and evenly distribute requests to different web nodes through load balancing.

Nginx can also be used as a current limiter. Nginx can control the number of requests per unit time and limit the number of connections at the same time.

API gateway

If the actual number of users participating in the spike activity is very large, the concurrent requests are very large. We need to limit the flow in the API gateway layer, where the maximum number of requests per second can be limited to a single web node.

We can also control the maximum number of requests per user, and record the number of requests per user through Redis.

Cache

In the service layer business, in order to reduce access to the database, a cache design is required. We can use local cache or distributed cache.

queue

The queue is mainly used to achieve peak-shaving and valley-filling of traffic. We can use message middleware such as RocketMQ and Kafka as distributed queues.

About current limiting

Why is the current limit required in the spike system? In the spike activity, the inventory of goods is limited, and the number of users requested is far greater than the inventory of goods. Most of the user requests are actually unable to grab the invalid traffic of the product. Therefore, this part of the traffic can be intercepted and limited upstream.

In order to prevent users from using scripts or frequently clicking to send a large number of requests, causing other users to be unable to participate in activities normally, we also need to control the number of requests per second by users.

We can implement current limiting from both URI and user aspects.

URI current limiting sample code:

Sample code for current limiting in the user dimension:


We obtain the current limiter object in the URI dimension and the current limiter object uriLimiterin the user dimension userLimiter. If the tryAcquire()permission is successfully obtained, the request is passed and the follow-up business is entered. Otherwise, an exception will be reported directly, and the front-end interface will make corresponding friendly prompts.

Deduct inventory in the cache

Use Redis to store the inventory quantity. When a user initiates a rush purchase request, first determine whether the inventory in Redis is available. If available, put the rush request into the distributed queue, process subsequent operations in an asynchronous manner, and complete the order. At the same time, make inventory deduction in Redis.

The sample code is as follows:

First do inventory deduction and get the deducted inventory quantity. If the inventory quantity is greater than or equal to 0, send the order creation request to mq. Otherwise, it will return the message that the purchase failed.

The consumer creates an order:

How to initialize inventory?

Before the start of the panic buying activity, some operators manually synchronize the commodity inventory from the database to the cache in the background. The deduction of inventory is deducted in the cache.

The single-threaded feature of Redis can be used to achieve safe inventory updates under multiple threads. If the value in the cache is not found when querying the value, it needs to be queried from the database and then synchronized to the cache. This process needs to be locked.

The sample code is as follows:

to sum up

The spike design is a typical high-concurrency system. The design of the spike system is often asked in interviews. When designing the spike system, we need to consider:

  • Request shunting-through load balancing

  • Current limit-using funnel algorithm (such as guava RateLimiter), semaphore Semaphore, Redis counting, etc.

  • Redis deducts inventory-reduces access to the database

  • Traffic peak clipping-distributed queue implementation

Alright, this is the end of this article, I hope this article is helpful to you.

Recommended in the past

Scan the QR code to get more exciting. Or search Lvshen_9 on WeChat , you can reply to get information in the background

1.回复"java" 获取java电子书;

2.回复"python"获取python电子书;

3.回复"算法"获取算法电子书;

4.回复"大数据"获取大数据电子书;

5.回复"spring"获取SpringBoot的学习视频。

6.回复"面试"获取一线大厂面试资料

7.回复"进阶之路"获取Java进阶之路的思维导图

8.回复"手册"获取阿里巴巴Java开发手册(嵩山终极版)

9.回复"总结"获取Java后端面试经验总结PDF版

10.回复"Redis"获取Redis命令手册,和Redis专项面试习题(PDF)

11.回复"并发导图"获取Java并发编程思维导图(xmind终极版)

Another: Click [ My Benefits ] to have more surprises.

Guess you like

Origin blog.csdn.net/wujialv/article/details/109065099