Easy-to-use Redis system for second-kill

Architecture design of second-kill system

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

write memory instead of writing to hard disk, asynchronous processing instead of synchronous processing, distributed processing.

With these three strokes, no matter how much load the second kill, you can easily handle. Better yet, Redis is able to meet the above three points. This makes it easy to implement a second-kill system with Redis.

Here is why the above three performance optimization ideas can solve the performance problem of the second-kill system: Write memory instead of writing to the hard disk: the traditional hard disk read and write performance is quite poor, SSD hard disk than the traditional hard drive 100 times times faster, and the memory is more than the SSD hard disk 10 times times faster, so write to memory instead of writing to the hard Can make the system's ability to ascend thousands of thousand. In other words, your second-kill system may require 1000 server support, and now 1 servers can be propped up. You may have questions: write to memory instead of persistent, then if the computer goes down at this point, then the data written is not all lost. If you're so unlucky that you run into a server outage, you don't have a second to go, what a big deal. Finally, we will persist the information to the hard disk when we really deal with the second order, so we won't lose the critical data. Redis is a caching system that supports this feature by returning data to the client after it has been written to memory. Asynchronous processing instead of synchronous processing: a system with a short, large concurrency such as a second kill, with a noticeable crest and a long trough in the performance load, is economically uneconomical to prepare a large number of servers for a fairly short time of large concurrency. Therefore, to deal with the second-class demand, it should be synchronous to asynchronous. The user requests to write the memory immediately returns, the background initiates many threads to read the data asynchronously from the memory pool, carries on the processing. If the user request may be entered within 1 seconds, the actual processing of the system may take 30 minutes, then a server in the asynchronous case its processing capacity is more than 1800 times more than the synchronization situation. Asynchronous processing is typically implemented with MQ (Message Queuing), and Redis can be seen as a high-performance MQ. Because its data reads and writes occur in memory. Distributed processing: Well, maybe you have a lot of customers, seconds to kill the system is the use of the above two strokes, or stretched, it doesn't matter, we have a big recruit: distributed processing. If a server cannot hold the system for seconds, use more servers. 10 units No, just 100 units. Distributed processing, is to spread the request of a large number of users across multiple servers, generally using hash to achieve uniform distribution. This type of system in the era of big data cloud computing today has a lot of, nothing but the paxos algorithm and hash rings implementation. Redis cluster is such a distributed product.

Using Redis to implement a second-kill system

Redis and Redis Cluster (distributed version), is a distributed cache system that supports a variety of data structures and also supports MQ. Redis has a lot of performance optimizations, so using Redis or Redis cluster makes it easy to implement a powerful second-kill system. Basically, you can use the Redis command.

Rpush Key value: Inserts a second kill request, stopping all subsequent insertions when the number of seconds to be inserted reaches the upper limit. Start multiple worker threads in the background, use Lpop key to read the user ID of the success of the second kill, and then perform subsequent processing. Alternatively, use the Lrange key start end command to read the user ID of the kill winner and process it. Execute INCR key_num every time the processing of a second kill record is completed. Once all the inventory has been processed, the second kill of the product is ended, the worker thread is closed, and the second kill request is no longer received.

What to do if you can't hold on

Perhaps you would say that we have a lot of customers, even if the deployment of Redis Cluster, still can't hold, then what to do. Remember a great man said: The way is always more difficult.

Below we specifically analyze, what else will overwhelm our system on Redis (Cluster) seconds kill.

Scripting attacks

If there are many tickets to the software, they will automatically initiate an HTTP request, a client one second to initiate a lot of requests, if a lot of users use such software, it may be to crush our switch.

This problem is actually the category of the network problem, and our second kill system is not on a level, so we should not solve. Many switches have the ability to prevent too many requests from a single source IP, and many open source software can achieve this, such as the TC on Linux can be controlled, the popular Web server Nginx (which can also be seen as a seven-layer soft switch) can also be configured to do this. An IP, a second I will allow you to visit Me 2 times, other packages directly lost you, you can crush me.

The switch can't hold up.

Maybe your customers have too much concurrent traffic, the switch is not going to hold up, there is a way, we can use multiple switches for our second kill system services. The principle is that DNS can return multiple IPs to a domain name, and return different IPs for different source IPs and the same domain name. such as Netcom user access, will return to a netcom computer room IP; Telecom user access, return to a telecommunications room IP. That means using a CDN. We can deploy multiple switches for different user services, where users access the Redis cluster in the back data center for a second kill operation.

Summarize

With the help of Redis cluster, being a second-kill system that supports massive users is really easy. The scenario described here is for the second-kill system, but the rationale behind it is as effective as other high-concurrency systems. Finally, we revisit the principle of optimization for high-performance systems: write memory instead of writing to hard disks, asynchronous processing instead of synchronous processing, distributed processing.