Second kill system architecture design second kill system, is a typical short time a large number of sudden access problems. There are three ways to optimize performance for this type of problem: Write to memory instead of hard disk Asynchronous rather than synchronous Distributed processing with these three tricks, no matter how heavy the load is, can easily handle. Better yet, Redis does all three. Therefore, it is easy to implement a seckill system with Redis. With my plan, no matter the e-commerce platform special price seconds kill, 12306 train ticket seconds kill, are not a matter 🙂
Here’s why the above three performance optimization ideas can solve the performance problem of seckill systems:
Write to memory instead of hard disk The read/write performance of traditional hard disks is quite poor. SSDS are 100 times faster than traditional hard drives. Memory is 10 times faster than SSD. Thus, writing to memory instead of hard disk increases the system’s power by a thousandfold. In other words, your seckill system might need 1000 servers, now it can be supported by 1 server. You might wonder: If you write to memory instead of persisting, then if the computer crashes, won’t all the data written to it be lost? If you’re unlucky enough to have a server down, you’re out of time. What’s the big deal? Finally, when we actually process the kill order later, we persist the information to hard disk. So no critical data is lost. Redis is a caching system where data is written to memory and then returned to the client, which supports this feature.
Asynchronous rather than synchronous processing Systems with short, large concurrency such as seckill have a distinct peak and long troughs in performance load. It makes no economic sense to prepare a large number of servers to cope with large concurrency in a relatively short period of time. Therefore, to deal with the need for seckilling, synchronization should be made asynchronous. Return immediately after user request write to memory. Multiple threads are started in the background to asynchronously read data from the memory pool for processing. If the user request may come in within 1 second, the actual processing may take 30 minutes. The processing power of a server in the asynchronous case is 1800 times greater than that in the synchronous case! Asynchronous processing, usually implemented using MQ(message queue). Redis can be viewed as a high-performance MQ. Because all of its data reads and writes happen in memory.
Distributed processing. Maybe you have a lot of customers, the second kill system is using the above two moves, or the lack of money. No matter, we have another big idea: distributed processing. If one server can’t support the system, use more servers. If you can’t get 10, get 100. Distributed processing refers to the distribution of massive user requests to multiple servers. Generally, hash is used for uniform distribution. There are already many such systems in the era of big data cloud computing. This is done using the Paxos algorithm and Hash Ring. Redis Cluster is such a distributed product.
Using Redis implementation description system Redis and Redis Cluster (distributed version), is a distributed cache system. It supports a variety of data structures as well as MQ. Redis has done a lot of performance optimization. Therefore, it is easy to implement a powerful seckill system using Redis or Redis Cluster. Basically, you just use these commands from Redis. RPUSH key Value Inserts the kill request
Stop all subsequent insertions when the number of inserted kill requests reaches the upper limit. Multiple working threads are started in the background, and LPOP key is used to read the user ID of the successful second kill for subsequent processing. Alternatively, run the LRANGE key start end command to read the ID of the successful user and perform subsequent operations. INCR key_num is executed each time a seckill record is processed. Once all inventory has been processed, the second kill for the item is terminated, the worker thread is closed, and the second kill request is no longer received. Script attacks such as now there are a lot of software grab train tickets. They automatically initiate HTTP requests. A client can make many requests a second. If a lot of users use this software, it could overwhelm our switch.
This problem actually belongs to the category of network problem, and our second kill system is not on the same level. So it’s not for us to solve. Many switches have features that prevent one source IP from making too many requests. There’s a lot of open source software that does this too. For example, TCS on Linux can be controlled. The popular Web server Nginx (also known as a layer 7 soft switch) can also be configured to do this. One IP, one second I allow you to access me 2 times, other software package directly to you lost, you still can overwhelm me?
Maybe your customers are getting so many concurrent traffic that your switch just won’t hold. There are ways to do that. We can use multiple switches to service our seckill system. The principle is that DNS can return multiple IP addresses for a domain name, and different IP addresses for the same domain name for different source IP addresses. If netcom user access, return a NETcom machine room IP; Telecom user access, return a telecom room IP. That is to use CDN! We can deploy multiple switches to serve different users. Users use these switches to access the Redis Cluster in the data center to perform second kill jobs.
Summary with the help of Redis Cluster, do a support mass user seconds kill system actually So Easy! Although the scheme described here is specific to seckill systems, the principle behind it is equally valid for other high-concurrency systems. Finally, let’s revisit the principle of optimization for high-performance systems: write to memory instead of disk asynchronous rather than synchronous distributed processing