前言：

　　最近經常看到買票難，作為搞技術的我TMD的罵一次：

　　 票會增加嗎？總是有人能買到，有人不能買到；

　　 就不能換個思路設計訂票系統。

　　 要是我是什么什么的來著，早已經實現通過手機短信、網站就能輕松買票了；

　　 還順便將手機實名制給實現了。

　　正文：

　　 不知是我想簡單了，還是專家們想復雜了。

　　鐵道部的專家還停留在線下售票方案中撥不出來；

　　線上售票系統簡單得多了。

　　罵完鐵道部后，提供一簡單又可行的解決方案。

　　查詢余票、防止超售、防止黃牛，一般的設計思路是有難度，

　　換個思路，TMD太簡單的就能搞定。

　　一、總體方案

　　1、正常情況：預訂交錢-->后臺自動驗證規則-->不符合購買限制的錢原路退回-->

　　-->提醒用戶預訂成功（但不一定有票）-->運輸資源出來，根據先到可先得+優化級的原則分配

　　-->短信通知用戶取票

　　２、用戶不取票：沒有關系，因為鐵道部已經收到錢，所以你開車前兩小時取即可。

　　 多方便啊，就不用為了票多走一次車站。

　　３、用戶退票：春運有人退嗎？平時要是退了，就退吧

　　二、前臺網站設計

　　只需要預訂，根本不需要查余票什么的。所以很簡單的架構就能搞定，甚至不用CDN

　　三、后臺設計

　　預訂后，后臺慢慢處理，看資源情況增加服務器。即使后臺的服務器掛了，前臺用戶也感覺不出來。

　　運輸資源出來，看有多少是分配給網上訂票的，依規則分配即可。

　　這樣后臺的架構要有多靈活，就可以設計成多靈活。

　　后臺由驗證服務器+分配服務器+取票及跟蹤服務器組成。

　　具有分配資格的，滿足了身份證唯一、已付款、優先級等等要求了；

　　而且是一票一票分配的，根本就沒有什么復雜的邏輯處理，也沒有什么數據庫表鎖；

　　因為能分配的已經滿足了鎖的要求了，用單線程分配就好了。

　　２核的一秒就可以處理1000張票以上。

　　四、可能的問題

　　 １、有存在海量的處理的情況嗎？沒有，預訂對數據只是增加操作，不需要扣除數量鎖表

　　 ２、有峰值壓力嗎？沒有，預訂時要處理的事情很少很少

　　 ３、能不能訂到票，心里沒底？預訂和搶票，沒有區別啊，

　　關鍵一點的是，預訂可以有復雜的預計，比如允許自動安排下一趟什么的；

　　多靈活啊。也不要做哪些沒有意義的重復提交。

　　 ４、如果鐵道部的內部人員想作弊，采用什么方式都可能存在作弊

　　 五、優點

　　１、能提前１０年預訂都沒有問題，只要鐵道部和旅客愿意。將來的目標發展為：個人旅行管理系統

　　２、前臺輕量，愛怎樣擴展就怎樣擴展

　　 3、后臺愛怎樣處理都行，而且可以很容易監控，有異常還可以人工偷偷處理一下，用戶根本感覺不到

　　４、實際上這樣一套系統上線，在家中買票，要坐車再去取票就可以了。不夠鐵道部的關系人少了點代理收入。

　　經以上分析，結論：用Asp.net+SQL２００８ 就可以輕松實現。特別是后臺，用C#.net開發絕對是優勢。