[鐵道部信息化管理]核心業務需求及邏輯架構分析

• 12306的已知信息、數據及問題
• 需求分析（一）—— 售票系統領域知識（區間票、訂票、預留票）
• 需求分析（二）—— 涉衆、用戶體驗
• 核心業務需求及邏輯架構分析
• 需求分析（三）—— 票倉
• 票倉設計（一）—— 預生成車票方案的優缺點
• 票倉設計（二）—— 區間二進制方案的優缺點
• 票倉設計（三）—— 平衡方案的優缺點
• 票務併發衝突處理原則設計（基於平衡方案）
• 緩存邏輯架構設計
• 數據庫邏輯設計
• 災難備份與恢復

 

快要太監了 :-(

因爲各類我的緣由, 鐵道部的這個博文系列停止了好久。最近終於連本身都很差意思了。因此仍是繼續完成它吧，估計1-2週一篇的節奏。

 

感受不先劃分一下大的系統架構總會讓你們感受有點頭暈, 不過沒能力對整個12306進行設計，這個貨太大了。只是借這個機會談談本身對系統結構分析的一些感想

 

樸素的面向對象分析

面向對象是一個萬金油，可是聽說真正懂的人很少是吧？

我對面向對象的感受就是: 他本質上是對現實世界的抽象，其表面現象是不斷細分對象的粒度，提高對象的抽象度。最終造成一種用有限數量的獨立的對象「積木」構造整個需求不斷變化的系統的目標。

而系統級別的分析也大體如此，咱們能夠借鑑類分析中的不少概念，不斷劃小系統規模，剝離職責，抽出依賴性。

 

通常系統結構

這裏只是一個簡單模型，用以表達我對多數項目的結構分析。

配置數據服務：系統運行所須要的動態配置信息
資產數據服務：全部實際或虛擬的「物」的管理（CRUD），甚至能夠包括人。
業務數據服務：該企業實際經營的業務產生的數據。超市的收銀記錄，企業的銷售記錄，鐵道部的售票記錄
報表數據服務：各種統計報表須要的

其中業務系統和業務數據服務應該是最核心的部分。

通常而言，那些配置和資產管理的部分不會形成嚴重的性能問題。只要在實現CRUD的時候多考慮考慮相關的業務需求，努力作到任何資產的屬性變更時，確保相關的業務完整性就好（出租公司管理系統裏，一輛出租車今天還在運營，後臺系統絕對不該該能夠輕鬆地把它標記成報廢車輛，連軟刪除都是不合理的作法）。

12306之因此能招全國人民圍觀，我以爲主要仍是花的錢和你們的感覺之間有落差。而我陰暗的覺得這個問題的核心部分就在票務處理的部分。

因此我後續的幾篇博文都會圍繞票務處理裏面的內容展開。

另外，我要你們瞭解的是，我是要設計一個合理的區間票售票系統核心。而不是實現鐵道部的需求。本質上我認爲鐵道部不會說清楚他本身的需求，而太極公司的需求分析有能夠進一步深挖的可能。

 

12306核心需求及模塊分析

總體架構無法子設計，太大了。有興趣的能夠參考

中國鐵路客票發售和預訂系統5_0版的研究與實現
國鐵路客票發售和預訂系統5.0版本(TRSv5.0)售票與經由維護操做說明

目前我專一的是用於訂票的部分。我感受這個是最重要的部分。

12306最大的問題，就是如何在訂票的時候高效率得而且適當優化得找到須要數量的車票。而且要能完全保證一張票不會被兩個請求同時處理成功。

只要這個問題沒法完全解決，任何分佈式處理，最終都會卡在這個問題上。

我會涉及到的模塊

 

12306票務處理功能模塊分析

假想完整網絡訂票流程圖

這裏實際的用戶和系統的交互有4種類型。

一、車次和餘額查詢

二、訂票

三、取消訂票

四、確認訂票

 

這裏但願廣大圍觀羣衆都來評估一下這個假設的訂票流程及其參數是否是都合理？若是這個流程自己不合理，則我後續的分析都要重寫了。不熟悉售票流程的，能夠看看我以前的分析文章。

而後咱們繼續來細化一下

 

車次和餘額查詢

輸入：起始站，終到站，日期，座位類型集合

輸出：車次，對應座位類型可售餘額

做用：最終用戶根據查詢結果選擇須要出行的車次，並進一步進入訂票操做。可是系統不保證顯示爲有票的車次在下一步操做中必然有票。

這裏其實涉及到兩個類型的查詢

一、哪些車次符合用戶的查詢結果，能夠經過一個基本固定不變的數據源來提供。而該數據源能夠實現分佈式緩存以緩解查詢壓力，甚至能夠考慮客戶端部分結果緩存。
輸入：起始站，終到站，日期
輸出 :車次列表，

二、特定車次，特定座位類型的可售票數量。這個數據的來源應該和第一個查詢不一樣。
輸入：起始站，終到站，車次，日期
輸出：數量

訂票(我喜歡稱它爲鎖票)

輸入：起始站，終到站，日期，座位類型，須要車票數量，用戶ID

輸出：實際到的獲取車票數量

做用：最終用戶經過訂票操做，順利鎖定須要數量的車票。系統保證用戶在規定的時間段內對這幾張車票具備優先訂購權利，且其餘人不得購買這些車票。

目前我感受留給用戶10-15分鐘時間繼續後續操做，以進入支付環節（固然，這必須是在系統自己性能良好條件下。不然點個按鈕就要等10分鐘，那就不對了。）
同時若是超時，則系統會在後續訂票操做中忽視該鎖定狀態。

取消訂票

輸入：起始站，終到站，日期，座位類型，數量，用戶ID

輸出：成功標誌

做用：用戶放棄已經得到的被鎖定的售票權利，系統恢復對應的數據爲可售。

確認訂票（確認支付）

輸入：起始站，終到站，日期，座位類型，數量，用戶ID，支付相關信息

輸出：成功標誌/確認失敗（恰好鎖定超時，且被他人訂走）

做用：最終確認售票，系統向第三方支付服務提交確認請求。