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

This article will explain in detail how to use Redis to easily implement the second kill system, the content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Architecture design of second kill system

The second kill system is a typical short-term and large number of sudden access problems. There are three ways to optimize performance for this type of problem:

Write to memory instead of to hard disk

Asynchronous processing instead of synchronous processing

Distributed processing

With these three tricks, no matter how heavy the load is, you can easily deal with it. Even better, Redis can meet the above three points. Therefore, the second kill system can be easily realized with Redis.

With my plan, whether it is the special price of e-commerce platform, 12306 train tickets, it is not a thing:)

Here's why the above three performance optimization ideas can solve the performance problem of the second kill system:

Write to memory instead of to hard disk

The read and write performance of traditional hard drives is quite poor. SSD hard drives are 100 times faster than traditional hard drives. The memory is more than 10 times faster than the SSD hard drive. Therefore, writing to memory instead of writing to the hard disk can increase the ability of the system thousands of times. In other words, it turns out that your second kill system may need 1000 servers to support, but now one server can handle it.

You may have the question: write to memory instead of persistence, so if the computer goes down at this time, won't all the written data be lost? If you are so unlucky to encounter a server outage, you will not have a second. What's the big deal?

Finally, when the second kill order is really processed later, we will persist the information to the hard drive. So critical data is not lost.

Redis is a caching system, data is written to memory and returned to the client, can support this feature.

Asynchronous processing instead of synchronous processing

Systems with large concurrency such as second kill have an obvious peak and a long-term trough in the performance load. It is quite uneconomical to prepare a large number of servers to deal with large concurrency in a relatively short period of time.

Therefore, to deal with the requirement of second kill, synchronous should be turned into asynchronous. It is returned immediately after the user requests to write to memory. In the background, multiple threads are started to read data asynchronously from the memory pool for processing. If the user request may be entered within 1 second, the actual processing of the system may take 30 minutes to complete. Then the processing power of a server in the case of asynchronism is more than 1800 times higher than that in the case of synchronization!

Asynchronous processing, usually implemented using MQ (message queuing). Redis can be seen as a high-performance MQ. Because all of its data are read and written in memory.

Distributed processing

Okay. Maybe you have a lot of customers, and even if you use the above two tricks, the second kill system is still stretched. It doesn't matter, we have another big trick: distributed processing. If one server can't hold the second kill system, use a few more servers. Ten won't work, just get on 100. Distributed processing is to distribute the requests of a large number of users to multiple servers. Hash is generally used to achieve uniform distribution.

There are already many such systems in big data's cloud computing era. It is nothing more than using Paxos algorithm and Hash Ring.

Redis Cluster is such a distributed product.

Using Redis to implement description system

Redis and Redis Cluster (distributed version) are a distributed caching system. It supports multiple data structures as well as MQ. Redis has made a lot of performance optimizations. So you can easily implement a powerful second kill system using Redis or Redis Cluster.

Basically, you can use these commands from Redis.

RPUSH key value

Insert a second kill request

When the number of second kill requests inserted reaches the limit, all subsequent insertions are stopped.

Start multiple worker threads in the background, using the

LPOP key

Read the user id of the successful person in seconds and carry on the subsequent processing.

Or use the LRANGE key start end command to read the id of the user who killed the successful person in seconds for subsequent processing.

Each time the processing of a second kill record is completed, INCR key_num is executed. Once all the inventory has been disposed of, the second kill of the item will be ended, the worker thread will be closed, and the second kill request will no longer be received.

What should I do if I can't hold on?

You might say that we have a lot of clients. Even if Redis Cluster is deployed, it still can't hold up. What are we going to do?

I remember a great man once said: there are always more ways than difficulties!

Below, let's analyze in detail what other circumstances will overwhelm our second-kill system on Redis (Cluster).

Script attack

For example, there are many software for grabbing train tickets. They automatically initiate http requests. A client initiates many requests a second. If many users use such software, it may directly crush our switch.

This problem actually belongs to the scope of the network problem, and our second kill system is not on the same level. Therefore, it is not up to us to solve the problem. Many switches have the ability to prevent too many requests from one source IP. There are also many open source software that can achieve this. For example, TC on linux can be controlled. The popular Web server Nginx (which can also be thought of as a seven-layer softswitch) can also be configured to do this. An IP, I allow you to visit me twice in a second, other software packages are lost directly to you, can you still crush me?

The switch won't hold up.

Maybe your customers have so many concurrent visits that the switch can't hold up.

There's a way. We can use multiple switches to serve our second kill system.

The principle is that DNS can return multiple IP for a domain name, and for different source IP, the same domain name returns different IP. Such as Netcom user access, return to a Netcom room IP; telecom user access, return to a telecommunications room IP. That is to say, CDN!

We can deploy multiple switches to serve different users. Through these switches, users access the Redis Cluster in the back data center for second kill jobs.

On how to use Redis to easily achieve the second kill system to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.