在第二篇文章里面，重點分析了余票庫的整體設計，我看到有的評論說了幾點，現在整理一下

1 為什么要用悲觀鎖

為什么要用鎖，由于之前是做金融系統(tǒng)，對數據的一致性要求很高。鐵道部的出票操作要保證數據一致性，所以必須在獲取余票的情況下鎖定余票記錄，否則會導致并發(fā)問題，多出票。如果是站票還無所謂，如果是臥鋪咋辦，一個席位，兩張票。這個操作和帳戶扣款一樣，考慮下面的例子：

這里沒有鎖，導致多出票，這個只是兩個線程，假設有10個線程，則多出10張票

考慮有鎖的情況：

2 系統(tǒng)能否承受悲觀鎖

首先，我們需要看到什么情況下鎖，以及鎖持續(xù)時間，以及請求的并發(fā)數來進行分析。大多數情況下，鐵道部購票系統(tǒng)承受的并發(fā)量都不會太大，除了節(jié)假日，主要是國慶節(jié)和春節(jié)。及時在國慶節(jié)和春節(jié)的情況下，我們假設每秒鐘1000個請求去買座Z27的20121001的座票，那么鎖記錄持續(xù)的時間是多長了

分兩種情況

a 有票：業(yè)務邏輯完成，釋放鎖

假設一般坐票有1000張，那么會有1000次鎖業(yè)務操作，假設業(yè)務持續(xù)鎖時間0.1秒（這個需要實際去進行壓力測試），一秒鐘處理10條記錄，需要2分鐘才能消化。而且這兩分鐘內oracle連接也被占用，后續(xù)的請求排隊，系統(tǒng)緩慢，然后假死。這里面我們可以設置一個值，假設超過5秒，還沒有辦法獲取到鎖，自動釋放連接，數據庫返回錯誤，客戶端可以選擇重試查詢票數或者報錯給客戶，當然，這個涉及到客戶體驗，如果獲取不到鎖，基本上可以告知客戶票已經售完。

考慮到如果余票庫有10個，那么就可以分攤一秒鐘就可以100請求。這個具體還是，不過以上只是假設，需要有實際的數據以及壓力測試要測試一下性能。

b 無票：直接釋放鎖

基本上非常快，不會占用資源。在下一個查詢周期就不會在鎖定記錄，因為直接在緩存出就排除了。

所以個人認為使用悲觀鎖不會存在太大的問題，只要庫設計的合理，鎖超時時間設計的合理，對請求進行有限的控制，是可以支持的，當然，這個要求實際去檢測。

3 不需要鎖，只需要一臺應用服務器啟動線程處理購票，也不需要應用集群？

那可以想象一下，所有的購票請求都會同時請求到那一臺處理購票的服務器上，假設這個每秒鐘處理1000請求（這個據我所知已經算高了）基本上高峰期幾秒種的數據就把服務壓掛了。并且這個是單點，一旦這一臺服務器掛了，整個系統(tǒng)癱瘓。

4 余票數據可以放在內存中嗎？

放在內存，也就是放在內存緩存里面，這個問題有以下幾個？

1 緩存故障

當緩存出現故障的時候，怎么辦？當然可以緩存集群，切換到另外一臺緩存服務器，但是余票的數據如何同步？兩者不一致怎么辦

2 系統(tǒng)發(fā)布

當系統(tǒng)發(fā)布的時候怎么解決緩存中的數據庫問題，當然可以先把請求處理完成，然后在發(fā)布。或者發(fā)布之前，把緩存的數據同步到數據庫中，這樣也是可以的。但是設計上太復雜。

3 極端情況

硬件故障

操作系統(tǒng)故障

機房斷電

這些故障都會導致內存數據丟失，余票數據都丟失了

我就知道我所在的公司遇到的變態(tài)的情況如下：

機房無故斷電，網卡故障，磁盤寫入失敗，

經常遇到的情況是：jvm crash，內存泄漏，這些會導致放在內存的數據比較危險。

還有領域驅動設計和數據庫設計兩者沒有必要聯(lián)系。領域驅動是解決復雜業(yè)務領域的時候用的一種設計思想，自己在這方面開發(fā)比較多，和數據庫這一層設計沒有關系

對于性能來說，當然可以把所有的數據都放在內存里面，這樣的處理效率***，但是內存的數據就易丟失的數據。設計一個系統(tǒng)架構***的問題就是權衡利弊。對于火車票系統(tǒng)，在出票的流程上，相當于金融系統(tǒng)的轉賬，余票相當于用戶的余額，要保證***優(yōu)先級的安全性和一致性。這個性能相比，優(yōu)先級要高。

談談對架構的認識

這里在說說談談自己對架構的認識吧，架構不是說就只管系統(tǒng)的性能，架構是全局觀。涉及到安全性，可用性，性能，數據一致性，可擴展性等等。每個系統(tǒng)的應用特點不一樣，所以思考的重點不一樣。金融類系統(tǒng)對可用性和安全性數據一致性要求非常高，不能有任何的妥協(xié)，寧可犧牲性能，這就是為什么銀行喜歡用IBM的產品。新浪這樣的網站，性能很重要，但是如果丟失的用戶少量數據，無所謂，所以數據可以放在內存里面，甚至可以用nodejs這樣的新技術來實現。鐵道部這樣的***系統(tǒng)，可用性一定是在***位的，其次是數據一致性，然后才是性能。就扯這么多，每個人的觀點不一樣，但是架構就是這么虛的東東。關系型數據庫目前證明還是最可靠的，你能想象金融類帳務系統(tǒng)用的是NoSql這樣的對事務要求不高的數據庫嗎？所以關系型適合在購票這樣的核心應用。其他的庫可以用NoSql來實現，比如會員庫，沒有問題。

渠道購票分配

上一篇文章提到了這個渠道訂票的需求，目前有兩種方式進行數據庫層面的設計，***種是各個渠道的數據切割開，互補影響，也就是說我網絡訂票不影響窗口售票，我想這個需求還是比較合理的，有限保證窗口票，那么可以把數據庫水平分割，按照渠道來設計

這種設計的***好處，就是各個渠道訂票完全是分割開的，互相都不影響，但是這樣***的問題就是事先算好每個渠道的票的配合，比如窗口100張，網絡20張，代售200張，電話30張。非常不靈活，比如假設我窗口還有票，但是窗口沒有人買，怎么辦，那只能其他渠道來賣。這樣也比較浪費，畢竟大多數情況下，鐵道部的購票還是系統(tǒng)還不是那么繁忙的。

另外一種設計就是在渠道層做流量控制，讓流量控制這一層負責票數分配

這種設計方式就是比較考驗渠道層，渠道層需要做流量控制，這樣分配的***問題，就是分配均勻，所以很好的算法。但是數據庫層統(tǒng)一了，可擴展性比較強。容易進行擴容，也不會造成硬件的浪費。

兩種設計方式體現的思想不一樣，各有利弊。不過從更傾向于第二種設計方式，比較靈活。而且渠道流量這一層本身就必須的，這一層可以設計的比較厚，而且可以大量使用緩存或者NoSql。

余票庫的再分析

1   余票庫的分庫策略

昨天討論余票庫分庫策略，想起和一個鐵路工程師聊起，再想想自己電話訂票的時候，可以發(fā)現更好的分庫方式。下面是從百度百科搜到的鐵道部的組織架構：

鐵道部下面分為18個鐵路局，我估計每個鐵路局負責的車次不一樣，那么分庫就可以按照鐵路局分庫，這樣就可以分為18個數據庫。但是考慮到余票庫的實際數據量并不大，只是高并發(fā)，我們沒有必要分成18個庫。但是我估計由于利益分配，這個18個鐵路局應該每個鐵路局都有自己的數據中心。但是我們這是純技術層面的分析，先不考慮利益和實際情況。我們可以按照鐵局路分庫，但是前提是負責賣票的車次都不一樣，否則一個車次，分到兩個庫里面系統(tǒng)會變的很復雜。假設范圍分為四個，東南西北，比如（哈爾并，沈陽，北京，呼和浩特）一個庫。這樣我們就有一個簡單的模型了，那么在梳理一下一次典型的購票數據流

其中虛線圈起來的部分是要保持數據一致性。

簡單的說就是 余票減少一張，車票庫待支付記錄就會多一條；車票支付成功，車票狀態(tài)要變更，支付數據完成，短信要發(fā)送，當然這個要看你對一致性要求有多高，車票購票成功，短信發(fā)送不一定要成功。但是車票支付成功，支付數據總要有，并且是成功的吧。這個要進行對賬的，否則就是一筆糊涂賬。據說鐵道部還會建立會員營銷系統(tǒng)，那么越來越多的功能就會更復雜，比如支付成功，積分增加一百，積分以后可以進行車票的支付等等。不過這個不是核心，如果能繼續(xù)寫，在分析吧。

至于在分布式環(huán)境下如何保持數據一致性，這個我會專門寫幾篇文章來進行分析，我覺得這個是比較有價值的。

2 如何確定余票

這個是第二篇博文中我沒有寫的，我覺得這個是最復雜的，現在繼續(xù)分析。

確定余票的因素：日期，車次（假設動車，普通車次不重復），出發(fā)站，到達站，席位

其他三個很容易從數據庫中獲取，這里不說了，主要是出發(fā)站，到達站兩個維度。

如果通過其實出發(fā)站和到達站進行查詢，首先我們根據車站確認可以通的車次，可以簡化為對N個車次查詢，在根據出發(fā)站，到達站進行分析

假設 車次Z27，坐票，20121001，中途經過5站（A，B，C，D，E），共有100張，簡化記錄為(A->E) = 100

假設用戶U1買了從A->E的車票一張，那么還剩下99張, 就是 (A->E) 99

假設用戶U2買了從A->C，那么  (A->E) = 98 ,(A->C)=98 (C->E) = 99

假設用戶U3買了從C->D, 那么 (A->E) =97 ,(A->C) = 98 , (C->E) = 98 (C->D) = 98 , (D->E) 99

看來越來越復雜，但是我們發(fā)現這個和二叉樹有關，看一下下面的圖，不斷構造一個樹的過程，而且判斷票和也查找節(jié)點有關，找到之后此節(jié)點票數-1，所有的父節(jié)點票數-1。我算法不好，只能想到這個算法了，不知道有沒有更好的算法，這個樹不需要實時更新，放在內存里面。這樣就方便查詢了。

整個架構的基本模型

把***篇和第二票文章整理的內容在綜合整理以下，在應用在豐富以下，可以搭建一個簡單的分布式系統(tǒng)的應用原型，透過這個原型，我們在不斷的完善系統(tǒng)

目前鐵道部可能的架構模型

***看到鐵道部的組織架構，感覺鐵道部的系統(tǒng)架構可能大致是這樣的：隨便亂太猜想的，下面一個簡單的模型，實際情況遠遠比這個復雜。

由于數據中心是分布的，所以系統(tǒng)很慢。因為數據這一層路由，都是遠程調用啊。同時鐵道部的應用應該也是分布部署的，由于數據中心不集中，花在系統(tǒng)間通信的成本太高。感覺這個可能是鐵道部內部的政治格局導致的，以前的銀行都是這么搞的，每個省都有自己的一套系統(tǒng)。

后續(xù)

寫了這么多，先休息一段時間吧，后續(xù)有時間在繼續(xù)分析這個系統(tǒng)，今天也恰好看到一個新聞：

據介紹，12306互聯(lián)網購票系統(tǒng)是基于中國鐵路客票發(fā)售和預訂系統(tǒng)（簡稱客票系統(tǒng)）這一核心系統(tǒng)構建的。客票系統(tǒng)在10余年的運營過程中先后完成6次升級：1.0版本實現了計算機售票取代人工硬板票，2.0版本實現了區(qū)域級聯(lián)網，3.0版本實現了全國聯(lián)網售票，4.0版本實現了與清分清算系統(tǒng)的對接，5.0版本實現了席位復用和共用，5.2版本實現了實名制售票、電子客票和電子支付。

由于2.0版本是區(qū)域級別售票，3.0實現全國聯(lián)網售票，但是我估計所謂實現全國聯(lián)網售票，因為是在2.0的基礎上通過適配和路由搭建的，鐵道部應該還沒有統(tǒng)一的數據中心，數據應該是各個鐵路局控制的。

4.0版本主要做清分系統(tǒng)，這個就是內部的核算系統(tǒng)，應該算是鐵道部內部最為復雜的一個系統(tǒng)了，比如我賣了1000張票，應該得多少錢，應付給代售點和合作商戶做多少錢。

5.0可能就是上面說的同一個位置，由于區(qū)域段不同，可以買兩張以上的票，只要鐵路段不重復，也就是我說的余票樹模型。

5.2就是實名制和增加了電子支付和電子客票，這個應該稍微簡單一點，只是增加了一種支付工具和驗票手段。所以版本號就沒有怎么升級。

看看新的客票系統(tǒng)的愿景;

鐵道部透露，新一代客票系統(tǒng)實現了四方面創(chuàng)新。一是服務模式創(chuàng)新，系統(tǒng)支撐包括票務服務、旅行服務等各種延伸服務在內的預訂業(yè)務。二是營銷理念創(chuàng)新，對鐵路列車開行、運力調整、票價優(yōu)惠等提出合理化建議；制定鐵路客戶常旅客計劃，建立旅客積分、獎勵制度。三是管理手段創(chuàng)新，滿足淡旺季不同客流特點下的售票組織需要。四是技術架構創(chuàng)新，研發(fā)高性能核心交易平臺。

從業(yè)務角度來看，

1 鐵道部想建立客戶模型，目前鐵道部還沒有客戶模型，畢竟實名制剛開始，區(qū)分優(yōu)質客戶以及黑名單。未來可能你座的越多，可能走優(yōu)先貴賓通道上車等等

2 建立積分模型，這個主要是用來營銷，和航空和銀行一樣，估計就是換禮品什么的

3 技術架構創(chuàng)新，我覺得這個是最重要的，現在的架構可能因為歷史的原因，比較弱。

4 高性能核心交易平臺：這個是必須的，類似淘寶那樣的交易平臺。從全球性來看，ebay的交易平臺比較強大，不過淘寶最近的交易數據不知道超過ebay沒有。這個交易平臺未來會不會開放，也是一個想想的空間。

未來還可以想想的是，一旦鐵道部建立的會員模型，更有可能往金融上面去靠攏，建立自己的賬戶模型，推出更多的支付方式，比如預存款，聯(lián)名卡等等。鐵道部相當于擁有最多實名制會員的公司，想象空間很大。但是前提是系統(tǒng)要做得好，別再被人罵。

原文鏈接：http://www.cnblogs.com/aigongsi/archive/2012/09/20/2694155.html

【編輯推薦】

1. 鐵道部新客票系統(tǒng)設計（二）
2. 鐵道部新客票系統(tǒng)設計（一）
3. ASP.NET Cache的一些總結
4. ASP.NET中常用的幾種身份驗證方式
5. 各自為政：ASP.NET實現團隊分工的思考