12306的改造思路

首先請參考『12306 外包给阿里巴巴、IBM 等大企业做是否可行？』

下面我提出我的一些小觀點，如無特別提醒，都是基於中國國情（我恨這四個字）。

1. 優化鐵路路綫
   鐵路的購票在春節期間是個強需求的業務，所以每個身份證所對應的購票行爲應該是可以相信的。完全可以開發一個新需求：指定在春節期間，旅客設置想購買的出行區間，在放票前一個星期提前挖掘出接近于真實的全局的路綫規劃。
   再進一步，提供給用戶選擇，是否優先選擇二等座；如無，是否自動選擇一等座；諸如此類。所有的需求提前設置好，然後就安心享受放票的過程吧。
   對於不設置這些屬性的用戶，我們“認爲”他們沒有搶票需求，不支持對其提供搶票服務（我就喜歡霸王條款，呵呵）。這樣子就簡化了車票的動態庫存邏輯了吧？
2. 從幾個整點搶票分爲更細粒度的，比如10分鐘一批，每批搶票設置同時在綫用戶數，所謂依靠隊列優勢和被神選中的人。總用戶數根據服務器所能承受的最佳性能來設置，保證應用的可用性。沒有占好隊伍的請等待下次。另外，像飛機票那種提前發票的做法對火車票來説不符合實際需求的。
   這裏這麽設計，主要是爲了限制第一波高峰期的來臨。而邏輯必須足够簡單，保證邏輯在服務器上可擴展性。所謂被神選中，因爲正如參考文章所説，基於供遠遠小于求的現實情況，必須要淘汰一些網速慢的，儘管這樣子對某些人群（特別是那些還不懂網絡的人來講）來講有些殘酷。用戶數相對車票庫存來説是好幾個量級之上。要必須充分榨乾所有已計劃好的庫存資源。
3. 對於在一波搶票中已購票成功的用戶，24小時内拒絕對其服務。
4. 重新規劃服務器資源，將熱點出行時間安排至特殊服務器。這樣子可以避免影響到其他非熱點出行時間的需求。
5. 强制采用支持離綫緩存靜態資源的支持html5協議的最新版本瀏覽器，無視ie之流的瀏覽器。要想搶票就要符合這個規定，誰叫我是鐵道部。
6. 禁止同一個身份證號同時登陸多種設備搶票。所有身份證的設置都必須手機驗證碼通過。身份證和手機號碼必須是一一對應的，是爲了防範黃牛黨。用戶可以設置多個身份證，但是不超過3個名額。
7. 對於部分退票的，可以重新進去庫存系統，因爲庫存是無法滿足需求的。
8. 每次搶票提前20天搶票即可，比如1月11日搶的是1月30日的，如此，當天搶票隻需要針對（N+20）的哪天特殊處理（緩存優化等）即可。查票功能和搶票功能分離。對於遺留票據，可以采取taobao秒殺的方案吧？
9. 對於未搶票成功的用戶，進行下一波開始搶票時間的提醒。
10. 對於已搶到票的，離綫計算座位的分配。
11. 同個身份證祇能搶兩個不同時間點的票，有些人想以防萬一嘛。不過隻允許退票一次，呵呵。

其他潛在的優勢

1. 打廣告呀：比如僅僅從技術實現上就爲VMware SQLFire/GemFire打了一次廣告。

總結，需要分解搶票流程。限制分流和隊列控制的邏輯要足够簡單，在這層進行水平擴展和負載均衡。後面的邏輯是實打實的拼硬件性能了。注意，最好還是不要采取隨機分票的原則（用戶心理會很不爽）。另外，最好在搶票界面的醒目位置上，顯示當前在綫用戶，在綫隊列用戶，整體票據情況統計等信息。

引用知乎用戶的一句話：

为了那么一两个星期而搞那么大的系统，而其它时间都在闲着，有些可惜了，这也就是铁路才干得出来这样的事了。

12306这个问题的再NB的IT企业也无法从根源上解决，你让铁路再发展个5年也没用（还是不可能为了春运平时上大量的空车）归根结底是个社会问题

補充 2014.1.12 有人說預先讓想訂票回家的用戶先預支現金。我覺得這是不可行的。因爲鐵道部、用戶和銀行之間的賬戶金額的轉移是有成本的，如果沒搶到票直接返回用戶，相當於鐵道部自己吃到這部分成本。任何組織、機構、還是公司都不應該這樣子做。對整體的經濟效益并沒有太多貢獻。

補充 2014.1.12 早上剛剛體驗了一下購票流程，很智能化，既然如何，我想以後還可以進一步優化，購票流程如下：

1. 用戶設置車票出發時間，設置座位級別優先次序，設置出發時間有限次序
2. 系統開始通知搶票
3. 用戶搶占隊列資源
4. 成功獲得資源的用戶，點擊搶票，同時可以預覽目前的票據變化情況（讓用戶心理安心，哈哈）
5. 搶票成功的用戶，開始進行支付
6. 10分鐘后，開始進行下一波的搶票

這次優化通過對流程的進一步改造把不必要的頁面和元素大量刪減，從而減少服務器壓力。對購票用戶來講，隻需要看到設置購票需求和規則，搶票，支付，界面夠簡單，避免界面與服務器的交互太多（新版本就是交互太多，本來性能就不够，還搞這麽多自動化，呵呵，中了搶票軟件的毒吧）。