專家訪談12306

目錄(?)[-]

您是否在春節(jié)國慶期間在12306上買過票談?wù)勗撓到y(tǒng)的用戶體驗

在去年國慶之前12306進(jìn)行了改版加入了排隊系統(tǒng)您認(rèn)為加入排隊系統(tǒng)的目的是什么緩解了哪些問題

春運購票與淘寶天貓在雙11期間的促銷有什么異同之處

淘寶天貓是如何應(yīng)對這種超大規(guī)模并發(fā)的如何hold住暴增的流量

您認(rèn)為這些經(jīng)驗中哪些可以應(yīng)用到12306

在系統(tǒng)業(yè)務(wù)設(shè)計上12306還存在哪些挑戰(zhàn)

您認(rèn)為高性能并發(fā)系統(tǒng)架構(gòu)應(yīng)該如何設(shè)計關(guān)鍵是什么

有人提議12306采用NoSQL存儲您認(rèn)為是否可行

如果使用開源來實現(xiàn)您有什么建議

從目前來看您認(rèn)為12306需要著重改善哪些方面如果讓您來設(shè)計您會如何做

莊表偉與12306相關(guān)的一些思考

其他

由于春運，鐵道部官方訂票網(wǎng)站12306流量暴增，其Alexa排名一度進(jìn)入前200，網(wǎng)友戲稱，12306已經(jīng)成為“全球最大、最牛的電商網(wǎng)站”。由于流量激增，12306系統(tǒng)頻頻癱瘓，一度出現(xiàn)登不上去、登上去搶不了票、搶到票需排隊、排隊后出票失敗等局面。系統(tǒng)的用戶體驗、性能遭到用戶大量的不滿。?

我們邀請了幾位系統(tǒng)架構(gòu)方面的專家，請他們從技術(shù)的角度為你剖析12306（我們會陸續(xù)增加其他幾位專家的回復(fù)）。同時我們還從論壇活動（暢聊12306，贏精美禮品）中選取了一些精彩回復(fù)。如果您對這些問題有獨到的見解，歡迎在本文中評論或參與論壇討論。

您是否在春節(jié)/國慶期間在12306上買過票？談?wù)勗撓到y(tǒng)的用戶體驗！

范凱?? 寫道 春運和國慶期間沒有買過。但去年夏天在12306上面買過票，結(jié)果沒有買到票，改買了飛機票。?

我只用過一次，體驗不深。感覺系統(tǒng)不太穩(wěn)定，我訪問的時候看到過Java出錯拋出的錯誤堆棧信息。

陳雄華?? 寫道 有。界面很象是企業(yè)MIS，顯得很粗糙，交互性，體驗性都感覺很次。

runfriends（來自論壇回復(fù)） 寫道 我知道它很難用，所以我從來沒用它買過票。去年國慶節(jié)查詢個票，慢的要命。?

從sql的拼寫到頁面優(yōu)化，從程序架構(gòu)到服務(wù)器架構(gòu)都需要全面重構(gòu)。居然不是參數(shù)化查詢sql，而是查詢參數(shù)拼到sql里的，完全是一群業(yè)余選手的習(xí)作。??

應(yīng)該采用js、css、圖片、html都應(yīng)該啟用gzip壓縮，所有css應(yīng)減少到一個，js文件該合并的合并，能重用的重用，頁面背景圖應(yīng)盡量合并成一個文件。盡量減少http請求數(shù)。

在去年國慶之前12306進(jìn)行了改版，加入了排隊系統(tǒng)，您認(rèn)為加入排隊系統(tǒng)的目的是什么？緩解了哪些問題？

范凱??? 寫道 對具體情況我不太了解。我猜測，實時購票是一個高并發(fā)的在線事務(wù)處理系統(tǒng)，需要通過排隊系統(tǒng)來緩解事務(wù)并發(fā)造成的鎖定吧。

陳雄華??? 寫道 排隊是緩解資源并發(fā)的一次不錯的策略，可以在后端資源不足時，將客戶端請求暫存在池中，方便系統(tǒng)資源的調(diào)度。

runfriends（來自論壇回復(fù)） 寫道 剛開始的時候看到網(wǎng)上很多人說它有一個巨大的事務(wù)。后來又加入了排隊系統(tǒng)。至于為什么個人猜測可能是為了降低數(shù)據(jù)庫壓力。?

而實際上，用戶并發(fā)量并沒有變化，排隊導(dǎo)致大量訪問不能盡快返回，占用了大量系統(tǒng)資源。實際上這樣做降低了系統(tǒng)吞吐量。數(shù)據(jù)庫壓力有沒有降低先不說，系統(tǒng)吞吐量肯定會降低。

czwlucky（來自論壇回復(fù)） 寫道 我認(rèn)為增加這個功能的意義在于，當(dāng)你不能立即買上票時，不用再不停的反復(fù)刷新提交了，相當(dāng)于銀行里發(fā)給你一個“號碼”，等叫你時你過來買票就是了，不用站那兒傻等。一方面增強了用戶體驗感，另一方面也能節(jié)約反復(fù)請求帶來的壓力。?

但我認(rèn)為買票難根本原因不在于這個，12306網(wǎng)站的壓力自然是大的，但這表面的背后卻隱藏著更多的問題，為什么一票難求？ 我們問自己一個問題：究竟一列火車有多少張票可賣？ 你會發(fā)現(xiàn)沒有答案！ 如果真的沒有答案，那即便你把12306刷到爆，也無濟于事。?

所以我認(rèn)為，在系統(tǒng)設(shè)計上不是問題，像淘寶、天貓一樣有大量的訪問者，解決方案也不是就一個。 問題還是在于業(yè)務(wù)的設(shè)計上，只有把出票規(guī)則定合理了，系統(tǒng)才能更好的為大家服務(wù)，我們也不用去刷網(wǎng)站了，壓力自然也會因此而小一些。?

無論是從新聞上了解的，還是我親身經(jīng)歷的，都證明從始點站開始買票會相對容易些，因為開始出票時，票數(shù)還是較多的（雖然也不是很多，大家都似懂非懂的），但從中間站點開始買票，票數(shù)少的可憐，甚至是０（網(wǎng)絡(luò)延遲造成的）。這里面有一個二次售票的概念，怎么把這個二次售票的問題解決了才可能改善購票難問題。?

二次售票我相信有它存在的理由。 但問題時它存在的理由真的注定它只能是現(xiàn)在這樣的方式存在嗎？ 我也相信這個業(yè)務(wù)規(guī)則一定有改進(jìn)的地方。?

公交車，火車，長途汽車，在售票方式與運輸距離，輸送量上有很大差別，但運輸本質(zhì)沒有差異。我們是不是能參考公交運輸中的一些優(yōu)點呢？比如是不是有可能增加同一線路的車次？ 如果不能增加車次，是不是可以考慮沿途換乘方案？

春運購票，與淘寶、天貓在雙11期間的促銷有什么異同之處？

范凱??? 寫道 相同之處應(yīng)該都是高并發(fā)的在線事務(wù)處理系統(tǒng)，我猜測主要不同之處在于12306背后的票務(wù)系統(tǒng)可能不是一個集中式的系統(tǒng)，而可能連接各個鐵路局票務(wù)系統(tǒng)，數(shù)據(jù)同步的實時性和一致性可能更復(fù)雜一些。當(dāng)然這些都僅僅是猜測，可能很不靠譜。

陳雄華??? 寫道 淘寶一天就處理了1億零580萬，而12306一天處理的交易僅僅166萬條 ，如果從并發(fā)性上來說，淘寶的并發(fā)量遠(yuǎn)比12306大，但天貓的商品信息，促銷數(shù)據(jù)都可以做緩存，做CDN，而12306的“商品”是一個個座位，這些座位必須通過后端數(shù)據(jù)庫即時查詢出來，狀態(tài)的一致性要求很高。?

從這點上看，12306的商品信息很難利用到緩存，因此12306查看“商品”的代價是比較大的，涉及到一系列的后端數(shù)據(jù)庫操作，從這個角度講，12306的復(fù)雜度是高于天貓的。

淘寶、天貓是如何應(yīng)對這種超大規(guī)模并發(fā)的？如何hold住暴增的流量？

范凱??? 寫道 這個我確實不知道，需要請阿里系的專家來解讀。?

（小編：阿里專家正在路上，Coming Soon！敬請期待！）

陳雄華??? 寫道 這是一個系統(tǒng)性的功能，簡而言之就是：分布式和緩存。

您認(rèn)為這些經(jīng)驗中哪些可以應(yīng)用到12306？

范凱??? 寫道 據(jù)我個人了解的八卦，去年春運12306宕機之后，曾經(jīng)求教過阿里，當(dāng)時阿里派出了一支技術(shù)團隊去了解情況和提供建議。 實事求是的說，12306相比一年前還是有所進(jìn)步的，不知道是不是背后有阿里系專家的貢獻(xiàn)。

陳雄華??? 寫道 參見第7條。

在系統(tǒng)、業(yè)務(wù)設(shè)計上，12306還存在哪些挑戰(zhàn)？

范凱??? 寫道 我覺得12306面臨的主要挑戰(zhàn)就是兩個方面：?

• 一、實時高并發(fā)在線事務(wù)處理；
• 二、如何和各個鐵路分局票務(wù)系統(tǒng)對接，保證數(shù)據(jù)同步的實時性和一致性。

陳雄華??? 寫道 淘寶的商品相對獨立，而12306商品之間的關(guān)聯(lián)性很大，由于CAP定律限制，如果其商品的一致性要求過高，必然對可用性和分區(qū)容錯性造成影響。?

因此，業(yè)務(wù)設(shè)計上，如果找到一條降低一致性要求時，還能保證業(yè)務(wù)的正確性的業(yè)務(wù)分拆之路。舉個例子，火車票查詢時，不要顯示多少張，而是顯示“有”或“無”，或者顯示>100張，50~100,小于50等，這樣就可以減小狀態(tài)的更新頻率，充分使用緩存數(shù)據(jù)。

czwlucky（來自論壇回復(fù)） 寫道 12306網(wǎng)站的技術(shù)問題或許有多種解決方案（雖然可能并不完美），但最難解決的是業(yè)務(wù)問題！?

一列火車總共有多少張票？恐怕這個就難回答，即使是鐵道上的人也不見得能回答的十分清楚。?

火車跟公交有幾分相似，都有固定站點，每個站點都可能有人上下。不同的是，公交車可以先上車后買票，火車只能先買票后上車。我想這才是問題的根本。公交上去了就上去了，上不去可以等下一趟。火車得先有票才能上車，可是賣票規(guī)則卻成了難解之題。

您認(rèn)為高性能并發(fā)系統(tǒng)架構(gòu)應(yīng)該如何設(shè)計？關(guān)鍵是什么？

范凱??? 寫道 高性能并發(fā)系統(tǒng)其實分很多種類，是并發(fā)讀，并發(fā)寫，并發(fā)長連接，還是并發(fā)事務(wù)？不同類型的架構(gòu)設(shè)計是不同的。具體到12306就是并發(fā)事務(wù)，在這個領(lǐng)域，我個人沒有什么經(jīng)驗。

陳雄華??? 寫道 1)? 優(yōu)化前端網(wǎng)頁?

• 充分利用CDN，使JS、圖片等靜態(tài)資源的請求能夠就近訪問（順便說一下，如果12306訂票插件能從google提供的http://cdnjs.com中引用JS，而不去直接引用github的JS，就不會把github搞癱了）。
• 將JS、CSS合并，最小化請求數(shù)。將JS和CSS壓縮，最小化數(shù)據(jù)傳輸
• 啟用gzip壓縮網(wǎng)頁。

2)? 群集分發(fā)和調(diào)度?

據(jù)說12306是采用集中式構(gòu)架的，集中式構(gòu)架很難應(yīng)對高并發(fā)，也很難水平擴容，分布式不是僅僅將調(diào)度服務(wù)器，應(yīng)用服務(wù)器，緩存服務(wù)器，數(shù)據(jù)庫服務(wù)器分開就行，應(yīng)該進(jìn)行更細(xì)的服務(wù)級劃分，對業(yè)務(wù)進(jìn)行服務(wù)細(xì)分，做成一個個松散耦合的服務(wù)，然后把這些服務(wù)獨立分布式部署。?

3)? 采用分布式會話?

為了可以進(jìn)行靈活的請求調(diào)度，不應(yīng)采用weblogic、websphere這些應(yīng)用服務(wù)器自身的session管理用戶會話，而應(yīng)該自己管理會話，如將會話保存在獨立的集群memcached服務(wù)器中，這樣每個應(yīng)用服務(wù)就都無狀態(tài)了，會話的請求可以隨意分發(fā)給不同的服務(wù)器。這也是我的ROP開源項目沒有使用HttpSession，而專門抽象出一個SessionManager接口的原因，開發(fā)者應(yīng)該自己去實現(xiàn)這個接口實現(xiàn)分布式會話管理。?

4)? 關(guān)于數(shù)據(jù)庫設(shè)計優(yōu)化?

數(shù)據(jù)庫往往是系統(tǒng)瓶頸所在，首先應(yīng)該對數(shù)據(jù)庫進(jìn)行分庫設(shè)計，可采用兩級水平切割，如首先切割成幾個物理庫，然后在物理庫內(nèi)部再采用表分割，一般是通過某個業(yè)務(wù)ID進(jìn)行取模切割，降低單庫及單表的并發(fā)性，提高TPS。?

合理采用讀寫分離技術(shù)，做到讀寫分離，可以一寫多讀，有效降低數(shù)據(jù)庫的負(fù)載，數(shù)據(jù)的同步可以視情況采取應(yīng)用層同步寫，讀取數(shù)據(jù)庫日志更新或直接使用mysql讀寫分離技術(shù)等。?

此外，業(yè)務(wù)服務(wù)化、服務(wù)解耦化是關(guān)鍵。

runfriends（來自論壇回復(fù)） 寫道 個人認(rèn)為針對不同的系統(tǒng)要有不同的設(shè)計方案。?

雖然12306可以歸類為電商領(lǐng)域，但是跟通常意義上的B2C還是有巨大的差異。所以單純從12306上面討論高性能并發(fā)系統(tǒng)架構(gòu)并沒有通用意義。?

不過，有一個思想應(yīng)該貫徹。那就是所有訪問力求分散到不同的服務(wù)器處理，不同類型的資源要堅持使用不同的集群服務(wù)。動靜分離、讀寫分離，減少一次頁面訪問的請求數(shù)和數(shù)據(jù)庫訪問次數(shù)，保持小事務(wù)粒度，注意線程安全，避免大數(shù)據(jù)量的查詢，建立索引（多表聯(lián)合、union、非參數(shù)化sql、笛卡兒積計算、返回大數(shù)據(jù)集等數(shù)據(jù)庫操作應(yīng)該避免）。?

對于變化較小的查詢操作可將查詢工作交給專門的索引服務(wù)器完成。不過個人感覺像12306這樣的業(yè)務(wù)，引入索引的意義不大也沒有必要。?

12306的業(yè)務(wù)需求乍一看似乎都是同一類型的資源，但是我們可能根據(jù)車次、臥、軟、硬、站、時段、線路等信息將車票這個12306要處理的惟一類型的資源分成若干子類，不同的子類請求由不同的集群處理。

有人提議12306采用NoSQL存儲，您認(rèn)為是否可行？

范凱??? 寫道 NoSQL的優(yōu)勢在于海量無模式數(shù)據(jù)存儲和查詢，12306的挑戰(zhàn)在于并發(fā)事務(wù)處理，所以用NoSQL無助于解決12306面臨的問題。

陳雄華??? 寫道 純用NoSQL個人認(rèn)為現(xiàn)在還不成熟，畢竟NoSQL的狀態(tài)一致性不好。一條可行的路子是MySQL+NoSQL，通過nosql緩解后端MySQL的壓力。?

當(dāng)然這涉及到很多業(yè)務(wù)流程的優(yōu)化設(shè)計，降低數(shù)據(jù)一致性要求后才能合理使用NoSQL。

runfriends（來自論壇回復(fù)） 寫道 事務(wù)的粒度應(yīng)做到購買行為是原子性的，即保證兩個人不會買到相同的票即可。每個票種的優(yōu)先級是一樣的，應(yīng)不同的查詢條件保證能盡快的返回。?

實際上每天出售的票種總和遠(yuǎn)達(dá)不到海量的程度。但是每年有幾個時段并發(fā)量特別大。如果使用大量nosql數(shù)據(jù)庫集群，票量一致性恐怕難以保證；如果使用單臺nosql，恐怕吞吐量和實時響應(yīng)也會像mysql一樣難以做到。?

不論什么數(shù)據(jù)庫，都難以完成這么少的數(shù)據(jù)量卻要完成這么大并發(fā)量的情況。?

個人認(rèn)為還是把不同票種分散在不同票池服務(wù)器中，完全由程序操作內(nèi)存完成查詢和購買更合適一些，雖然數(shù)據(jù)結(jié)構(gòu)可能要復(fù)雜很多。?

最后根據(jù)每個票種的余票量要限制每個票種的查詢和購買并發(fā)量。超過的就拒絕訪問，以節(jié)省資源。早死早超生，而不是所有人都耗在買票這個事上。

12306 如果使用開源來實現(xiàn)，您有什么建議？

范凱??? 寫道 其實用WebLogic應(yīng)用服務(wù)器，Oracle數(shù)據(jù)庫，SSH框架和C3P0連接池都是OK的，但要解決12306面臨的并發(fā)事務(wù)問題，需要系統(tǒng)在基礎(chǔ)設(shè)施和架構(gòu)上做很多專門的調(diào)整和開發(fā)的工作，? 這些才是解決問題的關(guān)鍵，和用什么軟件和框架關(guān)系不大。

陳雄華??? 寫道 預(yù)算很大一部分都要來買weblogic、oracle的授權(quán)了，好鋼用在了刀背上。完全可以用jboss代替weblogic，用mysql代替oracle，把這些省下的錢請技術(shù)專家，遠(yuǎn)比買這些東西好用。?

另外，這種高并發(fā)的互聯(lián)網(wǎng)的應(yīng)用不建議使用Hibernate，建議直接使用Spring JDBC，畢竟Hibernater操作數(shù)據(jù)庫往往不夠細(xì)粒度。另外還建議使用Spring MVC替代Struts，Spring MVC比Struts更高效性，頁面盡量使用客戶端的技術(shù)而不要使用服務(wù)端的技術(shù)實現(xiàn)，如使用客戶端的requirejs+underscore客戶端模塊就比使用服務(wù)端的JSP或Freemarker要好，畢竟這樣就讓客戶機來負(fù)責(zé)頁面渲染了，且可以有效地使用CDN。

從目前來看，您認(rèn)為12306需要著重改善哪些方面？如果讓您來設(shè)計，您會如何做？

范凱??? 寫道 12306從前端頁面上來看用戶體驗就比較差，至少從頁面設(shè)計和前端JS代碼上來說就有巨大的改進(jìn)空間了。后臺架構(gòu)上需要解決高并發(fā)事務(wù)處理，和分布式數(shù)據(jù)同步的實時性和一致性問題，在這兩個問題上，我個人也沒有太多相關(guān)實踐經(jīng)驗，有一些個人的想法，但還是不誤人子弟了，這些方面可以請阿里系的專家來解答。

陳雄華??? 寫道

• web前端要大筆優(yōu)化，采用requirejs+jquery+backbone+underscore框架，web應(yīng)用要進(jìn)行部署優(yōu)化js合并，js壓縮；
• 所有業(yè)務(wù)SOA化，以便可以將業(yè)務(wù)分布式部署；
• 數(shù)據(jù)庫分庫，二級切分,實現(xiàn)讀寫分離，從業(yè)務(wù)流程調(diào)整上降低對數(shù)據(jù)一致性的要求；
• 充分使用nosql技術(shù)，通過流程優(yōu)化和調(diào)整，使nosql承擔(dān)大量的數(shù)據(jù)訪問請求，使nosql成為保衛(wèi)后端mysql的一道堅強的保障。

runfriends（來自論壇回復(fù)） 寫道 鐵道部應(yīng)該對每節(jié)車廂、每個車次要賣出多少站票、軟座、硬座、臥鋪有一個規(guī)劃。購買同一車次和票種的人不會造成太高的并發(fā)。因此關(guān)鍵在于查詢和買票服務(wù)器集群的設(shè)計和實現(xiàn)。?

設(shè)計一個票池系統(tǒng)，按照車次、線路、區(qū)域劃分票池，按照車次、站、軟、硬、臥分類不同票種，將每個票種分配到票池集群的某臺服務(wù)器上。買票時肯定已經(jīng)確定了票種，通過一致性哈希準(zhǔn)確定位指定票種所在的服務(wù)器。票池系統(tǒng)完全采用內(nèi)存儲存預(yù)售票票種、票量信息。?

查詢、購買分開不同的集群，兩個集群之間實現(xiàn)余票量同步。保證每個操作迅速返回，不必保證查詢和購買實時同步，也不必保證查到的票在購買的時候一定能買到。

莊表偉：與12306相關(guān)的一些思考

鐵路購票的12306網(wǎng)站，我也在上面購買過火車票，雖然的確存在著各種各樣的問題，但是最終確實成功的買到了票，而且也順利的坐上了火車。也許因為不是在春運期間購買的緣故，說實話，我對它的印象沒有那么糟糕。?

當(dāng)然，如果我們看看網(wǎng)絡(luò)上的新聞，搜索微博里的各種人對12306的批評、責(zé)罵與嘲諷...是的，他們做得糟透了。?
但是，在我看來，痛罵他們的技術(shù)如何垃圾，并沒有追蹤到問題的本質(zhì)，本文試著繼續(xù)深入的追究下去。?

一、不要外包?

分布式系統(tǒng)的第一原則是：不要分布式！而外包系統(tǒng)的第一原則是：不要外包！前一句，有很多高人說過，后面這一句，是我杜撰的。而我之所以會提到這個問題，是因為網(wǎng)絡(luò)上有很多類似的觀點，似乎是因為這次的外包開發(fā)沒有找好，如果將這個活包給淘寶、支付包、京東、亞馬遜之類的大型成熟電商來做，就萬事大吉了。事實上，這些成熟電商之所以成熟，恰恰是經(jīng)過了長期的改進(jìn)完善之后的結(jié)果，而且，一定是他們自己的開發(fā)團隊完成的。另一個近在眼前的例子，想想蘇寧易購吧。直接一點說，如果這事外包給淘寶來做，就算淘寶有人有時間也愿意接這個活，也肯定干不好。?

為什么外包通常搞不好呢？因為他們不是自己人，他們沒有跟著一個企業(yè)同步成長的體會。因為他們希望獲得整理明白后的一本“需求匯總”，他們害怕反復(fù)不斷變動的需求。當(dāng)然，我這個觀點，可能存在著某種偏見，但是，越是變動復(fù)雜，極其核心，影響巨大的系統(tǒng)，我都強烈的不建議交給外包來完成。?

二、循序漸進(jìn)?

一個非常龐大的電商網(wǎng)站，都不是一天建成的，淘寶不是一天建成的，亞馬遜、京東也不是一天建成的。我們怎么能夠希望12306在第一次推出的時候，就能夠支撐春運購票這樣變態(tài)的需求呢？?

為了限制需求，其實可以有很多種辦法：比如限制特定的班次（只賣高鐵票、臥鋪票、只賣從起點到終點的票等等）、比如網(wǎng)絡(luò)購票加價，比如只在平時提供使用而不是在春運期間投入使用。總之，不需要一開始就服務(wù)所有的用戶，選定一個較小的范圍，先服務(wù)好，再循序漸進(jìn)，逐步擴大服務(wù)的范圍、提升服務(wù)的效率與質(zhì)量，才是較為穩(wěn)妥的辦法。?

三、排隊系統(tǒng)?

在12306網(wǎng)站推出之前，我們的購票體驗同樣糟糕，客觀的說，只怕更糟。但是為什么反而沒有什么人來罵呢？很多人在說，因為12306的用戶體驗做得不夠好，但是我想要反其道而談之。如果網(wǎng)站的用戶體驗?zāi)軌蛳癞?dāng)初的實際購票一樣差，只怕反而更加好一些。?

回顧一下傳統(tǒng)的購票流程吧：來到購票大廳，首先要選擇一個窗口排隊，運氣不好的時候，自己選擇的那一隊恰恰是最慢的。經(jīng)過幾個小時甚至十幾個小時的排隊，我們來到了窗口前，遇到的是心煩意亂的售票員大媽，她們通常態(tài)度惡劣卻動作迅速，到哪里？沒有！賣完了！只有站票了，要不要？不要就換下一個！看清楚了嗎？確認(rèn)我就出票了。?

窗口前的購票者，在身后巨大的目光壓力之下，在面前不耐煩的語言壓力之下，做著迅速的購買決定。這種購票體驗，真的是太爛了。唯一的好處是：當(dāng)我們拿到了那張紙片，就放下心來，肯定能回家了。?

假設(shè)，我們一開始就把12306做成一個售票大廳的模式，總共就100個窗口，每個人都登錄以后先排上10個小時的隊，一旦排上了，輪到自己了，購票時間不會超過2分鐘。那么，雖然是漫長的10小時的等待，卻不需要時刻守在電腦前站著。這種體驗，我想就足夠了。?

從12306的角度而言，完全可以將系統(tǒng)按照每個城市一個售票大廳的方式來部署，一開始假設(shè)只有100個窗口，人再多也是這么排著。等到系統(tǒng)穩(wěn)定了，能力上去了，再慢慢的增加窗口的數(shù)量，縮短排隊的時間。痛罵的人，將會少很多很多。原因很簡單，不要一開始就給用戶一個很高的期待值，然后再讓他們失望，而是基于現(xiàn)狀，小步快跑的做著改進(jìn)。反而會有較好的效果。?

這種做法，其實在網(wǎng)游行業(yè)是基本常識，隨著用戶數(shù)量的增加，新增一組一組的服務(wù)器，以容納更多的玩家，而不是一開始就放開讓所有的人進(jìn)來玩。寧可不讓他們進(jìn)來，也不是讓他們進(jìn)來以后，在游戲場景里玩排隊的游戲。?

四、代售機制?

火車票代售網(wǎng)點，其實在很多年前就已經(jīng)出現(xiàn)了。我認(rèn)為這個模式其實很不錯，是一個分散客流提高效率的好辦法。假設(shè)，我們不做12306的網(wǎng)站，而是開辦成千上萬，甚至上百萬的火車票代售網(wǎng)店，情況會變成什么樣子呢？假設(shè)，我們降低火車票代售點的準(zhǔn)入門檻：交XX萬押金，下載一個代售點客戶端，自備電腦，自尋場地，自尋客源，自己去做生意。搞一個簡單的審批流程，每年新增批準(zhǔn)10萬個個體戶代售點。?

這樣的好處是：每個企業(yè)，每個公司，每個街道辦事處，都可以自己申請成為一個代售網(wǎng)點，然后解決身邊人購票的難題。在最大限度內(nèi)，減少集中排隊的壓力。另一方面，由于審批流程可以控制代售點的數(shù)量，同時也就保證了系統(tǒng)的壓力始終以可控的方式增長。?

我在內(nèi)心默默推理了一下，似乎是一個較為簡單可行的辦法。?

五、架構(gòu)演進(jìn)?

在網(wǎng)絡(luò)上，我們常常能夠看到很多給12306支招的方案，總之各種前衛(wèi)，各種先進(jìn)。但是，在我看來，越是復(fù)雜的系統(tǒng)，越是怕這種“革命”，哪怕過去的架構(gòu)再不合理，也最好不要貿(mào)然引入過于激進(jìn)的架構(gòu)，在原有的架構(gòu)下逐步演進(jìn)，逐步擴展，逐步尋找小范圍的、能夠被改進(jìn)的點來推進(jìn)，才是較為合理的做法。?

我能夠看到的很多對于12306的批評，常常是一直站著說話不腰疼的姿態(tài)，說實話，并不可取。就目前來看，我們最樂觀的估計是，12306能夠頂住壓力，逐漸改進(jìn)、完善，在3~5年之后，漸漸淡出人們的視線，成為一個普通的，日常必須使用的，生活服務(wù)類網(wǎng)站。?

六、抓大放小?

說起用戶體驗糟糕，每個人都可以滔滔不絕的說很多話。我們常常會看到這樣一種言論：鐵道部的官員，他們用12306嗎？如果他們也用，難道不會更加促使12306網(wǎng)站更快的改進(jìn)嗎？?

其實，從技術(shù)人員的角度而言，怕的就是大老板親自抓用戶體驗。當(dāng)然，比這個更加糟糕的，則是每個領(lǐng)導(dǎo)，都對用戶體驗，說三道四。?

對于12306的改進(jìn)，我想不必過于關(guān)注細(xì)節(jié)，追蹤一些統(tǒng)計數(shù)據(jù)的變化情況就好。比如：平均購票等待時間；退票率與廢票率；列車上座率等等。至于如何提高這些數(shù)據(jù)，領(lǐng)導(dǎo)們千萬不要事無巨細(xì)的參與討論，大家各自努力就好。有更多的事情得靠領(lǐng)導(dǎo)們努力：比如切實提高運力...

其他

runfriends（來自論壇回復(fù)） 寫道 第一：專業(yè)的事就應(yīng)該找專家來做。不論招標(biāo)也好，還是私下里尋找合作伙伴也好，都應(yīng)該挑選有高并發(fā)、高吞吐量這方面的專家完成。而這樣的人只存在于大型電商公司。鐵道部花了那么多錢卻沒去找正確的人來做這件事。?

第二：關(guān)鍵在于目的是什么。目的是花錢，還是為了方便買票，還是其它目的？?

第三：關(guān)于搶票插件的問題。如果網(wǎng)站本身響應(yīng)迅速，搶票插件也沒什么市場了。關(guān)鍵在于要去考慮怎么改善用戶體驗，而不是要去禁搶票插件。上頭意識從來都沒有做正確的事。?

酷殼博主說，就為了一年那么幾次，十幾天的高訪問量，花那么多錢開發(fā)一個購票網(wǎng)站，也就鐵道部能做的出來了。?

個人覺的，更好的做法是。鐵道部應(yīng)該可以把購票api開放出來。讓所有人都可以通過這些api開發(fā)購票網(wǎng)站。讓這些網(wǎng)站之間形成競爭。?

這樣訪問壓力分散到了不同公司的服務(wù)器，而鐵道部就是做了一個平臺。這樣做的效果更好。就像現(xiàn)在很多類似攜程這樣的網(wǎng)站都可以在上面訂飛機票一樣。?

另外，通過云計算將根據(jù)一年中不同時段的壓力彈性改變計算資源，也可以節(jié)省成本。 wangshu3000（來自論壇回復(fù)） 寫道 問題瓶頸（Front to Backgroud）：?

• Web端，每天請求上億，壓力很大，包括html js css img等，需要占用大量帶寬
• 身份證認(rèn)證，可能會用到第三方的認(rèn)證，或者鐵道部協(xié)議，獲取到身份證信息，這個查詢量也很大
• 交易，銀行性能應(yīng)該不在瓶頸
• 訂票記錄，采用按照車次分表，應(yīng)該是集中控制集群，分表 分區(qū) 索引，速度不會太慢
• 查詢余票，每次交易成功，更新訂票數(shù)據(jù)，更新量較大

分析：?

• 網(wǎng)站的內(nèi)容可以分布式部署，采用apache＋xxx分發(fā)，后臺多個鏡像分擔(dān)請求，進(jìn)行冗余;圖片、css、js、html、動態(tài)jsp、后臺業(yè)務(wù)，分別部署;并且對web進(jìn)行部分優(yōu)化，壓縮，合并，緩存等。
• 每次訂票數(shù)據(jù)流量在2M，每天1200w/8h/60min/60s，每秒420個訂票請求，840M/s的網(wǎng)絡(luò)流量，根據(jù)分布6種文件140M/s，一般光纖網(wǎng)絡(luò)就可以了;每種文件下面分布幾個cluster，性能足以支持，每秒70個請求。并不大
• 身份證第三方只要支持每秒1k＋的并發(fā)請求就足以支持訂票了。很容易
• 如果本地驗證身份證，根據(jù)省份、建立表，根據(jù)城市建立分區(qū)表，速度也會非常快，用身份證做主鍵，一條身份證信息0.2k，全國13億＝260G的數(shù)據(jù)量，easy，做個RAC就足以支持這種壓力了
• 銀行不考慮
• 車次，訂票記錄，余票記錄，每天7kw的記錄，14G/天，保存20天，才280G
• 訂票業(yè)務(wù)按照省份分布，每個省份單獨結(jié)算
• 整體采用SOA架構(gòu)，都是服務(wù)，每個服務(wù)專注自己的業(yè)務(wù)，優(yōu)化自己的服務(wù)
• 銀行交易需要大量校對和核實業(yè)務(wù)，也許要一些投入，算成本;需要對仗，異常情況分析等，屬于不是直接業(yè)務(wù)的處理，不能省略。
• 硬件IO，視情況而定優(yōu)化，EMC盤陣，RAID;數(shù)據(jù)分布存儲，根據(jù)數(shù)據(jù)量劃分group。
• CPU，內(nèi)存通過簡單增加刀的CPU和內(nèi)存來提高。
• 網(wǎng)絡(luò)，根據(jù)地點，業(yè)務(wù)分布到不同的節(jié)點進(jìn)行購票，每個節(jié)點的網(wǎng)絡(luò)吞吐可以控制，不會太高

總結(jié)

以上是生活随笔為你收集整理的社区专家谈12306的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。