Build a reliable online booking system for train tickets

Yesterday, January 11, 2012, users @fenng wrote an article criticizing the Ministry of Railways online booking system tickets, http://www.12306.cn [1]. At the same time in Sina sent a fiery microblogging, "to your mother's high-speed processing of massive affairs system", aroused hot [2].

Spring Festival approaching, we can not buy the ticket, catch up with the reunion of his family thirty, anxious mood can be understood. However, open the table scolded, only to vent their emotions, can not solve the practical problems.

The development of a booking system is not difficult, it is difficult to deal with during the Spring Festival, the daily average of 1 billion levels of peak traffic. Daily peak demand of 1 billion levels, in China, the world's largest country in the world's population, not rare, not only the train ticket booking system will encounter, but also in the promotion of e-commerce will encounter, social networking sites encountered hot news When will encounter.

Therefore, the cloud computing system that can be successfully operated in China is sure to succeed if it is promoted to the whole world. However, in the United States, the successful operation of the cloud computing system, transplanted to China, but not necessarily successful.

If we can design and construct a stable and efficient railway booking system, we will not only solve the practical problems of the Chinese people, but also highlight the high-tech industries in the world and highlight the cutting-edge technologies that are attached to China's labels.

So software engineers offer advice on how to improve the 12306 online ticketing system [3]. Among them are more representative, there are two [4,5].

User comments, the view that, [4] the use of "virtual queuing" means to reduce the process to extend the load, is the online game design ideas. And [5] the use of caching technology, layer by layer to reduce system load, is the Internet design ideas.

Personally think that [4] and [5] are not mutually exclusive two routes, the two focus on solving the problem is different, may wish to use together, learn from each other. Here to introduce our draft design, the pursuit of practical, abandon the fancy. Initiate, welcome Paizhuan.

Figure one. 12306.cn site system architecture ideas map.

Courtesy http://alibuybuy-img11.stor.sinaapp.com/2012/01/e990_12306.png

Figure 1 is the system architecture diagram, the typical "presentation layer" / "business layer" / "data layer" syllogism.

There are two types of user access, one is a browser running on a computer, such as IE, and the other is a cell phone.

Regardless of the user using a computer browser, or mobile phone visit http://www.12306.cn website, the user request is first received by the site's load balancer. The load balancer is connected to a group of portal servers. According to the load of each portal server, the load balancer forwards the user requests to a relatively idle portal server.

The task of the portal server is similar to that of the sending and receiving rooms. It reads only the first few bytes of each user's request. The purpose is to determine the type of user's request and then place the request on the corresponding type of queue. Portal server processing logic is very simple, the benefits of doing so is to enable it to quickly handle large quantities of user requests.

According to [5] analysis, 12306 user requests processed can be divided into three categories,

1. Query. Users booking before, check trips and tickets. After the user places an order, he or she inquires whether or not he has already made a ticket.
2. Booking, including determining the number of trips and votes, and then payment. Users pay, you need to operate in online banking and other sites.
3. The first visit to the user, you need to register, including name and credit card information.

Three types of requests for business processes, is divided into two stages,

1 running in the cache task queue. The purpose of setting up the queue is to prevent the processing time-consuming, resulting in a large number of user requests congestion in the portal server, resulting in the system paralyzed.

2. Business Process Processor, for each type of business, respectively, a group of business servers. Different business processes, different.

Figure II. 12306.cn website search and booking business process vision.

Courtesy http://alibuybuy-img11.stor.sinaapp.com/2012/01/1e0d_12306-1.png

Figure II describes the query and booking, two business processes. Registration business process omitted.

Query business processes, see Figure II, the upper half, divided into five steps. Here are two issues that need attention,

1. After the user makes the request, after a brief waiting time, the result can be seen quickly. The average waiting time can not exceed 1 second.

Affect the entire query speed is the key, "Query Server" design.

Query tasks can be further refined, roughly divided into three.

1. Query trips and schedules, which is static content, very little interaction with the database, the amount of data is not large, you can cache in memory.

Train and timetable data structure, may wish to adopt the Key-Value way, the development is simple, the use of high efficiency. There are many specific implementations of Key-Value, [5] Redis is recommended.

These are the technical details that we can compare to determine which product is most suitable for the actual flow of train ticket booking system and peak fluctuations.

2. Check the remaining tickets for a shift, which requires calling the constantly updated data in the database.

[5] It is advisable to divide the remaining tickets into only two, "yes" or "no", thus reducing the number of calls to the database and reducing the pressure on the database. However, this may not be able to meet the needs of users, may lead to netizens critics ridiculed.

[4] It is suggested that the function of measuring the length of the ticket queue be added to the ticket queue, and the remaining seats for each train can be calculated according to the length of the ticket queue and the number of tickets purchased for each request in the queue. If the 12306.cn website has only one background system, this approach works.

However, if the 12306.cn website uses a distributed structure, each railway branch has a subsystem that manages each train station within each jurisdiction. Under the distributed system, this method is facing the trouble of task forwarding. Not only the development workload, and will extend the processing time of the query process, leading to long-term users.

3. Has been ordered by the user, check whether the ticket has been successfully set.

Each user usually only care about their booking. If all the contents of the ticket subscribed by each user are cached in the memory, not only the memory space is consumed but the memory space is inefficiently used. A more serious problem is that access to the database is too frequent, the amount of data is large, and the size of the database is increased pressure.

Address these two issues of distributed synchronization, as well as the pressure on the database, may wish to start from booking process design and data structure design.

If there is a Beijing user online booking a set of coupons, via Beijing Railway Bureau and Zhengzhou Railway Bureau area two trips. Internet users from Beijing, the Beijing Railway Administration's subsystem, to process his request. Beijing Railway Bureau booking server to his request is divided into two, Beijing Railway Bureau trips booking, the completion of the Beijing subsystem, Zhengzhou Railway Bureau trips completed in Zhengzhou subsystem.

Each subsystem handles four Key-Value data sets.

1. User ID: Multiple (Order ID) s.
2. Order ID: multiple (booking result ID) s.
3. Booking result ID: a (user ID, vehicle ID).
4. Train ID: one (date), multiple (seat, user ID).

After booking the ticket booking server in Beijing, the above four data sets are written into the database of the Beijing sub-system and simultaneously cached into the inquiry server in Beijing, see steps 6 and 7 in the lower half of Figure II.

Zhengzhou booking server to complete the booking, the above four data sets, write the database of Zhengzhou subsystem, while caching query server in Beijing, rather than Zhengzhou server.

Let the booking server to the booking data at the same time into the database and query the server cache, the purpose is to make the database permanently retain booking records, leaving most of the queries, only access the cache, reducing the pressure on the database.

Beijing users booking data, only cache query server in Beijing, not cross-domain cache, thereby reducing the cache space occupied, and synchronization trouble. In doing so, there is a precondition to assume that the inquiring user is essentially the same person as the booking user and accessing the Internet from the same city.

But here is a flaw, a user in Beijing set a ticket online. A few days later, he was online in Beijing, entering the user ID and password, you will see all the tickets he ordered. However, a few days later, he went to Zhengzhou and got online from Zhengzhou. He also entered the user ID and password but could not see all the tickets he ordered.

The solution to this defect is not troublesome. When the user queries the booking information, it needs to indicate the booking location. The system forwards the query request to the subsystem in the corresponding area according to the booking location.

In addition, each time booking, the site will send a text message to his cell phone to provide booking information, see Figure II, the second half of the 8th and 9th step.

The above is a preliminary design, there are many details need to be improved, such as how to configure the firewall and so on. This design not only applies to a single centralized deployment, but also suitable for distributed deployment.

Some readers may ask, why not use cloud computing? In fact, the above architecture design for the future evolution of cloud computing, leaving a hint.

In the above architecture design, we assume that each link requires how many servers, how much capacity the database needs, have been planned in advance. But if the prior planning, lower than the actual amount of traffic and data, then the system will collapse. Therefore, prior planning can only be set up on a peak basis.

But what is the peak? Difficult to determine in advance. Even if we can determine the peak value and then we plan the system capacity based on the peak value, then after the Spring Festival, there will be a lot of resource redundancy and waste of resources.

How to fight floods without wasting resources? The solution is cloud computing, and for the time being, there is no other way than cloud computing.

Reference,

[1] massive transaction processing system.

http://www.douban.com/note/195179318/

[2] to your fuck 'massive affairs high-speed processing system'.

http://weibo.com/1577826897/y0jGYcZfW

[3] The idea of ​​train booking system.

http://weibo.com/1570303725/y0l9Y2mwE

[4] Simple design of railway booking system.

http://blog.codingnow.com/2012/01/ticket_queue.html

[5] Railway Booking website personal design humble opinion.

http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html

The picture from Designyoutrust

Source: http://www.ifanr.com/68019