url:http://www.iteye.com/magazines/110

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

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

目 錄 [ - ]
您是否在春節/國慶期間在12306上買過票？談談該系統的用戶體驗！
12306在去年國慶之前進行了改版，加入了排隊系統，您認為加入排隊系統的目的是什么？緩解了哪些問題？
12306春運購票，與淘寶、天貓在雙11期間的促銷有什么異同之處？
淘寶、天貓是如何應對這種超大規模并發的？如何hold住暴增的流量？
您認為這些經驗中哪些可以應用到12306？
12306在系統、業務設計上，還存在哪些挑戰？
您認為高性能并發系統架構應該如何設計？關鍵是什么？
有人提議12306采用NoSQL存儲，您認為是否可行？
12306 如果使用開源來實現，您有什么建議？
從目前來看，您認為12306需要著重改善哪些方面？如果讓您來設計，您會如何做？
莊表偉：與12306相關的一些思考
其他
您是否在春節/國慶期間在12306上買過票？談談該系統的用戶體驗！


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

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


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


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

從sql的拼寫到頁面優化，從程序架構到服務器架構都需要全面重構。居然不是參數化查詢sql，而是查詢參數拼到sql里的，完全是一群業余選手的習作。?

應該采用js、css、圖片、html都應該啟用gzip壓縮，所有css應減少到一個，js文件該合并的合并，能重用的重用，頁面背景圖應盡量合并成一個文件。盡量減少http請求數。
12306在去年國慶之前進行了改版，加入了排隊系統，您認為加入排隊系統的目的是什么？緩解了哪些問題？


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


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


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

而實際上，用戶并發量并沒有變化，排隊導致大量訪問不能盡快返回，占用了大量系統資源。實際上這樣做降低了系統吞吐量。數據庫壓力有沒有降低先不說，系統吞吐量肯定會降低。


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

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

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

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

二次售票我相信有它存在的理由。 但問題時它存在的理由真的注定它只能是現在這樣的方式存在嗎？ 我也相信這個業務規則一定有改進的地方。

公交車，火車，長途汽車，在售票方式與運輸距離，輸送量上有很大差別，但運輸本質沒有差異。我們是不是能參考公交運輸中的一些優點呢？比如是不是有可能增加同一線路的車次？ 如果不能增加車次，是不是可以考慮沿途換乘方案？
12306春運購票，與淘寶、天貓在雙11期間的促銷有什么異同之處？

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


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

從這點上看，12306的商品信息很難利用到緩存，因此12306查看“商品”的代價是比較大的，涉及到一系列的后端數據庫操作，從這個角度講，12306的復雜度是高于天貓的。
淘寶、天貓是如何應對這種超大規模并發的？如何hold住暴增的流量？

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

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


陳雄華??? 寫道
這是一個系統性的功能，簡而言之就是：分布式和緩存。
您認為這些經驗中哪些可以應用到12306？

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


陳雄華??? 寫道
參見第7條。
12306在系統、業務設計上，還存在哪些挑戰？

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

一、實時高并發在線事務處理；
二、如何和各個鐵路分局票務系統對接，保證數據同步的實時性和一致性。

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

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


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

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

火車跟公交有幾分相似，都有固定站點，每個站點都可能有人上下。不同的是，公交車可以先上車后買票，火車只能先買票后上車。我想這才是問題的根本。公交上去了就上去了，上不去可以等下一趟。火車得先有票才能上車，可是賣票規則卻成了難解之題。
您認為高性能并發系統架構應該如何設計？關鍵是什么？

范凱??? 寫道
高性能并發系統其實分很多種類，是并發讀，并發寫，并發長連接，還是并發事務？不同類型的架構設計是不同的。具體到12306就是并發事務，在這個領域，我個人沒有什么經驗。


陳雄華??? 寫道
1)? 優化前端網頁

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

2)? 群集分發和調度

據說12306是采用集中式構架的，集中式構架很難應對高并發，也很難水平擴容，分布式不是僅僅將調度服務器，應用服務器，緩存服務器，數據庫服務器分開就行，應該進行更細的服務級劃分，對業務進行服務細分，做成一個個松散耦合的服務，然后把這些服務獨立分布式部署。

3)? 采用分布式會話

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

4)? 關于數據庫設計優化

數據庫往往是系統瓶頸所在，首先應該對數據庫進行分庫設計，可采用兩級水平切割，如首先切割成幾個物理庫，然后在物理庫內部再采用表分割，一般是通過某個業務ID進行取模切割，降低單庫及單表的并發性，提高TPS。

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

此外，業務服務化、服務解耦化是關鍵。


runfriends（來自論壇回復） 寫道
個人認為針對不同的系統要有不同的設計方案。

雖然12306可以歸類為電商領域，但是跟通常意義上的B2C還是有巨大的差異。所以單純從12306上面討論高性能并發系統架構并沒有通用意義。

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

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

12306的業務需求乍一看似乎都是同一類型的資源，但是我們可能根據車次、臥、軟、硬、站、時段、線路等信息將車票這個12306要處理的惟一類型的資源分成若干子類，不同的子類請求由不同的集群處理。
有人提議12306采用NoSQL存儲，您認為是否可行？

范凱??? 寫道
NoSQL的優勢在于海量無模式數據存儲和查詢，12306的挑戰在于并發事務處理，所以用NoSQL無助于解決12306面臨的問題。


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

當然這涉及到很多業務流程的優化設計，降低數據一致性要求后才能合理使用NoSQL。


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

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

不論什么數據庫，都難以完成這么少的數據量卻要完成這么大并發量的情況。

個人認為還是把不同票種分散在不同票池服務器中，完全由程序操作內存完成查詢和購買更合適一些，雖然數據結構可能要復雜很多。

最后根據每個票種的余票量要限制每個票種的查詢和購買并發量。超過的就拒絕訪問，以節省資源。早死早超生，而不是所有人都耗在買票這個事上。
12306 如果使用開源來實現，您有什么建議？

范凱??? 寫道
其實用WebLogic應用服務器，Oracle數據庫，SSH框架和C3P0連接池都是OK的，但要解決12306面臨的并發事務問題，需要系統在基礎設施和架構上做很多專門的調整和開發的工作，? 這些才是解決問題的關鍵，和用什么軟件和框架關系不大。


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

另外，這種高并發的互聯網的應用不建議使用Hibernate，建議直接使用Spring JDBC，畢竟Hibernater操作數據庫往往不夠細粒度。另外還建議使用Spring MVC替代Struts，Spring MVC比Struts更高效性，頁面盡量使用客戶端的技術而不要使用服務端的技術實現，如使用客戶端的requirejs+underscore客戶端模塊就比使用服務端的JSP或Freemarker要好，畢竟這樣就讓客戶機來負責頁面渲染了，且可以有效地使用CDN。
從目前來看，您認為12306需要著重改善哪些方面？如果讓您來設計，您會如何做？

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


陳雄華??? 寫道
web前端要大筆優化，采用requirejs+jquery+backbone+underscore框架，web應用要進行部署優化js合并，js壓縮；
所有業務SOA化，以便可以將業務分布式部署；
數據庫分庫，二級切分,實現讀寫分離，從業務流程調整上降低對數據一致性的要求；
充分使用nosql技術，通過流程優化和調整，使nosql承擔大量的數據訪問請求，使nosql成為保衛后端mysql的一道堅強的保障。


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

設計一個票池系統，按照車次、線路、區域劃分票池，按照車次、站、軟、硬、臥分類不同票種，將每個票種分配到票池集群的某臺服務器上。買票時肯定已經確定了票種，通過一致性哈希準確定位指定票種所在的服務器。票池系統完全采用內存儲存預售票票種、票量信息。

查詢、購買分開不同的集群，兩個集群之間實現余票量同步。保證每個操作迅速返回，不必保證查詢和購買實時同步，也不必保證查到的票在購買的時候一定能買到。
莊表偉：與12306相關的一些思考

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

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

一、不要外包

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

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

二、循序漸進

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

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

三、排隊系統

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

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

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

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

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

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

四、代售機制

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

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

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

五、架構演進

在網絡上，我們常常能夠看到很多給12306支招的方案，總之各種前衛，各種先進。但是，在我看來，越是復雜的系統，越是怕這種“革命”，哪怕過去的架構再不合理，也最好不要貿然引入過于激進的架構，在原有的架構下逐步演進，逐步擴展，逐步尋找小范圍的、能夠被改進的點來推進，才是較為合理的做法。

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

六、抓大放小

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

其實，從技術人員的角度而言，怕的就是大老板親自抓用戶體驗。當然，比這個更加糟糕的，則是每個領導，都對用戶體驗，說三道四。

對于12306的改進，我想不必過于關注細節，追蹤一些統計數據的變化情況就好。比如：平均購票等待時間；退票率與廢票率；列車上座率等等。至于如何提高這些數據，領導們千萬不要事無巨細的參與討論，大家各自努力就好。有更多的事情得靠領導們努力：比如切實提高運力...
其他

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

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

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

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

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

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

另外，通過云計算將根據一年中不同時段的壓力彈性改變計算資源，也可以節省成本。


wangshu3000（來自論壇回復） 寫道
問題瓶頸（Front to Backgroud）：

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

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

?

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。