難得在上能看到案例設計討論，而且是關於12306售票系統的。於是我也來發表下的我一些感想，歡迎來吐槽！
12306系統公升級了，但還是被吐槽了。這次國慶我沒買火車票，按照去年春節的購票經歷，我談談我的看法。
什麼才是12306最需解決的問題？
1、 重大節假日前期，系統登陸難。
2、 搶票環節的併發處理能力。
3、 餘票查詢的響應速度。
人們往往有先入為主的觀念，導致了解決問題的思維方式收到束縛，難以跳出既定的圈子。誰能說現在的購票系統的業務邏輯和使用者體驗是最合理的呢？它的設計合理之處又在**呢？我想完全不懂技術的人做產品經理，可以比技術出身的人做的更好，因為不懂技術的產品經理提出的需求不會受技術的束縛，更加注重使用者體驗。12306的餘票查詢的使用者體驗太糟糕了，為什麼非要有帳號才可以查詢-_-
購票系統的功能架構和技術架構，勢必要考慮到峰值的處理能力，尤其是超大規模併發的處理能力。12306雖說是非盈利性的，但是這畢竟關乎到民生，為何不公開技術架構，讓更多的人參與改進呢？
以上內容可以忽略。以下是我的設計思路，主要採用功能適度分離的思想進行設計。
1、 餘票查詢的優化方案
將餘票查詢系統與搶票系統功能分離，餘票查詢系統部署到映象站點cdn上，搶票系統應用單獨部署，支付和退票應用單獨部署。（這點很關鍵）
資料庫的讀寫分離，主資料庫只做寫操作，寫入購票記錄和更新實時餘票資訊，餘票查詢庫可以通過非同步更新獲取餘票資訊。餘票查詢功能可以基於部署到cdn上，建議免登陸，建議向社會開放餘票資源和api。（解決查票問題）
餘票查詢系統的系統架構。我們需要什麼級別的實時性？毫秒級？不需要！餘票查詢的操作遠大於搶票，每1秒內資訊的變化都難以想象，所以在餘票查詢上實時性太高意義不大，只能作為搶票前的參考，所以也沒必要一定要用關聯式資料庫，nosql其實很合適。系統只要保證購票者在資訊獲取是平等的，搶票環節是公平的（按照先購先得的原則），然後進行適度優化設計。餘票查詢的系統架構，我有2個設計方案
1) 記憶體資料為主、資料庫為輔方案。
2) 純資料庫方案。
基於車票餘額資訊進行分庫，並進行資料庫遠端同步。考慮到實際應用特點，可以對餘票資訊按照部署城市或者地區進行分庫。如在杭州買票，基本上都是查詢涉及包含杭州的車次資訊，所以可以根據這點做深入的優化，增加冗餘記錄，減少跨庫查詢。所以這些資料的實時性要求會比較高，要直接從cdn的映象庫獲取。出現異地**性質的餘票查詢時，通過主資料庫的讀庫（或者對應cdn的映象庫）進行查詢。
2、 搶票環節的優化方案
我可以理解在火車站買票需要排隊，因為這樣可以維持秩序，對先排隊的人也是一種。但是無法理解在網路上買票還需要排隊，難道排到後一定有票？更無法理解登陸還要排隊，因為把購票者堵在外面不是解決問題的辦法，提高視窗的併發處理能力才是關鍵。
訊息佇列是需要的，但不應該出現在登陸和購票環節。雖說搶票靠的是硬體、軟體、網路和人品，但是每個人都應該同享購票的權利。如何做到這點？
1） 搶票處理服務和身份認證必須分開部署，前端通過負載均衡提高併發處理能力。
2） 將每個搶票請求提交到對應的訊息佇列（不同車次的搶票處理服務，可以部署在不同的伺服器上），並返回佇列位置id，搶票環節完成。然後就是等待搶票決策系統的處理結果。保證每個請求都會被登記並被處理，這點才能體現搶票環節的公平、公正、公開。
3） 非同步處理搶票訊息佇列中的每個資訊。搶票成功（表示搶票資訊被處理後，受理通過），則給予車票支付序列號，按照序列號支付，完成購票環節。
4） 使用者搶票申請的被接收和被處理過程分開。搶票被接收後，如果當前車次的未處理訊息佇列大於設定的閥值，則堵塞新的搶票申請。如果訊息佇列數小於閥值，已經沒有餘票，但是還有未完成支付的餘票，則詢問使用者知否排隊等待（如果有人退票或未能完成支付，則享受優先獲得該票的資格，在退票和支付過期處理系統中優先考慮這部分申請）。
5） 單獨部署未支付訂單審查系統。每分鐘檢測超時未支付訂單，並將失效的購票申請反饋到相應的佇列處理伺服器。
類似於鐵道部12306的城市選擇框的實現
第一次寫，有點小緊張。今天先簡單的介紹一下城市選擇框的實現，與12306官網有一點差距，上圖，先看看效果 如圖所示，支援拼音首字母查詢，全拼音查詢，漢字查詢等 好了，現在談一談我是怎麼實現的 首先是準備工作 分析一下裡面的資料，發現是有固定格式的 找到資料以後，將他存為本地txt檔案，記得修改檔案編...
類似於鐵道部12306的城市選擇框的實現
第一次寫，有點小緊張。今天先簡單的介紹一下城市選擇框的實現，與12306官網有一點差距，上圖，先看看效果 如圖所示，支援拼音首字母查詢，全拼音查詢，漢字查詢等 好了，現在談一談我是怎麼實現的 首先是準備工作 分析一下裡面的資料，發現是有固定格式的 這就好辦了是吧，我們可以用程式的方式來取出每條記錄並...
關於鐵道部購票時間段安排分析
2014年1月21日，今天朋友託我幫他買一張 嶽陽東至廣州南站的高鐵票，果斷下午1點40分左右，登陸12306 進行刷票，然後2點整 過後。車票一閃而過，非常遺憾，與票擦肩而過，心想，武廣高鐵，車輛高達30多輛，我又是開了兩台萬網idc伺服器進行刷票，應該不存在搶不到票的原因，於是，果斷分析，鐵道部...