轉載：由12306.cn談談網站性能技術

作者 ：陳皓  出處：酷 殼 – CoolShell.cn

原文網址：http://coolshell.cn/articles/6470.html

        12306.cn網站挂了，被全國人民罵了。我這兩天也在思考這個事，我想以這個事來粗略地和大家讨論一下網站性能的問題。因為倉促，而且完全基于本人有限的經驗和了解，是以，如果有什麼問題還請大家一起讨論和指正。（這又是一篇長文，隻讨論性能問題，不讨論那些UI，使用者體驗，或是是否把支付和購票下單環節分開的功能性的東西）

業務

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

• 其一，有人可能把這個東西和QQ或是網遊相比。但我覺得這兩者是不一樣的，網遊和QQ線上或是登入時通路的更多的是使用者自己的資料，而訂票系統通路的是中心的票量資料，這是不一樣的。不要覺得網遊或是QQ能行你就以為這是一樣的。網遊和QQ 的後端負載相對于電子商務的系統還是簡單。

• 其二，有人說春節期間訂火車的這個事好像網站的秒殺活動。的确很相似，但是如果你的思考不在表面的話，你會發現這也有些不一樣。火車票這個事，還有很多查詢操作，查時間，查座位，查鋪位，一個車次不 行，又查另一個車次，其伴随着大量的查詢操作，下單的時候需要對資料庫操作。而秒殺，直接殺就好了。另外，關于秒殺，完全可以做成隻接受前N個使用者的請求（完全不操作後端的任何資料， 僅僅隻是對使用者的下單操作log），這種業務，隻需要在記憶體cache中放好可秒殺的數量，還可以把資料分布開來放，100商品，10台伺服器一台放10個，無需在當時操作任何資料庫。可以訂單數夠後，停止秒殺，然後批量寫資料庫。而且秒殺的商品不多。火車票這個不是像秒殺那麼簡單的，春運時間，幾乎所有的票都是熱門票，而且幾乎是全國人民都來了。（淘寶的雙十一也就3百萬使用者，而火車票瞬時有千萬級别甚至是億級别的）

• 其三，有人拿這個系統和奧運會的票務系統比較。我覺得還是不一樣。雖然奧運會的票務系統當年也一上線就廢了。但是奧運會用的是抽獎的方式，也就是說不存在先來先得的搶的方式，而且，是事後抽獎，事前隻需要收資訊，事前不需要保證資料一緻性，沒有鎖，很容易水準擴充。

• 其四，訂票系統應該和電子商務的訂單系統很相似，都是需要對庫存進行：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請求，現在的浏覽器都是并發請求的（當然，浏覽器的一個頁面的并發數是有限的，但是你擋不住使用者開多個頁面，而且，後端伺服器TCP連結在前端斷開始，還不會馬上釋放或重要）。是以，隻要有100萬個使用者，就有可能會有6000萬個連結（通路第一次後有了浏覽器端的cache，這個數會下來，就算隻有20%也是百萬級的連結數），太多了。一個登入查詢頁面就好了。把js打成一個檔案，把css也打成一個檔案，把圖示也打成一個檔案，用css分塊展示。把連結數減到最低。

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

這個世界不是哪個公司都敢做圖檔服務的，因為圖檔太耗帶寬了。現在寬帶時代很難有人能體會到當撥号時代做個圖頁都不敢用圖檔的情形（現在在手機端浏覽也是這個情形）。我檢視了一下12306首頁的需要下載下傳的總檔案大小大約在900KB左右，如果你通路過了，浏覽器會幫你緩存很多，隻需下載下傳10K左右的檔案。但是我們可以想像一個極端一點的案例，1百萬使用者同時通路，且都是第一次通路，每人下載下傳量需要1M，如果需要在120秒内傳回，那麼就需要，1M * 1M /120 * 8 = 66Gbps的帶寬。很驚人吧。是以，我估計在當天，12306的阻塞基本上應該是網絡帶寬，是以，你可能看到的是沒有響應。後面随着浏覽器的緩存幫助12306減少很多帶寬占用，于是負載一下就到了後端，後端的資料處理瓶頸一下就出來。于是你會看到很多http 500之類的錯誤。這說明後端伺服器垮了。

四、前端頁面靜态化

靜态化一些不常變的頁面和資料，并gzip一下。使用nginx的sendfile功能可以讓這些靜态檔案直接在核心心态交換，可以極大增加性能。

五、優化查詢

很多人查詢都是在查一樣的，完全可以用反向代理合并這些并發的相同的查詢。這樣的技術主要用查詢結果緩存來實作，第一次查詢走資料庫獲得資料，并把資料放到緩存，後面的查詢統統直接通路高速緩存。為每個查詢做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，有的就簡單地輪流分析。這些都不夠好，一個是不能完美地負載均衡，另一個靜态的方法的緻命缺陷是，如果有一台計算伺服器當機了，或是我們需要加入新的伺服器，對于我們的配置設定器來說，都需要知道的。另外，還要重算哈希（一緻性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）無論你怎麼設計，你的系統一定要能容易地水準擴充。也就是說，你的整個資料流中，所有的環節都要能夠水準擴充。這樣，當你的系統有性能問題時，“加30倍的伺服器”才不會被人譏笑。

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

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

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

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

更新2012年9月27日 

 Alexa 統計的12306的PV （注：Alexa的PV定義是：一個使用者在一天内對一個頁面的多次點選隻算一次）

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

（轉載本站文章請注明作者和出處 酷 殼 – CoolShell.cn ，請勿用于任何商業用途）