The business process improvement suggestions on the Ministry of Railways website can reduce a large number of concurrent requests.

The content of the original post has been sorted out. Please visit:Http://blog.csdn.net/dragonimp/article/details/7184319

The following content is the original post content, which is only retained and does not post comments. For comments, please read the content of the original post before posting comments.

 

Original article title: there is a big problem with the Ministry of Railways's online ticketing website-A Big Deal !!!

 

I already wanted to talk about the website's problems. I wanted to talk about it when I bought a ticket online for the first time before New Year's day. Today I came to csdn and wrote it for sharing, but maybe someone has published it. At that time, when I saw the 30-minute lock prompt, it seemed that I was able to see a problem that would make the system collapse-a super long transaction at the business level !! When I saw the website, I ordered the order and locked the ticket first, and then paid for the ticket. After 30 minutes, I did not pay for the ticket and returned the ticket. What is silly, in order to reduce the problem of refund caused by unsuccessful ticket purchase, the Ministry of Railways changed the unlock time from the original 30 minutes to 45 minutes. Currently, many people are online shopping for the first time and are not familiar with online banking payment, this causes more people to wait longer and refresh constantly, requiring more system processing. Another serious problem is that a large number of tickets are locked on the website and cannot be bought at the railway station. This is my first and only online shopping experience, I went to the train station to buy the tickets. I was told that the tickets were all locked by the network and I had to go to the website to buy them. So I immediately used my mobile phone to dial the phone online and it took me half an hour to buy the tickets. However, this locking method is extremely unfair to the railway station! You can refresh your computer, but the train station will not refresh your queue. Even if you are willing to refresh again, you have to go back to the end of the team to repeat it!

We recommend that you remove the lock mechanism and change it to "Pay successfully" to sell your seats. You can enjoy the same position as the ticket office. One simple way to think of is to let everyone rush to the website first. If no ticket is found after the rush, the transfer is allowed. If there is a ticket, you can directly purchase the ticket using the website balance, there is no need to lock the operation first. Because the lock time is missing, it is clear whether there is a ticket at that time, there will be no waiting for the ticket to be locked, waiting for timeout and then releasing the ticket. In this way, a large amount of PV will be reduced, and the customer experience will not know how many times.

The problem now is that it seems that the Bank has never seen the function of transferring back online. The function of switching back online is batch. However, if Batch Transfer is used, it will inevitably cause the common people to not understand it, however, I think this is still worth it. In the style of the Ministry of Railways, it does not need to be understood or explained by everyone. In other words, if you leave for 15 days, it will take 15 days, it may be returned in a day or two. Therefore, it is worthwhile to get more refunds for a better customer experience and less system pressure! However, if this mechanism is not abolished, hardware, concurrency, and optimization of algorithms are not necessary.

 

----------------------------------------------------------------------------

In June 8, the Order locking mechanism was canceled. The process was as follows:

1. Select the number of vehicles to place an order, and provide the amount to be paid. The transfer page is used for charge, but no seats are locked at this time. 2. After the payment is completed, the user confirms the order and deducts the charge and assigns the seat to him. (If there is a large quantity, You Can batch check which customers have made the transaction according to the payment time.) 3. If the payment is complete, the ticket cannot be bought due to the late payment time, allow him to transfer the money in charge. (You can transfer the funds to the bank in batches at night and return to the customer's bank card the next day.) The advantage is obvious that you no longer need to lock the bank. Payment and refund are a module and can be completed in advance, the pressure is dispersed. The seat assignment is a module that can be completed in batches in a short time. The process is clear, the system is under low pressure, and the customer experience is good.

 

Such a simple business process is not optimized. What are the massive amounts of data? What are the high concurrency? What are the databases? What are the software? They are all cloud games. Don't be fooled by the so-called technical experts who have never bought tickets.

-----------------------------------------------------------------------------

On the evening of October 8, I would like to add two types of images to you. I am not from the Ministry of Railways, so the images are only used to indicate what I mean and are not necessarily completely accurate. We can also see from the figure that there are not many changes, but the changes are very easy, but I think the results are visible.

 

Existing ticket purchase flowchart: Because the ticket is locked first, everyone has to wait for the refund if there is still a successful payment. The rest is like a second kill, killing your system. In addition, once the ticket is locked, even the train station cannot be bought. Because the ticket window cannot be refreshed all the time, he must deal with the requirements of other people to buy tickets, which leads to the failure to sell tickets completely, however, you cannot buy a ticket at the railway station.

 

The suggested flowchart shows that if the lock operation in the existing process is removed, the ticket will not be locked online (but it is not actually sold out ). When you buy a website, you will have it. If you don't have it, you won't be crazy about your website. You can make the payment slowly and don't have to worry about it at all. In this way, you can choose any idle time period to place an order for payment first (of course, a few days in advance, otherwise the ticket will be lost if it is no longer available ). In addition, in the ticketing stage, you can use a batch of tickets and choose a variety of priority policies, such as the priority of the station, to play a fair role, because this time is just a pass, the processing logic is simple, and the business can be more flexible and the performance can be better.

 

 

---------------------

Explanations of some problems:

1. About transactions/locks. I admit that this title is the title of the party, but it only means business-level "transactions ". I have never said that they use real database transactions or locks to lock this. I think no Sb will do this in the world. I am also writing a program. I don't think that the Ministry of Railways uses database locks to lock this record or the whole process is a database transaction, that is, to make a database transaction, I really don't know how to achieve this across so many pages. Who have seen or implemented this?
2. Recharge questions. This is just a conceptual concept. You can say that you pay for this order, rather than recharge in advance. Just change the position in the process. It turns out to be "invoice-payment-unsuccessful refund", and now it is "payment-invoice-unsuccessful refund ". Note that the current lock can be regarded as a pass-out because it takes up the amount, and the effect is the same, but the ticket can be refunded later.
3. This approach is a last resort to avoid unnecessary pressure. Because if each person only comes once, there is no need to brush at this side, and the system pressure is low. The existing practices must be "customer-centric", but lead to other logic problems and unnecessary concurrency requirements. Some people say that if there are many options, they will pay a lot of money and cannot buy tickets. This is a good question. However, your system can mark this document as a refund and refund the money to the "Account" of the website. You can also directly set other bills without making another payment, you don't have to pay back the money. There are always methods. Do not rush to deny them.
4. The general idea is to minimize unnecessary access and distribute system pressure. No one paid attention to yesterday. at least some people paid attention to it today, but I hope everyone will be optimistic about the content and what I want to express, and then make comments.