Simple Design of Railway Ticket Booking System

In fact, the technical difficulties facing the railway ticket booking system are nothing more than the massive concurrent business requests that may occur during the Spring Festival. This can be easily solved by adding a queuing system.

Originally, I spoke to Weibo about this simple solution. I thought everyone would understand it at a glance. I did not expect many people to have doubts. Well, write a blog to explain it.

To put it simply, we set up several gateway servers and use dynamic DNS to share the concurrent ticket booking requests. By analogy, people are diverted to different ticket purchase halls. You can buy tickets for all times in each ticket purchase Hall. OK. I will not elaborate on how to implement load balancing in this step.

In fact, the most important role of each gateway is to queue ticket booking users. In fact, the entire system only uses queuing. Even if each gateway is sitting behind a line of ticket buyers, someone can buy a ticket on the screen and enter it to the internal ticket booking system to issue a ticket, then, knock the ticket number back, and the system can work normally without pressure. Otherwise, how did I sell tickets during the past Spring Festival?

Let's talk about how the queuing system works:

In fact, it is similar for us to go to a popular restaurant for dinner to get a number. It is only necessary to prevent other people from entering the queue with forged numbers.

If you come to a person (an HTTP request), I will randomly generate a number that I have done some signature processing and return it to you. Ticket ID. This ticked ID is hard to forge.

The system opens a large array in the memory (32 GB memory is enough for hundreds of millions of people), which is a loop queue. Put the ticket ID at the end of the queue.

The user now sends a request to the gateway with the ticket ID. Using a hash query, the gateway finds its location in the array queue in the memory and immediately returns it to the user. The user's front-end can see how many people are waiting in front of the Gateway (ticket sales hall.

The key here is that the entire queue is in the memory of the Local Machine. querying the location in the returned queue can be more efficient than a web server that processes static files. Static files must at least call file IO. The number of concurrent operations that can be processed by the static file web server.

At the same time, the front-end controls the frequency at which the user queries the queue location with the ticket ID. High load can be 1 second or longer. In order to prevent the user from writing a script to refresh this request (although it does not make much sense, because many of the refresh will not be included in the front), if the same ticket ID is frequently queried. For example, 20 or more queries are performed within 10 s. The ticket ID is invalid. The person holding the ticket needs to requeue.

For the last ranked person, the system will generate a unique session ID that cannot be forged. You can use this session ID to complete the actual ticket purchase process. You can connect to the real ticketing server or use the gateway to transfer the ticket. The invalid session ID will be immediately disconnected. Once the user knows that it is almost impossible to forge the session ID, he can only get it through the ticket ID queue. Unless it is a malicious attack system, no one will try the session ID in disorder.

We can set a maximum validity period for each session ID, for example, half an hour. If the ticket purchase process has not been completed for more than half an hour, the ticket will be queued up again.

As for how many session IDs are opened at the same time, that is, how many ticket purchasing windows are opened depends on the load that the ticket purchasing system can afford. However, after a simple calculation, we know that a queuing system ensures a good order. With the computer's throughput, we can solve the ticket purchase requests of hundreds of millions of people even if these people are queuing together, that is, the processing capacity of a group of machines in just a few hours.

This blog is just a casual write. It may not be very rigorous, but the idea is reached. There is a lot of data to be estimated in the middle, which is not too difficult.

Why is the current ticketing system so rampant? The key lies in a large amount of network bandwidth, and the computing power is wasted on "maintaining order. When the system is unstable, a large number of ineffective ticketing processes that are only half done are wasted. To respond to highly concurrent HTTP requests, the key lies in rapid response. Do not go around the database. Databases are not required to maintain the queue. If all HTTP requests are returned immediately, the amount of HTTP requests that can be processed in a short time will also be very large. If you cannot process the request and keep the TCP connection there, the system will not be able to support it.

In addition, users can see the number of people in front of the ever-decreasing queue, and they will wait with peace of mind. As long as the website page is refreshed smoothly (it is easy to ensure that only queue information is processed), the user experience will be good.

Reposted from: simple design of Yunfeng's blog Railway Ticket Booking System