由12306.cn談?wù)劸W(wǎng)站性能技術(shù)

　　12306.cn網(wǎng)站掛了，被全國人民罵了。我這兩天也在思考這個事，我想以這個事來粗略地和大家討論一下網(wǎng)站性能的問題。因為倉促，而且完全基于本人有限的經(jīng)驗和了解，所以，如果有什么問題還請大家一起討論和指正。(這又是一篇長文，只討論性能問題，不討論那些UI，用戶體驗，或是是否把支付和購票下單環(huán)節(jié)分開的功能性的東西)

　　業(yè)務(wù)

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

　　其一，有人可能把這個東西和QQ或是網(wǎng)游相比。但我覺得這兩者是不一樣的，網(wǎng)游和QQ在線或是登錄時訪問的更多的是用戶自己的數(shù)據(jù)，而訂票系統(tǒng)訪問的是中心的票量數(shù)據(jù)，這是不一樣的。不要覺得網(wǎng)游或是QQ能行你就以為這是一樣的。網(wǎng)游和QQ 的后端負載相對于電子商務(wù)的系統(tǒng)還是簡單。

　　其二，有人說春節(jié)期間訂火車的這個事好像網(wǎng)站的秒殺活動。的確很相似，但是如果你的思考不在表面的話，你會發(fā)現(xiàn)這也有些不一樣。火車票這個事，還有很多查詢操作，查時間，查座位，查鋪位，一個車次不 行，又查另一個車次，其伴隨著大量的查詢操作，下單的時候需要對數(shù)據(jù)庫操作。而秒殺，直接殺就好了。另外，關(guān)于秒殺，完全可以做成只接受前N個用戶的請求(完全不操作后端的任何數(shù)據(jù)， 僅僅只是對用戶的下單操作log)，這種業(yè)務(wù)，只要把各個服務(wù)器的時間精確同步了就可以了，無需在當時操作任何數(shù)據(jù)庫。可以訂單數(shù)夠后，停止秒殺，然后批量寫數(shù)據(jù)庫。火車票這個豈止是秒殺那么簡單。能不能買到票得當時告訴用戶啊。

　　其三，有人拿這個系統(tǒng)和奧運會的票務(wù)系統(tǒng)比較。我覺得還是不一樣。雖然奧運會的票務(wù)系統(tǒng)當年也一上線就廢了。但是奧運會用的是抽獎的方式，也就是說不存在先來先得的搶的方式，而且，是事后抽獎，事前只需要收信息，事前不需要保證數(shù)據(jù)一致性，沒有鎖，很容易水平擴展。

　　其四，訂票系統(tǒng)應(yīng)該和電子商務(wù)的訂單系統(tǒng)很相似，都是需要對庫存進行：1)占住庫存，2)支付(可選)，3)扣除庫存的操作。這個是需要有一致性的檢查的，也就是在并發(fā)時需要對數(shù)據(jù)加鎖的。B2C的電商基本上都會把這個事干成異步的，也就是說，你下的訂單并不是馬上處理的，而是延時處理的，只有成功處理了，系統(tǒng)才會給你一封確認郵件說是訂單成功。我相信有很多朋友都收到認單不成功的郵件。這就是說，數(shù)據(jù)一致性在并發(fā)下是一個瓶頸。

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

　　多說幾句：

　　庫存是B2C的惡夢，庫存管理相當?shù)膹?fù)雜。不信，你可以問問所有傳統(tǒng)和電務(wù)零售業(yè)的企業(yè)，看看他們管理庫存是多么難的一件事。不然，就不會有那么多人在問凡客的庫存問題了。(你還可以看看《喬布斯傳》，你就知道為什么Tim會接任Apple的CEO了，因為他搞定了蘋果的庫存問題)

　　對于一個網(wǎng)站來說，瀏覽網(wǎng)頁的高負載很容易搞定，查詢的負載有一定的難度去處理，不過還是可以通過緩存查詢結(jié)果來搞定，最難的就是下單的負載。因為要訪問庫存啊，對于下單，基本上是用異步來搞定的。去年雙11節(jié)，淘寶的每小時的訂單數(shù)大約在60萬左右，京東一天也才能支持40萬(居然比12306還差)，亞馬遜5年前一小時可支持70萬訂單量。可見，下訂單的操作并沒有我們相像的那么性能高。

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

　　數(shù)據(jù)一致性才是真正的性能瓶頸。有 人說nginx可以搞定每秒10萬的靜態(tài)請求，我不懷疑。但這只是靜態(tài)請求，理論值，只要帶寬、I/O夠強，服務(wù)器計算能力夠，并支持的并發(fā)連接數(shù)頂?shù)米?0萬TCP鏈接的建立 的話，那沒有問題。但在數(shù)據(jù)一致性面前，這10萬就完完全全成了一個可望不可及的理論值了。

　　我說那么多，我只是想從業(yè)務(wù)上告訴大家，我們需要從業(yè)務(wù)上真正了解春運鐵路訂票這樣業(yè)務(wù)的變態(tài)之處。

　　前端性能優(yōu)化技術(shù)

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

　　一、前端負載均衡

　　通過DNS的負載均衡器(一般在路由器上根據(jù)路由的負載重定向)可以把用戶的訪問均勻地分散在多個Web服務(wù)器上。這樣可以減少Web服務(wù)器的請求負載。因為http的請求都是短作業(yè)，所以，可以通過很簡單的負載均衡器來完成這一功能。最好是有CDN網(wǎng)絡(luò)讓用戶連接與其最近的服務(wù)器(CDN通常伴隨著分布式存儲)。(關(guān)于負載均衡更為詳細的說明見“后端的負載均衡”)

　　二、減少前端鏈接數(shù)

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

　　三、減少網(wǎng)頁大小增加帶寬

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

　　四、前端頁面靜態(tài)化

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

　　五、優(yōu)化查詢

　　很多人查詢都是在查一樣的，完全可以用反向代理合并這些并發(fā)的相同的查詢。這樣的技術(shù)主要用查詢結(jié)果緩存來實現(xiàn)，第一次查詢走數(shù)據(jù)庫獲得數(shù)據(jù)，并把數(shù)據(jù)放到緩存，后面的查詢統(tǒng)統(tǒng)直接訪問高速緩存。為每個查詢做Hash，使用NoSQL的技術(shù)可以完成這個優(yōu)化。(這個技術(shù)也可以用做靜態(tài)頁面)

　　對于火車票量的查詢，個人覺得不要顯示數(shù)字，就顯示一個“有”或“無”就好了，這樣可以大大簡化系統(tǒng)復(fù)雜度，并提升性能。

　　六、緩存的問題

　　緩存可以用來緩存動態(tài)頁面，也可以用來緩存查詢的數(shù)據(jù)。緩存通常有那么幾個問題：

　　1)緩存的更新。也叫緩存和數(shù)據(jù)庫的同步。有這么幾種方法，一是緩存time out，讓緩存失效，重查，二是，由后端通知更新，一量后端發(fā)生變化，通知前端更新。前者實現(xiàn)起來比較簡單，但實時性不高，后者實現(xiàn)起來比較復(fù)雜 ，但實時性高。

　　2)緩存的換頁。內(nèi)存可能不夠，所以，需要把一些不活躍的數(shù)據(jù)換出內(nèi)存，這個和操作系統(tǒng)的內(nèi)存換頁和交換內(nèi)存很相似。FIFO、LRU、LFU都是比較經(jīng)典的換頁算法。相關(guān)內(nèi)容參看Wikipeida的緩存算法。

　　3)緩存的重建和持久化。緩存在內(nèi)存，系統(tǒng)總要維護，所以，緩存就會丟失，如果緩存沒了，就需要重建，如果數(shù)據(jù)量很大，緩存重建的過程會很慢，這會影響生產(chǎn)環(huán)境，所以，緩存的持久化也是需要考慮的。

　　精彩內(nèi)容，請點擊下一頁！

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學習有所幫助,可以手機掃描二維碼進行捐贈