如果由你來設計 12306.cn，你會怎麼設計？

int LockSeat(int nStart, int nEnd)
{
if (nSeatSell[nStart][nEnd] &>= 2000)
{
return -1;
}

//依次遍歷所有座位
for (int i=nSeatSell[nStart][nEnd]; i&<2000; i++) { bool bHaveSeat = true; //如果座位經過此旅程的站點沒有被佔用 for (int j=nStart; j&

現在效率如何？直接看結果吧

售罄一個2000座位30站的車次車票，只需要62毫秒，每秒可以處理的請求達到7000萬，這個速度，怎麼也該夠了吧？

當然，這裡還沒有考慮退票，多人同行座位盡量連號，不過這些也不過在細節上的一些處理，即使對效率有些影響，但應該也完全夠不成瓶頸。

一個出票線程 一個退票線程 一個查詢余票線程

我認為系統設計切勿照搬已有的模式，尤其是這種專業性比較強的系統。

目前遇到的困難來不一定完全來自於系統架構的軟體設計方面，需要完善的部分還有很多。

4、通過各種渠道宣傳鐵路詳細的放票時間以及購票手續。

總的來說，善於引導用戶的系統才是一個完善的系統，鐵路部門應該在這方面加強。

技術上面：訂票系統大量js非同步交互框架，導致伺服器請求數量暴漲，應該優化系統處理流程，將一些不變得東西固化存儲，完善系統環節異常信息的處理工作。提高系統安全性和網路用戶體驗是矛盾的，要處理好這方面的關係。

2、將查詢的站點（多個）、登錄的站點（一個）、註冊的站點（一個）、訂單接收處理的站點（多個）、付費處理（一個）、後台監控站點（一個）、後台處理站點（一個）分散式部署，使用單點登錄系統統一控制，然後用演算法將處理平均分布到各個站點。（一個或多個代表部署的數量，如果發現有不足的地方，可以在運行時再加，前期架構主要確保能夠動態伸縮）

自己畫的

舉例說明,用PHP+MySQL實現12306購票和退票以及余票查詢邏輯.

普通商品的庫存之間沒有關聯性,庫存量都是確定的.

所以資料庫中不應存儲某個車次某個路段的余票數量,而應存儲該車次該路段已售的車票數量.

(1024, [3,4], 0)

如果三者的票合計小於500(這裡假設列車滿載為500人),

補充(糾錯):

經評論里的網友提醒,糾錯如下:

應該找出跟目標路段[2,3,4]有交集(相交元素&>=2)的路段,比如還包括[1,2,3]和[3,4,5]之類的.

演算法如下:

&= 2) {
$related[] = $v;
}
}
var_export($related);
// 得到
[1,2,3] 之前沒有考慮類似這樣的情況
[1,2,3,4]
[2,3]
[2,3,4]
[3,4]


其實很簡單，

還記得當年全國好n萬人秒殺淘寶紅包么？ 3000個紅包1秒鐘內就搶光， 這壓力相對於分散成很多車次，很多席別的火車票而言， 可難度大多了。

最坑爹的是，最近面試阿里巴巴，考官開始問這個問題了！

其實這是一個不完整的問題，完整的問題是：如何在保證現有售票系統（售票窗口）的情況下，不改動後台的設備，實現網路訂票功能？

【轉載】12306鐵道部訂票網站性能分析

http://hi.baidu.com/1988wangxiao/item/204d7bce98f20dcb984aa0b5

寫的不錯，推薦給大家。

http://12306.cn 網站掛了，被全國人民罵了，以這個事來粗略地討論一下網站性能的問題。這是一篇長文，只討論性能問題，不討論那些UI，用戶體驗，或是是否把支付和購票下單環節分開的功能性的東西。

業務

任何技術都離不開業務需求，所以，要說明性能問題，首先還是想先說說業務問題。

一，有人可能把這個東西和QQ或是網遊相比。

但我覺得這兩者是不一樣的，網遊和QQ在線或是登錄時訪問的更多的是用戶自己的數據，而訂票系統訪問的是中心的票量數據，這是不一樣的。不要覺得網遊或是QQ能行你就以為這是一樣的。網遊和QQ 的後端負載相對於電子商務的系統還是簡單。

二，有人說春節期間訂火車的這個事好像網站的秒殺活動。

的確很相似，但是如果你的思考不在表面的話，你會發現這也有些不一樣。火車票這個事，還有很多查詢操作，查時間，查座位，查鋪位，一個車次不 行，又查另一個車次，其伴隨著大量的查詢操作，下單的時候需要對資料庫操作。而秒殺，直接殺就好了。另外，關於秒殺，完全可以做成只接受前N個用戶的請求（完全不操作後端的任何數據， 僅僅只是對用戶的下單操作log），這種業務，只要把各個伺服器的時間精確同步了就可以了，無需在當時操作任何資料庫。可以訂單數夠後，停止秒殺，然後批量寫資料庫。火車票這個豈止是秒殺那麼簡單。能不能買到票得當時告訴用戶啊。

三，有人拿這個系統和奧運會的票務系統比較。

我覺得還是不一樣。雖然奧運會的票務系統當年也一上線就廢了。但是奧運會用的是抽獎的方式，也就是說不存在先來先得的搶的方式，而且，是事後抽獎，事前只需要收信息，事前不需要保證數據一致性，沒有鎖，很容易水平擴展。

四，訂票系統應該和電子商務的訂單系統很相似。

都是需要對庫存進行：1）佔住庫存，2）支付（可選），3）扣除庫存的操作。這個是需要有一致性的檢查的，也就是在並發時需要對數據加鎖的。B2C的電商基本上都會把這個事干成非同步的，也就是說，你下的訂單並不是馬上處理的，而是延時處理的，只有成功處理了，系統才會給你一封確認郵件說是訂單成功。我相信有很多朋友都收到認單不成功的郵件。這就是說，數據一致性在並發下是一個瓶頸。

五，鐵路的票務業務很變態。

其採用的是突然放票，而有的票又遠遠不夠大家分，所以，大家才會有搶票這種有中國特色的業務的做法。於是當票放出來的時候，就會有幾百萬人甚至上千萬人殺上去，查詢，下單。幾十分鐘內，一個網站能接受幾千萬的訪問量，這個是很恐怖的事情。據說12306的高峰訪問是10億PV，集中在早8點到10點，每秒PV在高峰時上千萬。

多說幾句：

一、庫存是B2C的惡夢，庫存管理相當的複雜。

不信，你可以問問所有傳統和電務零售業的企業，看看他們管理庫存是多麼難的一件事。不然，就不會有那麼多人在問凡客的庫存問題了。（你還可以看看《喬布斯傳》，你就知道為什麼Tim會接任Apple的CEO了，因為他搞定了蘋果的庫存問題）

二、對於一個網站來說，瀏覽網頁的高負載很容易搞定，查詢的負載有一定的難度去處理，不過還是可以通過緩存查詢結果來搞定，最難的就是下單的負載。

因為要訪問庫存啊，對於下單，基本上是用非同步來搞定的。去年雙11節，淘寶的每小時的訂單數大約在60萬左右，京東一天也才能支持40萬（居然比12306還差），亞馬遜5年前一小時可支持70萬訂單量。可見，下訂單的操作並沒有我們相像的那麼性能高。

三、淘寶要比B2C的網站要簡單得多，因為沒有倉庫。

所以，不存在像B2C這樣有N個倉庫對同一商品庫存更新和查詢的操作。下單的時候，B2C的 網站要去找一個倉庫，又要離用戶近，又要有庫存，這需要很多計算。試想，你在北京買了一本書，北京的倉庫沒貨了，就要從周邊的倉庫調，那就要去看看瀋陽或 是西安的倉庫有沒有貨，如果沒有，又得看看江蘇的倉庫，等等。淘寶的就沒有那麼多事了，每個商戶有自己的庫存，庫存分到商戶頭上了，反而有利於性能。

四、數據一致性才是真正的性能瓶頸。

有人說nginx可以搞定每秒10萬的靜態請求，我不懷疑。但這只是靜態請求，理論值，只要帶寬、I/O夠強，伺服器計算能力夠，並支持的並發連接數頂得住10萬TCP鏈接的建立 的話，那沒有問題。但在數據一致性面前，這10萬就完完全全成了一個可望不可及的理論值了。

我說那麼多，我只是想從業務上告訴大家，我們需要從業務上真正了解春運鐵路訂票這樣業務的變態之處。

前端性能優化技術

要解決性能的問題，有很多種常用的方法，我在下面列舉一下，我相信12306這個網站使用下面的這些技術會讓其性能有質的飛躍。

一、前端負載均衡

通過DNS的負載均衡器（一般在路由器上根據路由的負載重定向）可以把用戶的訪問均勻地分散在多個Web伺服器上。這樣可以減少Web伺服器的請求負載。因為http的請求都是短作業，所以，可以通過很簡單的負載均衡器來完成這一功能。最好是有CDN網路讓用戶連接與其最近的伺服器（CDN通常伴隨著分散式存儲）。（關於負載均衡更為詳細的說明見「後端的負載均衡」）

二、減少前端鏈接數

我看了一下http://12306.cn，打開主頁需要建60多個HTTP連接，車票預訂頁面則有70多個HTTP請求，現在的瀏覽器都是並發請求的。所以，只要有100萬個用戶，就會有6000萬個鏈接，太多了。一個登錄查詢頁面就好了。把js打成一個文件，把css也打成一個文件，把圖標也打成一個文件，用css分塊展示。把鏈接數減到最低。

三、減少網頁大小增加帶寬

這個世界不是哪個公司都敢做圖片服務的，因為圖片太耗帶寬了。現在寬頻時代很難有人能體會到當撥號時代做個圖頁都不敢用圖片的情形（現在在手機端瀏覽也是這個情形）。我查看了一下12306首頁的需要下載的總文件大小大約在900KB左右，如果你訪問過了，瀏覽器會幫你緩存很多，只需下載10K左右的文件。但是我們可以想像一個極端一點的案例，1百萬用戶同時訪問，且都是第一次訪問，每人下載量需要1M，如果需要在120秒內返回，那麼就需要，1M * 1M /120 * 8 = 66Gbps的帶寬。很驚人吧。所以，我估計在當天，12306的阻塞基本上應該是網路帶寬，所以，你可能看到的是沒有響應。後面隨著瀏覽器的緩存幫助12306減少很多帶寬佔用，於是負載一下就到了後端，後端的數據處理瓶頸一下就出來。於是你會看到很多http 500之類的錯誤。這說明伺服器垮了。

四、前端頁面靜態化

靜態化一些不常變的頁面和數據，並gzip一下。還有一個並態的方法是把這些靜態頁面放在/dev/shm下，這個目錄就是內存，直接從內存中把文件讀出來返回，這樣可以減少昂貴的磁碟I/O。

五、優化查詢

很多人查詢都是在查一樣的，完全可以用反向代理合併這些並發的相同的查詢。這樣的技術主要用查詢結果緩存來實現，第一次查詢走資料庫獲得數據，並把數據放到緩存，後面的查詢統統直接訪問高速緩存。為每個查詢做Hash，使用NoSQL的技術可以完成這個優化（這個技術也可以用做靜態頁面）對於火車票量的查詢，個人覺得不要顯示數字，就顯示一個「有」或「無」就好了，這樣可以大大簡化系統複雜度，並提升性能。

六、緩存的問題

緩存可以用來緩存動態頁面，也可以用來緩存查詢的數據。緩存通常有那麼幾個問題：

1）緩存的更新。也叫緩存和資料庫的同步。有這麼幾種方法，一是緩存time out，讓緩存失效，重查，二是，由後端通知更新，一量後端發生變化，通知前端更新。前者實現起來比較簡單，但實時性不高，後者實現起來比較複雜 ，但實時性高。

2）緩存的換頁。內存可能不夠，所以，需要把一些不活躍的數據換出內存，這個和操作系統的內存換頁和交換內存很相似。FIFO、LRU、LFU都是比較經典的換頁演算法。相關內容參看Wikipeida的緩存演算法。

3）緩存的重建和持久化。緩存在內存，系統總要維護，所以，緩存就會丟失，如果緩存沒了，就需要重建，如果數據量很大，緩存重建的過程會很慢，這會影響生產環境，所以，緩存的持久化也是需要考慮的。諸多強大的NoSQL都很好支持了上述三大緩存的問題。

後端性能優化技術

前面討論了前端性能的優化技術，於是前端可能就不是瓶頸問題了。那麼性能問題就會到後端數據上來了。下面說幾個後端常見的性能優化技術。

一、數據冗餘

關於數據冗餘，也就是說，把我們的資料庫的數據冗餘處理，也就是減少表連接這樣的開銷比較大的操作，但這樣會犧牲數據的一致性。風險比較大。很多人把NoSQL用做數據，快是快了，因為數據冗餘了，但這對數據一致性有大的風險。這需要根據不同的業務進行分析和處理。（注意：用關係型資料庫很容易移植到NoSQL上，但是反過來從NoSQL到關係型就難了）

二、數據鏡像

幾乎所有主流的資料庫都支持鏡像，也就是replication。資料庫的鏡像帶來的好處就是可以做負載均衡。把一台資料庫的負載均分到多台上，同時又保證了數據一致性（Oracle的SCN）。最重要的是，這樣還可以有高可用性，一台廢了，還有另一台在服務。數據鏡像的數據一致性可能是個複雜的問題，所以我們要在單條數據上進行數據分區，也就是說，把一個暢銷商品的庫存均分到不同的伺服器上，如，一個暢銷商品有1萬的庫存，我們可以設置10台伺服器，每台伺服器上有1000個庫存，這就好像B2C的倉庫一樣。

三、數據分區

數據鏡像不能解決的一個問題就是數據表裡的記錄太多，導致資料庫操作太慢。所以，把數據分區。數據分區有很多種做法，一般來說有下面這幾種：

1）把數據把某種邏輯來分類。比如火車票的訂票系統可以按各鐵路局來分，可按各種車型分，可以按始發站分，可以按目的地分……，反正就是把一張表拆成多張有一樣的欄位但是不同種類的表，這樣，這些表就可以存在不同的機器上以達到分擔負載的目的。

2）把數據按欄位分，也就是豎著分表。比如把一些不經常改的數據放在一個表裡，經常改的數據放在另外多個表裡。把一張表變成1對1的關係，這樣，你可以減少表的欄位個數，同樣可以提升一定的性能。另外，欄位多會造成一條記錄的存儲會被放到不同的頁表裡，這對於讀寫性能都有問題。但這樣一來會有很多複雜的控制。

3）平均分表。因為第一種方法是並不一定平均分均，可能某個種類的數據還是很多。所以，也有採用平均分配的方式，通過主鍵ID的範圍來分表。

4）同一數據分區。這個在上面數據鏡像提過。也就是把同一商品的庫存值分到不同的伺服器上，比如有10000個庫存，可以分到10台伺服器上，一台上有1000個庫存。然後負載均衡。

這三種分區都有好有壞。最常用的還是第一種。數據一旦分區，你就需要有一個或是多個調度來讓你的前端程序知道去哪裡找數據。把火車票的數據分區，並放在各個省市，會對12306這個系統有非常有意義的質的性能的提高。

四、後端系統負載均衡

前面說了數據分區，數據分區可以在一定程度上減輕負載，但是無法減輕熱銷商品的負載，對於火車票來說，可以認為是大城市的某些主幹線上的車票。這就需要使用數據鏡像來減輕負載。使用數據鏡像，你必然要使用負載均衡，在後端，我們可能很難使用像路由器上的負載均衡器，因為那是均衡流量的，因為流量並不代表伺服器的繁忙程度。因此，我們需要一個任務分配系統，其還能監控各個伺服器的負載情況。

任務分配伺服器有一些難點：

負載情況比較複雜。什麼叫忙？是CPU高？還是磁碟I/O高？還是內存使用高？還是並發高？還是內存換頁率高？你可能需要全部都要考慮。這些信息要發送給那個任務分配器上，由任務分配器挑選一台負載最輕的伺服器來處理。

任務分配伺服器上需要對任務隊列，不能丟任務啊，所以還需要持久化。並且可以以批量的方式把任務分配給計算伺服器。

任務分配伺服器死了怎麼辦？這裡需要一些如Live-Standby或是failover等高可用性的技術。我們還需要注意那些持久化了的任務的隊列如何轉移到別的伺服器上的問題。

我看到有很多系統都用靜態的方式來分配，有的用hash，有的就簡單地輪流分析。這些都不夠好，一個是不能完美地負載均衡，另一個靜態的方法的致命缺陷是，如果有一台計算伺服器死機了，或是我們需要加入新的伺服器，對於我們的分配器來說，都需要知道的。

還有一種方法是使用搶佔式的方式進行負載均衡，由下游的計算伺服器去任務伺服器上拿任務。讓這些計算伺服器自己決定自己是否要任務。這樣的好處是可以簡化系統的複雜度，而且還可以任意實時地減少或增加計算伺服器。但是唯一不好的就是，如果有一些任務只能在某種伺服器上處理，這可能會引入一些複雜度。不過總體來說，這種方法可能是比較好的負載均衡。

五、非同步、 throttle 和 批量處理

非同步、throttle（節流閥） 和批量處理都需要對並發請求數做隊列處理的。

非同步在業務上一般來說就是收集請求，然後延時處理。在技術上就是可以把各個處理程序做成並行的，也就可以水平擴展了。但是非同步的技術問題大概有這些，a）被調用方的結果返回，會涉及進程線程間通信的問題。b）如果程序需要回滾，回滾會有點複雜。c）非同步通常都會伴隨多線程多進程，並發的控制也相對麻煩一些。d）很多非同步系統都用消息機制，消息的丟失和亂序也會是比較複雜的問題。

throttle 技術其實並不提升性能，這個技術主要是防止系統被超過自己不能處理的流量給搞垮了，這其實是個保護機制。使用throttle技術一般來說是對於一些自己無法控制的系統，比如，和你網站對接的銀行系統。

批量處理的技術，是把一堆基本相同的請求批量處理。比如，大家同時購買同一個商品，沒有必要你買一個我就寫一次資料庫，完全可以收集到一定數量的請求，一次操作。這個技術可以用作很多方面。比如節省網路帶寬，我們都知道網路上的MTU（最大傳輸單元），以態網是1500位元組，光纖可以達到4000多個位元組，如果你的一個網路包沒有放滿這個MTU，那就是在浪費網路帶寬，因為網卡的驅動程序只有一塊一塊地讀效率才會高。因此，網路發包時，我們需要收集到足夠多的信息後再做網路I/O，這也是一種批量處理的方式。批量處理的敵人是流量低，所以，批量處理的系統一般都會設置上兩個閥值，一個是作業量，另一個是timeout，只要有一個條件滿足，就會開始提交處理。

所以，只要是非同步，一般都會有throttle機制，一般都會有隊列來排隊，有隊列，就會有持久化，而系統一般都會使用批量的方式來處理。雲風同學設計的「排隊系統」 就是這個技術。這和電子商務的訂單系統很相似，就是說，我的系統收到了你的購票下單請求，但是我還沒有真正處理，我的系統會跟據我自己的處理能力來throttle住這些大量的請求，並一點一點地處理。一旦處理完成，我就可以發郵件或簡訊告訴用戶你來可以真正購票了。

在這裡，我想通過業務和用戶需求方面討論一下雲風同學的這個排隊系統，因為其從技術上看似解決了這個問題，但是從業務和用戶需求上來說可能還是有一些值得我們去深入思考的地方：

1）隊列的DoS攻擊。首先，我們思考一下，這個隊是個單純地排隊的嗎？這樣做還不夠好，因為這樣我們不能杜絕黃牛，而且單純的ticket_id很容易發生DoS攻擊，比如，我發起N個 ticket_id，進入購票流程後，我不買，我就耗你半個小時，很容易我就可以讓想買票的人幾天都買不到票。有人說，用戶應該要用身份證來排隊， 這樣在購買里就必需要用這個身份證來買，但這也還不能杜絕黃牛排隊或是號販子。因為他們可以註冊N個帳號來排隊，但就是不買。黃牛這些人這個時候只需要干一個事，把網站搞得正常人不能訪問，讓用戶只能通過他們來買。

2）對列的一致性？對這個隊列的操作是不是需要鎖？只要有鎖，性能一定上不去。試想，100萬個人同時要求你來分配位置號，這個隊列將會成為性能瓶頸。你一定沒有資料庫實現得性能好，所以，可能比現在還差

3）隊列的等待時間。購票時間半小時夠不夠？多不多？要是那時用戶正好不能上網呢？如果時間短了，用戶不夠時間操作也會抱怨，如果時間長了，後面在排隊的那些人也會抱怨。這個方法可能在實際操作上會有很多問題。另外，半個小時太長了，這完全不現實，我們用15分鐘來舉例：有1千萬用戶，每一個時刻只能放進去1萬個，這1萬個用戶需要15分鐘完成所有操作，那麼，這1千萬用戶全部處理完，需要1000*15m = 250小時，10天半，火車早開了。（我並非亂說，根據鐵道部專家的說明：這幾天，平均一天下單100萬，所以，處理1000萬的用戶需要十天。這個計算可能有點簡單了，我只是想說，在這樣低負載的系統下用排隊可能都不能解決問題）

4）隊列的分散式。這個排隊系統只有一個隊列好嗎？還不足夠好。因為，如果你放進去的可以購票的人如果在買同一個車次的同樣的類型的票（比如某動車卧鋪），還是等於在搶票，也就是說系統的負載還是會有可能集中到其中某台伺服器上。因此，最好的方法是根據用戶的需求——提供出發地和目的地，來對用戶進行排隊。而這樣一來，隊列也就可以是多個，只要是多個隊列，就可以水平擴展了。

我覺得完全可以向網上購物學習。在排隊（下單）的時候，收集好用戶的信息和想要買的票，並允許用戶設置購票的優先順序，比如，A車次卧鋪買 不到就買 B車次的卧鋪，如果還買不到就買硬座等等，然後用戶把所需的錢先充值好，接下來就是系統完全自動地非同步處理訂單。成功不成功都發簡訊或郵件通知用戶。這樣，系統不僅可以省去那半個小時的用戶交互時間，自動化加快處理，還可以合併相同購票請求的人，進行批處理（減少資料庫的操作次數）。這種方法最妙的事是可以知道這些排隊用戶的需求，不但可以優化用戶的隊列，把用戶分布到不同的隊列，還可以像亞馬遜的心愿單一樣，讓鐵道部做車次統籌安排和調整（最後，排隊系統（下單系統）還是要保存在資料庫里的或做持久化，不能只放在內存中，不然機器一down，就等著被罵吧）。

小結

寫了那麼多，我小結一下：

0）無論你怎麼設計，你的系統一定要能容易地水平擴展。也就是說，你的整個數據流中，所有的環節都要能夠水平擴展。這樣，當你的系統有性能問題時，「加3倍的伺服器」才不會被人譏笑。

1）上述的技術不是一朝一夕能搞定的，沒有長期的積累，基本無望。我們可以看到，無論你用哪種都會引發一些複雜性。

2）集中式的賣票很難搞定，使用上述的技術可以讓訂票系統能有幾佰倍的性能提升。而在各個省市建分站，分開賣票，是能讓現有系統性能有質的提升的最好方法。

3）春運前夕搶票且票量供遠小於求這種業務模式是相當變態的，讓幾千萬甚至上億的人在某個早晨的8點鐘同時登錄同時搶票的這種業務模式是變態中的變態。業務形態的變態決定了無論他們怎麼辦干一定會被罵。

4）為了那麼一兩個星期而搞那麼大的系統，而其它時間都在閑著，有些可惜了，這也就是鐵路才幹得出來這樣的事了。

（本文轉載時請註明作者和出處，請勿於記商業目的）

我說一下資料庫方面的想法。

在另一個問題里回答了，再貼一次：

個人認為更有價值是體現在數據分析上，如得到寬頻數據、用戶流量、區域分布、請求特點、應用瓶頸點、伺服器的性能指標等等，這些數據對優化、改良現有架構非常有幫助。拋開寬頻因素，以下是對12306平台系統架構的幾點建議：

火車票難買的根本在於車少人多，不管你再怎麼優化12306網站的性能，一到放票的時間點，那麼多人集中下單，肯定要卡。

核心觀點：

這段時間看了些寫鐵路售票網的設計思路，有些人（架構師）提出的方案我卻很不敢苟同，太慣性了，總想著從技術去解決壓力問題，就像之前我比喻的的總想張大嘴咬硬骨頭。春運這種特殊場景搶票不可避免，開票後把用戶理解成DDOS攻擊者一點都不過分，要保證系統性能必須通過業務手段來規避！

在春運這種特殊時期，我更傾向於採取分時分線路的策略進行售賣，或是網上提的排隊隊列，都可以有效緩解瞬間峰值。

1. 春運期間，同時在線、查詢、訂票的人數峰值高。
2. 多種網點銷售，電話、網點、互聯網，都反映到同一個票源上，不能出現重複賣，付了錢卻沒票這樣的事。
3. 因為票源太緊張，只要一放票，大家想盡辦法最快速度上來搶票，用什麼手段的都有，造成DDOS。

方案：

1. 靜態內容，CDN需要足夠給力。
2. 動態內容，查詢、下單、支付、取票這幾個環節需要足夠給力，特別是後面三個環節涉及到嚴格的事務。

查票：