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通常伴隨 著分佈式存儲)。(關於負載均衡更為詳細的說明見後端的負載均衡)

　　二、減少前端鏈接數

　　我看瞭一下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臺服務器，每臺服務器上有100個庫存，這就好像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)為瞭那麼一兩個星期而搞那麼大的系統，而其它時間都在閑著，有些可惜瞭，這也就是鐵路才幹得出來這樣的事瞭。

　　文章來源：酷殼