How to build a reliable train ticket online ordering system

Intermediary transaction SEO diagnosis Taobao guest Cloud host technology Hall

Yesterday, January 11, 2012, netizens @fenng wrote an article criticizing the Railway ministry train ticket online ordering system, http://www.12306.cn [1]. At the same time in Sina issued a fierce rhetoric microblogging, "go to your mother's ' massive transaction high speed processing system '", causing hot discussion [2].

The Spring Festival will arrive, we cannot buy the ticket, cannot catch up with the family reunion of the New Year Eve, the anxious mood can understand. But the table open scold, can only vent emotion, solve the actual problem.

It is not difficult to develop a booking system, it is difficult to cope with the peak flow of 1 billion during the Spring festival. Daily 1 billion-level flood peak requests, in China, the world's largest population, not rare, not only train ticket booking system will encounter, and e-commerce in the promotion, will encounter, social networking sites encounter news hotspots, will also encounter.

Therefore, the successful operation of the cloud computing system in China, spread to the world, must also be successful. But the successful operation of the cloud computing system in the US, transplanted to China, is not necessarily successful.

If we can design and build a stable and efficient railway booking system, not only solve the real problems of Chinese people, but also in the global High-tech industry, is a bright spot, but also affixed with the Chinese label of cutting-edge technology highlights.

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

In the comments of netizens, there is a view that [4] using "virtual queuing" means, the process of lengthening the load is reduced, is the design idea of online games. and [5] using caching technology to reduce the load of the system layer by layer is the idea of Internet design.

Personally, [4] and [5] are not mutually exclusive routes, the two focus on the solution of different issues, may wish to combine the use of complementarity. Here is a look at our draft design, the pursuit of practicality, discard the fancy. Welcome to the Brick.

Figure I. 12306.cn Web Site System architecture plan.

Courtesy Http://i879.photobucket.com/albums/ab351/kan_deng/12306.png

Figure I is the system architecture diagram, typical "presentation layer"/"Business Layer"/"Data layer" three paragraph theory.

There are two types of user access, one is running in the computer browser, such as IE, the other is mobile phone.

Whether the user uses a computer browser or a mobile phone to access the http://www.12306.cn website, the user requests to be first received by the Web site's load balancer. Load Balancer connects a group of portal servers, depending on the load of each portal server, the load Balancer forwards the user request to a relatively leisurely portal server.

The Portal Server's task is similar to that of the mailroom gaffer, which reads only the first few bytes of each user request, to determine the type of user request, and then to put the request into the appropriate type of queue. The process logic of the portal server is very simple, and the benefit is that it can quickly handle High-volume user requests.

According to [5] analysis, 12306 processing user requests, roughly divided into three categories,

1. Query. Before booking, check the train and other tickets. After the user orders, whether the query has been booked.

2. Booking, including determining the number of trips and votes, and then payment. When the user pays, need to operate on the website such as net silver.

3. Users who first visit need to register, including information such as name and credit card.

The business process of three types of requests is divided into two phases,

1. Task queues running in the cache. The purpose of the queue is to prevent the process from taking too long, causing a large number of user requests to be congested on the portal server, resulting in system paralysis.

2. Business processing processor, for each type of business, there are a group of business servers. Different business processes, each of the same.

Figure Ii. 12306.cn website inquiry and booking business process diagram.

Courtesy Http://i879.photobucket.com/albums/ab351/kan_deng/12306-1.png

Figure II describes the query and booking of two business processes. Register business process omitted.

The business process of the query, see figure two upper half, five steps. Here are two questions to note,

1. After the user makes a request, after a short wait time, can quickly see the result. The average wait time cannot exceed 1 seconds.

2. The key to affecting the whole query speed is the design of "Query Server".

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

1. Query the train and timetable, which is static content, rarely interacting with the database, the amount of data is not large, can be slow in memory.

The data structure of the train and timetable, it is advisable to adopt the Key-value way, the development is simple, the use efficiency is high. Key-value implementations have many products, [5] recommend using Redis.

These are technical details, and it is advisable to determine which product is most appropriate for the actual flow of the train ticket booking system and the peak fluctuation by contrast experiments.

2. Check the remaining tickets for a particular shift, which requires constant updating of the data in the database.

[5] It is suggested to divide the remaining tickets into two types, "yes" or "none", thus reducing the number of calls to access the database and reducing the pressure on the database. But this does not necessarily meet the needs of users, may incur the criticism of netizens.

[4] In order to increase the length of the booking queue, it is suggested that the remaining seats of each train can be calculated according to the length of the booking queue and the number of tickets purchased per request in the queue. This approach works if the 12306.cn Web site has only one backend system.

But if 12306.cn website uses the distributed structure, each railroad branch station has the subsystem, separately manages each railroad precinct area each train. In a distributed system, this approach faces the problem of task forwarding. Not only the development of a large workload, but also extended query process processing time, causing users to wait long.

3. The user who has already ordered the order, whether the query has been successfully booked.

Each user usually cares only about the tickets they subscribe to. If you put every user to order all the contents of the ticket, are slow to exist in memory, not only very consuming memory space, the use of memory space inefficient, more serious problem is, access to the database is too frequent, large amount of data, increase the pressure of the database.

To solve the two problems of distributed synchronization and database pressure, we should start with the process design and data structure design of booking.

If a Beijing user ordered a set of tickets online, through the Beijing Railway Bureau and the Zhengzhou Railway Bureau area two trips. Users from Beijing to the Internet, by the Beijing Railway Bureau subsystem, processing his request. Beijing Railway Bureau's booking server divides his request into a split, the Beijing Railway Bureau's train booking, completed in the Beijing subsystem, Zhengzhou Railway Bureau train in Zhengzhou subsystem completed.

Each subsystem handles four kinds of key-value data sets.

1. User id: multiple (Order ID) s.

2. Order ID: multiple (booking result id) s.

3. Booking Result ID: One (user ID, train ID).

4. Train ID: one (date), multiple (seat, user ID).

Beijing booking server After booking, the four data sets to the Beijing subsystem of the database, while caching into the Beijing query server, see the second half of the 6th and 7th steps.

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

Let the booking server to the booking data, and write to the database and query server cache, the purpose is to keep the database permanent reservation records, and let most of the query, only access to the cache, reduce the pressure of the database.

Beijing users of the booking data, only cached in Beijing query server, does not cross the domain cache, thereby reducing cache space occupancy, and synchronization of the trouble. To do so, there is a premise that the query user and the booking user, basically the same person, and from the same city to the Internet.

But there is a flaw, a user in Beijing online booking tickets. After a few days, he went online in Beijing, entered the user ID and password, he will see all the tickets he ordered. But after a few days, he went to Zhengzhou, the Internet from Zhengzhou, the same input user ID and password, but did not see all the tickets he ordered.

The solution to this defect is not troublesome, in the user inquiries booking information, need to indicate the location of the booking, the system according to the booking location, the query request forwarded to the corresponding area of the subsystem.

In addition, each time booking, the website will send text messages to his mobile phone, provide booking information, see the second half of the 8th and 9th steps.

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

Perhaps some readers will ask, why not use cloud computing? In fact, the above architecture design, for the future evolution of cloud computing, left a foreshadowing.

In the above architecture design, we assume that each link needs to use how many servers, how much capacity of the database, in advance have been planned. But if the plan ahead, less than the actual amount of traffic and data, then the system will collapse. Therefore, prior planning can only be established on the basis of peak value.

But how much is the peak? Even if the peak value can be determined, then the ability to plan the system based on peak value, then after the Spring Festival, there will be a lot of resource redundancy, resulting in waste of resources?

How can we fight against floods without causing waste of resources? The solution is cloud computing, and there is no other way to do it now, except for cloud computing.

Reference,

[1] massive transaction high speed processing system.

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

[2] Go to your mother's ' massive transaction high speed processing system '.

Http://weibo.com/1577826897/y0jGYcZfW

[3] The idea of a train booking system.

Http://weibo.com/1570303725/y0l9Y2mwE

[4] The simple design of the railway booking system.

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

[5] Opinion on the design of railway booking website.

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

Drawing from Designyoutrust

Dr. Deng Kan, American Carnegie Mellon computer robotics Specialist

Http://blog.sina.com.cn/s/blog_46d0a3930100yc6x.html