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

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

您是否在春節/國慶期間在12306上買過票？談談該系統的使用者體驗！

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

我只用過一次，體驗不深。感覺系統不太穩定，我訪問的時候看到過Java出錯丟擲的錯誤堆疊資訊。

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

我知道它很難用，所以我從來沒用它買過票。去年國慶節查詢個票，慢的要命。 

從sql的拼寫到頁面優化，從程式架構到伺服器架構都需要全面重構。居然不是引數化查詢sql，而是查詢引數拼到sql裡的，完全是一群業餘選手的習作。  

應該採用js、css、圖片、html都應該啟用gzip壓縮，所有css應減少到一個，js檔案該合併的合併，能重用的重用，頁面背景圖應儘量合併成一個檔案。儘量減少http請求數。

在去年國慶之前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等，這樣就可以減小狀態的更新頻率，充分使用快取資料。

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讀寫分離技術等。 

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

個人認為針對不同的系統要有不同的設計方案。 

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

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

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

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

有人提議12306採用NoSQL儲存，您認為是否可行？

範凱    寫道 NoSQL的優勢在於海量無模式資料儲存和查詢，12306的挑戰在於併發事務處理，所以用NoSQL無助於解決12306面臨的問題。

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

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

事務的粒度應做到購買行為是原子性的，即保證兩個人不會買到相同的票即可。每個票種的優先順序是一樣的，應不同的查詢條件保證能儘快的返回。 

實際上每天出售的票種總和遠達不到海量的程度。但是每年有幾個時段併發量特別大。如果使用大量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的一道堅強的保障。

鐵道部應該對每節車廂、每個車次要賣出多少站票、軟座、硬座、臥鋪有一個規劃。購買同一車次和票種的人不會造成太高的併發。因此關鍵在於查詢和買票伺服器叢集的設計和實現。 

設計一個票池系統，按照車次、線路、區域劃分票池，按照車次、站、軟、硬、臥分類不同票種，將每個票種分配到票池叢集的某臺伺服器上。買票時肯定已經確定了票種，通過一致性雜湊準確定位指定票種所在的伺服器。票池系統完全採用記憶體儲存預售票票種、票量資訊。 

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

莊表偉：與12306相關的一些思考

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

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

一、不要外包 

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

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

二、循序漸進 

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

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

三、排隊系統 

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

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

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

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

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

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

四、代售機制 

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

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

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

五、架構演進 

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

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

六、抓大放小 

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

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

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

其他

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

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

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

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

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

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

另外，通過雲端計算將根據一年中不同時段的壓力彈性改變計算資源，也可以節省成本。 問題瓶頸（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和記憶體來提高。
• 網路，根據地點，業務分佈到不同的節點進行購票，每個節點的網路吞吐可以控制，不會太高