12306的已知資訊、資料及問題
需求分析（一）—— 售票系統領域知識（區間票、訂票、預留票）
需求分析（二）—— 涉衆、使用者體驗
核心業務需求及邏輯架構分析
需求分析（三）—— 票倉
票倉設計（一）—— 預生成車票方案的優缺點
票倉設計（二）—— 區間二進制方案的優缺點
票倉設計（三）—— 平衡方案的優缺點
票務并發沖突處理原則設計（基于平衡方案）
緩存邏輯架構設計
災難備份與恢複
快要太監了 :-(
由于各種個人原因, 鐵道部的這個博文系列中止了很久。最近終于連自己都不好意思了。是以還是繼續完成它吧，估計1-2周一篇的節奏。
感覺不先劃分一下大的系統架構總會讓大家感覺有點頭暈, 不過沒能力對整個12306進行設計，這個貨太大了。隻是借這個機會談談自己對系統結構分析的一些感想
樸素的面向對象分析
面向對象是一個萬金油，但是據說真正懂的人不多是吧？
我對面向對象的感覺就是: 他本質上是對現實世界的抽象，其表面現象是不斷細分對象的粒度，提升對象的抽象度。最終形成一種用有限數量的獨立的對象“積木”構造整個需求不斷變化的系統的目标。
而系統級别的分析也大緻如此，我們可以借鑒類分析中的很多概念，不斷劃小系統規模，剝離職責，抽出依賴性。
一般系統結構
這裡隻是一個簡單模型，用以表達我對多數項目的結構分析。
配置資料服務：系統運作所需要的動态配置資訊
資産資料服務：所有實際或虛拟的“物”的管理（crud），甚至可以包括人。
業務資料服務：該企業實際經營的業務産生的資料。超市的收銀記錄，企業的銷售記錄，鐵道部的售票記錄
報表資料服務：各類統計報表需要的
其中業務系統和業務資料服務應該是最核心的部分。
一般而言，那些配置和資産管理的部分不會造成嚴重的性能問題。隻要在實作crud的時候多考慮考慮相關的業務需求，努力做到任何資産的屬性變動時，確定相關的業務完整性就好（出租公司管理系統裡，一輛計程車今天還在營運，背景系統絕對不應該可以輕松地把它标記成報廢車輛，連軟删除都是不合理的做法）。
12306之是以能招全國人民圍觀，我覺得主要還是花的錢和大家的感受之間有落差。而我陰暗的以為這個問題的核心部分就在票務處理的部分。
是以我後續的幾篇博文都會圍繞票務處理裡面的内容展開。
另外，我要大家了解的是，我是要設計一個合理的區間票售票系統核心。而不是實作鐵道部的需求。本質上我認為鐵道部不會說清楚他自己的需求，而太極公司的需求分析有可以進一步深挖的可能。
12306核心需求及子產品分析
整體架構沒法子設計，太大了。有興趣的可以參考
中國鐵路客票發售和預訂系統5_0版的研究與實作
國鐵路客票發售和預訂系統5.0版本(trsv5.0)售票與經由維護操作說明
目前我專注的是用于訂票的部分。我感覺這個是最重要的部分。
12306最大的問題，就是如何在訂票的時候高效率得并且适當優化得找到需要數量的車票。并且要能徹底保證一張票不會被兩個請求同時處理成功。
隻要這個問題無法徹底解決，任何分布式處理，最終都會卡在這個問題上。
我會涉及到的子產品
12306票務處理功能子產品分析
假想完整網絡訂票流程圖
這裡實際的使用者和系統的互動有4種類型。
1、車次和餘額查詢
2、訂票
3、取消訂票
4、确認訂票
這裡希望廣大圍觀群衆都來評估一下這個假設的訂票流程及其參數是不是都合理？如果這個流程本身不合理，則我後續的分析都要重寫了。不熟悉售票流程的，可以看看我之前的分析文章。
然後我們繼續來細化一下
車次和餘額查詢
輸入：起始站，終到站，日期，座位類型集合
輸出：車次，對應座位類型可售餘額
作用：最終使用者根據查詢結果選擇需要出行的車次，并進一步進入訂票操作。但是系統不保證顯示為有票的車次在下一步操作中必然有票。
這裡其實涉及到兩個類型的查詢
1、哪些車次符合使用者的查詢結果，可以通過一個基本固定不變的資料源來提供。而該資料源可以實作分布式緩存以緩解查詢壓力，甚至可以考慮用戶端部分結果緩存。
輸入：起始站，終到站，日期
輸出 :車次清單，
2、特定車次，特定座位類型的可售票數量。這個資料的來源應該和第一個查詢不同。
輸入：起始站，終到站，車次，日期
輸出：數量
訂票(我喜歡稱它為鎖票)
輸入：起始站，終到站，日期，座位類型，需要車票數量，使用者id
輸出：實際到的擷取車票數量
作用：最終使用者通過訂票操作，順利鎖定需要數量的車票。系統保證使用者在規定的時間段内對這幾張車票具有優先訂購權利，且其他人不得購買這些車票。
目前我感覺留給使用者10-15分鐘時間繼續後續操作，以進入支付環節（當然，這必須是在系統本身性能良好條件下。否則點個按鈕就要等10分鐘，那就不對了。）
同時如果逾時，則系統會在後續訂票操作中忽視該鎖定狀态。
取消訂票
輸入：起始站，終到站，日期，座位類型，數量，使用者id
輸出：成功标志
作用：使用者放棄已經獲得的被鎖定的售票權利，系統恢複對應的資料為可售。
确認訂票（确認支付）
輸入：起始站，終到站，日期，座位類型，數量，使用者id，支付相關資訊
輸出：成功标志/确認失敗（剛好鎖定逾時，且被他人訂走）
作用：最終确認售票，系統向第三方支付服務送出确認請求。
最新内容請見作者的github頁：http://qaseven.github.io/