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，支付相關信息
輸出：成功標志/確認失?。▌偤面i定超時，且被他人訂走）
作用：最終確認售票，系統向第三方支付服務提交確認請求。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters