If it's you. Ministry of Railways 12306 website architect, how to design the software architecture and hardware system architecture of the website

Http://www.cnblogs.com/aigongsi/archive/2012/09/17/2683656.html

design of new ticket system for Railway Ministry (I.)

design of new ticketing system for Railway Ministry (II.)

design of new ticket system for Railway Ministry (III.)

__________________________________________________________________________________

Http://www.oschina.net/question/88671_35944?sort=default&p=1#answers

To express words in a real-world scenario:

1, the ticket office is not allowed to stand in front of the queue to talk to the conductor, talk more than a certain time, you will be forced to drive out of the queue, solve the problem of repeated refreshes (if repeated refresh, the system only gives the wait interface)

2, more open ticket window (this spell is the server cluster of magnitude, if you want to support hundreds of millions of people at the same time to buy tickets, think of how many windows need.) , it usually takes a few seconds for a transaction to purchase a ticket, and any simple cluster cannot solve the problem in real time.

3, according to the destination, a limited time to buy tickets, 1 days 24 hours into 48 parts, every half an hour corresponding to a provincial administrative unit, through the administrative provisions of the customer group, improve the efficiency of the cluster. Repeat the process the next day, the time-limited table is announced in advance.

In addition, the computer system can not use simple addition to calculate the bottleneck, a province pilot can use, does not mean that the server volume *40 can support the country at the same time.

First of all, I would like to deny some of the optimizations that seem reasonable, but are not really necessary at all:

1. Foreground data optimization and compression
If the number of servers processing the data on the foreground page is not enough, or the pressure is too high, causing the Web page to open slowly and loading the page elements slowly, then the foreground data needs to be optimized and compressed. However, open the homepage, from the HTML file, to the picture, and even the verification code, almost all are instantaneous open (telecommunications, education Network, Unicom and Netcom has been measured), therefore, the front desk that point text data, what is good optimization. Of course, optimization can be, but the crux of the problem is not at the foreground of this text data.

2. Use the cache with the database.
Those who say this, have to understand what is called e-commerce. This kind of thing is not the kind of acid that can be neglected in Weibo. E-commerce business processing, the need for high acid, at present, the railway booking system is because of the need to ensure high acid, which led to today's problems. However, some people actually want to use the cache, this will lead to acid reduction method, to relieve the pressure, obviously, they do not realize that this design, even the requirements are violated, but also talk about optimization.


Over the past few days, I have discussed this issue with a number of highly theoretical mentors and friends with several large project experiences. We have come to the conclusion that the bottleneck of the current ticketing system lies in the realization of the acid: lock. Because the lock has a certain degree of hardware exclusivity, as well as the process serialization and other characteristics, coupled with the current universal database products, there will be an intrinsic lock of the cost of the lifting level. This overhead, and then the amount of business at the national level, resulting in, even the use of the most powerful mainframe, may not be able to withstand the use of the lock on demand.

To really solve the problem of locking in this system, it is impossible to increase the lock efficiency at the order of magnitude, unless a revolutionary upgrade of the future computer structure or components is possible. For example, in order to query the operation of the ticket, the client of each query operation, the server needs a corresponding operation. This model, reflected in the real world, that is, in the ticket office, a person needs to get tickets, the conductor has to answer once, so how many people, the conductor will have to answer how many times, obviously this is an inefficient method. However, the reality is that all people only need to look at the railway station Bulletin board, you can understand the situation of the ticket, this mode, in the computer is, the service side of the broadcast data, all clients can obtain data, but the current computer and network hardware, there is no such device. In the future, there may be some devices that are based on light or sound waves for simultaneous data broadcast, but it's clearly meaningless to discuss this device.

Nevertheless, we have discussed 3 small schemes that can improve lock efficiency at a linear level. The scheme is as follows:

1. Due to the uniqueness of the structure of the train ticket, the number of locks used is not many per business process. However, if you use common database software, you will have additional lock overhead and other overhead for memory. So, we need to "pull out" the database of train tickets, separate into a special database software for C + +, which eliminates the additional lock overhead and other overhead associated with using standard database software.

2. Distribute the ticket data to different servers as much as possible. In doing so, you can make the lock overhead for each server as small as possible, and ensure that you have as much hardware as possible to participate in the lock operation. For example, spread the ticket of a train to 10 databases. But the actual operation, how to apportion, we think, this to calculate according to the pressure, peacetime pressure is very small, maybe 1 servers can process the ticket data of many trains at the same time, but during the spring festival, 1 servers may only be able to process a small portion of a train ticket at the same time. Calculate the pressure, you can manually statistics, and then modify the allocation scheme, you can also be based on a number of simple strategies, plus machine learning, to implement machine automation statistics and modify the allocation scheme.

3. Owing to the problem of capacity, the number of train tickets provided by the railway station is much smaller than the number of people who have come to purchase, and in the entire purchase process, the number of queries accounted for the largest percentage, therefore, in the whole process of using the system is more read (more queries), Less write times (purchase to train tickets less). Therefore, the database can be used to load balance the read operation of the cluster mode. If you do this, you can speed up the query, however, the write speed will be slightly lower, but this decrease is obviously worth it.