12306.cn網(wǎng)站掛掉，我想以這個(gè)事來(lái)粗略地和大家討論一下網(wǎng)站性能的問(wèn)題。因?yàn)閭}(cāng)促，而且完全基于 本人有限的經(jīng)驗(yàn)和了解，所以，如果有什么問(wèn)題還請(qǐng)大家一起討論和指正。（這又是一篇長(zhǎng)文，只討論性能問(wèn)題，不討論那些UI，用戶體驗(yàn)，或是是否把支付和購(gòu) 票下單環(huán)節(jié)分開(kāi)的功能性的東西）

業(yè)務(wù)

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

• 其一，有人可能把這個(gè)東西和QQ或是網(wǎng)游相比。但我覺(jué)得這兩者是不一樣的，網(wǎng)游和QQ在線或是登錄時(shí)訪問(wèn)的更多的是用戶自己的數(shù)據(jù)，而訂票系統(tǒng)訪問(wèn)的是中心的票量數(shù)據(jù)，這是不一樣的。不要覺(jué)得網(wǎng)游或是QQ能行你就以為這是一樣的。網(wǎng)游和QQ 的后端負(fù)載相對(duì)于電子商務(wù)的系統(tǒng)還是簡(jiǎn)單。
• 其二，有人說(shuō)春節(jié)期間訂火車的這個(gè)事好像網(wǎng)站的秒殺活動(dòng)。的確很相似，但 是如果你的思考不在表面的話，你會(huì)發(fā)現(xiàn)這也有些不一樣。火車票這個(gè)事，還有很多查詢操作，查時(shí)間，查座位，查鋪位，一個(gè)車次不 行，又查另一個(gè)車次，其伴隨著大量的查詢操作，下單的時(shí)候需要對(duì)數(shù)據(jù)庫(kù)操作。而秒殺，直接殺就好了。另外，關(guān)于秒殺，完全可以做成只接受前N個(gè)用戶的請(qǐng)求 （完全不操作后端的任何數(shù)據(jù)， 僅僅只是對(duì)用戶的下單操作log），這種業(yè)務(wù)，只需要在內(nèi)存cache中放好可秒殺的數(shù)量，還可以把數(shù)據(jù)分布開(kāi)來(lái)放，100商品，10臺(tái)服務(wù)器一臺(tái)放10 個(gè)，無(wú)需在當(dāng)時(shí)操作任何數(shù)據(jù)庫(kù)。可以訂單數(shù)夠后，停止秒殺，然后批量寫數(shù)據(jù)庫(kù)。而且秒殺的商品不多。火車票這個(gè)不是像秒殺那么簡(jiǎn)單的，春運(yùn)時(shí)間，幾乎所有 的票都是熱門票，而且?guī)缀跏侨珖?guó)人民都來(lái)了。（淘寶的雙十一也就3百萬(wàn)用戶，而火車票瞬時(shí)有千萬(wàn)級(jí)別甚至是億級(jí)別的）
• 其三，有人拿這個(gè)系統(tǒng)和奧運(yùn)會(huì)的票務(wù)系統(tǒng)比較。我覺(jué)得還是不一樣。雖然奧運(yùn)會(huì)的票務(wù)系統(tǒng)當(dāng)年也一上線就廢了。但是奧運(yùn)會(huì)用的是抽獎(jiǎng)的方式，也就是說(shuō)不存在先來(lái)先得的搶的方式，而且，是事后抽獎(jiǎng)，事前只需要收信息，事前不需要保證數(shù)據(jù)一致性，沒(méi)有鎖，很容易水平擴(kuò)展。
• 其四，訂票系統(tǒng)應(yīng)該和電子商務(wù)的訂單系統(tǒng)很相似，都是需要對(duì)庫(kù)存進(jìn) 行：1）占住庫(kù)存，2）支付（可選），3）扣除庫(kù)存的操作。這個(gè)是需要有一致性的檢查的，也就是在并發(fā)時(shí)需要對(duì)數(shù)據(jù)加鎖的。B2C的電商基本上都會(huì)把這個(gè) 事干成異步的，也就是說(shuō)，你下的訂單并不是馬上處理的，而是延時(shí)處理的，只有成功處理了，系統(tǒng)才會(huì)給你一封確認(rèn)郵件說(shuō)是訂單成功。我相信有很多朋友都收到 認(rèn)單不成功的郵件。這就是說(shuō)，數(shù)據(jù)一致性在并發(fā)下是一個(gè)瓶頸。
• 其五，鐵路的票務(wù)業(yè)務(wù)很變態(tài)，其采用的是突然放票，而有的票又遠(yuǎn)遠(yuǎn)不夠大家分，所以，大家才會(huì)有搶票這種有中國(guó)特色的業(yè)務(wù)的做法。于是當(dāng)票放出來(lái)的時(shí)候，就會(huì)有幾百萬(wàn)人甚至上千萬(wàn)人殺上去，查詢，下單。幾十分鐘內(nèi)，一個(gè)網(wǎng)站能接受幾千萬(wàn)的訪問(wèn)量，這個(gè)是很恐怖的事情。據(jù)說(shuō)12306的高峰訪問(wèn)是10億PV，集中在早8點(diǎn)到10點(diǎn)，每秒PV在高峰時(shí)上千萬(wàn)。

多說(shuō)幾句：

• 庫(kù)存是B2C的惡夢(mèng)，庫(kù)存管理相當(dāng)?shù)膹?fù)雜。不信，你可以問(wèn)問(wèn)所有傳統(tǒng)和電務(wù)零售業(yè)的企業(yè)，看看他們管理庫(kù)存是多么難的一件事。不然，就不會(huì)有那么多人在問(wèn)凡客的庫(kù)存問(wèn)題了。（你還可以看看《喬布斯傳》，你就知道為什么Tim會(huì)接任Apple的CEO了，最主要的原因是他搞定了蘋果的庫(kù)存周期問(wèn)題）
• 對(duì)于一個(gè)網(wǎng)站來(lái)說(shuō)，瀏覽網(wǎng)頁(yè)的高負(fù)載很容易搞定，查詢的負(fù)載有一定的難度去處理，不過(guò)還是可以通過(guò)緩存查詢結(jié)果來(lái)搞定，最難的就是下單的負(fù)載。因?yàn)橐L問(wèn)庫(kù)存啊，對(duì)于下單，基本上是用異步來(lái)搞定的。去年雙11節(jié)，淘寶的每小時(shí)的訂單數(shù)大約在60萬(wàn)左右，京東一天也才能支持40萬(wàn)（居然比12306還差），亞馬遜5年前一小時(shí)可支持70萬(wàn)訂單量。可見(jiàn)，下訂單的操作并沒(méi)有我們相像的那么性能高。
• 淘寶要比B2C的網(wǎng)站要簡(jiǎn)單得多，因?yàn)闆](méi)有倉(cāng)庫(kù)，所以，不存在像B2C這樣有N個(gè)倉(cāng)庫(kù)對(duì)同一商品庫(kù)存更新和查 詢的操作。下單的時(shí)候，B2C的 網(wǎng)站要去找一個(gè)倉(cāng)庫(kù)，又要離用戶近，又要有庫(kù)存，這需要很多計(jì)算。試想，你在北京買了一本書，北京的倉(cāng)庫(kù)沒(méi)貨了，就要從周邊的倉(cāng)庫(kù)調(diào)，那就要去看看沈陽(yáng)或 是西安的倉(cāng)庫(kù)有沒(méi)有貨，如果沒(méi)有，又得看看江蘇的倉(cāng)庫(kù)，等等。淘寶的就沒(méi)有那么多事了，每個(gè)商戶有自己的庫(kù)存，庫(kù)存就是一個(gè)數(shù)字，并且?guī)齑娣值缴虘纛^上 了，反而有利于性能擴(kuò)展。
• 數(shù)據(jù)一致性才是真正的性能瓶頸。有 人說(shuō)nginx可以搞定每秒10萬(wàn)的靜態(tài)請(qǐng)求，我不懷疑。但這只是靜態(tài)請(qǐng)求，理論值，只要帶寬、I/O夠強(qiáng)，服務(wù)器計(jì)算能力夠，并支持的并發(fā)連接數(shù)頂?shù)米?10萬(wàn)TCP鏈接的建立 的話，那沒(méi)有問(wèn)題。但在數(shù)據(jù)一致性面前，這10萬(wàn)就完完全全成了一個(gè)可望不可及的理論值了。

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

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

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

一、前端負(fù)載均衡

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

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

我看了一下12306.cn，打開(kāi)主頁(yè)需要建60多個(gè)HTTP連接，車票預(yù)訂頁(yè)面則有70多個(gè)HTTP請(qǐng)求，現(xiàn)在的瀏覽器都是并發(fā)請(qǐng)求的（當(dāng)然，瀏 覽器的一個(gè)頁(yè)面的并發(fā)數(shù)是有限的，但是你擋不住用戶開(kāi)多個(gè)頁(yè)面，而且，后端服務(wù)器TCP鏈接在前端斷開(kāi)始，還不會(huì)馬上釋放或重要）。所以，只要有100萬(wàn) 個(gè)用戶，就有可能會(huì)有6000萬(wàn)個(gè)鏈接（訪問(wèn)第一次后有了瀏覽器端的cache，這個(gè)數(shù)會(huì)下來(lái)，就算只有20%也是百萬(wàn)級(jí)的鏈接數(shù)），太多了。一個(gè)登錄查 詢頁(yè)面就好了。把js打成一個(gè)文件，把css也打成一個(gè)文件，把圖標(biāo)也打成一個(gè)文件，用css分塊展示。把鏈接數(shù)減到最低。

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

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

#p#

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

靜態(tài)化一些不常變的頁(yè)面和數(shù)據(jù)，并gzip一下。還有一個(gè)變態(tài)的方法是把這些靜態(tài)頁(yè)面放在/dev/shm下，這個(gè)目錄就是內(nèi)存，直接從內(nèi)存中把文件讀出來(lái)返回，這樣可以減少昂貴的磁盤I/O。使用nginx的sendfile功能可以讓這些靜態(tài)文件直接在內(nèi)核心態(tài)交換，可以極大增加性能。

五、優(yōu)化查詢

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

對(duì)于火車票量的查詢，個(gè)人覺(jué)得不要顯示數(shù)字，就顯示一個(gè)“有”或“無(wú)”就好了，這樣可以大大簡(jiǎn)化系統(tǒng)復(fù)雜度，并提升性能。把查詢對(duì)數(shù)據(jù)庫(kù)的負(fù)載分出去，從而讓數(shù)據(jù)庫(kù)可以更好地為下單的人服務(wù)。

六、緩存的問(wèn)題

緩存可以用來(lái)緩存動(dòng)態(tài)頁(yè)面，也可以用來(lái)緩存查詢的數(shù)據(jù)。緩存通常有那么幾個(gè)問(wèn)題：

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

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

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

諸多強(qiáng)大的NoSQL都很好支持了上述三大緩存的問(wèn)題。

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

前面討論了前端性能的優(yōu)化技術(shù)，于是前端可能就不是瓶頸問(wèn)題了。那么性能問(wèn)題就會(huì)到后端數(shù)據(jù)上來(lái)了。下面說(shuō)幾個(gè)后端常見(jiàn)的性能優(yōu)化技術(shù)。

一、數(shù)據(jù)冗余

關(guān)于數(shù)據(jù)冗余，也就是說(shuō)，把我們的數(shù)據(jù)庫(kù)的數(shù)據(jù)冗余處理，也就是減少表連接這樣的開(kāi)銷比較大的操作，但這樣會(huì)犧牲數(shù)據(jù)的一致性。風(fēng)險(xiǎn)比較大。很多人 把NoSQL用做數(shù)據(jù)，快是快了，因?yàn)閿?shù)據(jù)冗余了，但這對(duì)數(shù)據(jù)一致性有大的風(fēng)險(xiǎn)。這需要根據(jù)不同的業(yè)務(wù)進(jìn)行分析和處理。（注意：用關(guān)系型數(shù)據(jù)庫(kù)很容易移植 到NoSQL上，但是反過(guò)來(lái)從NoSQL到關(guān)系型就難了）

二、數(shù)據(jù)鏡像

幾乎所有主流的數(shù)據(jù)庫(kù)都支持鏡像，也就是replication。數(shù)據(jù)庫(kù)的鏡像帶來(lái)的好處就是可以做負(fù)載均衡。把一臺(tái)數(shù)據(jù)庫(kù)的負(fù)載均分到多臺(tái)上，同時(shí)又保證了數(shù)據(jù)一致性（Oracle的SCN）。最重要的是，這樣還可以有高可用性，一臺(tái)廢了，還有另一臺(tái)在服務(wù)。

數(shù)據(jù)鏡像的數(shù)據(jù)一致性可能是個(gè)復(fù)雜的問(wèn)題，所以我們要在單條數(shù)據(jù)上進(jìn)行數(shù)據(jù)分區(qū)，也就是說(shuō)，把一個(gè)暢銷商品的庫(kù)存均分到不同的服務(wù)器上，如，一個(gè)暢銷商品有1萬(wàn)的庫(kù)存，我們可以設(shè)置10臺(tái)服務(wù)器，每臺(tái)服務(wù)器上有1000個(gè)庫(kù)存，這就好像B2C的倉(cāng)庫(kù)一樣。

三、數(shù)據(jù)分區(qū)

數(shù)據(jù)鏡像不能解決的一個(gè)問(wèn)題就是數(shù)據(jù)表里的記錄太多，導(dǎo)致數(shù)據(jù)庫(kù)操作太慢。所以，把數(shù)據(jù)分區(qū)。數(shù)據(jù)分區(qū)有很多種做法，一般來(lái)說(shuō)有下面這幾種：

1）把數(shù)據(jù)把某種邏輯來(lái)分類。比如火車票的訂票系統(tǒng)可以按各鐵路局來(lái)分，可按各種車型分，可以按始發(fā)站分，可以按目的地分……，反正就是把一張表拆成多張有一樣的字段但是不同種類的表，這樣，這些表就可以存在不同的機(jī)器上以達(dá)到分擔(dān)負(fù)載的目的。

2）把數(shù)據(jù)按字段分，也就是豎著分表。比如把一些不經(jīng)常改的數(shù)據(jù)放在一個(gè)表里，經(jīng)常改的數(shù)據(jù)放在另外多個(gè)表里。把一張表變成1對(duì)1的關(guān)系，這樣，你 可以減少表的字段個(gè)數(shù)，同樣可以提升一定的性能。另外，字段多會(huì)造成一條記錄的存儲(chǔ)會(huì)被放到不同的頁(yè)表里，這對(duì)于讀寫性能都有問(wèn)題。但這樣一來(lái)會(huì)有很多復(fù) 雜的控制。

3）平均分表。因?yàn)榈谝环N方法是并不一定平均分均，可能某個(gè)種類的數(shù)據(jù)還是很多。所以，也有采用平均分配的方式，通過(guò)主鍵ID的范圍來(lái)分表。

4）同一數(shù)據(jù)分區(qū)。這個(gè)在上面數(shù)據(jù)鏡像提過(guò)。也就是把同一商品的庫(kù)存值分到不同的服務(wù)器上，比如有10000個(gè)庫(kù)存，可以分到10臺(tái)服務(wù)器上，一臺(tái)上有1000個(gè)庫(kù)存。然后負(fù)載均衡。

這三種分區(qū)都有好有壞。最常用的還是第一種。數(shù)據(jù)一旦分區(qū)，你就需要有一個(gè)或是多個(gè)調(diào)度來(lái)讓你的前端程序知道去哪里找數(shù)據(jù)。把火車票的數(shù)據(jù)分區(qū)，并放在各個(gè)省市，會(huì)對(duì)12306這個(gè)系統(tǒng)有非常有意義的質(zhì)的性能的提高。

四、后端系統(tǒng)負(fù)載均衡

前面說(shuō)了數(shù)據(jù)分區(qū)，數(shù)據(jù)分區(qū)可以在一定程度上減輕負(fù)載，但是無(wú)法減輕熱銷商品的負(fù)載，對(duì)于火車票來(lái)說(shuō)，可以認(rèn)為是大城市的某些主干線上的車票。這就 需要使用數(shù)據(jù)鏡像來(lái)減輕負(fù)載。使用數(shù)據(jù)鏡像，你必然要使用負(fù)載均衡，在后端，我們可能很難使用像路由器上的負(fù)載均衡器，因?yàn)槟鞘蔷饬髁康模驗(yàn)榱髁坎⒉?代表服務(wù)器的繁忙程度。因此，我們需要一個(gè)任務(wù)分配系統(tǒng)，其還能監(jiān)控各個(gè)服務(wù)器的負(fù)載情況。

任務(wù)分配服務(wù)器有一些難點(diǎn)：

• 負(fù)載情況比較復(fù)雜。什么叫忙？是CPU高？還是磁盤I/O高？還是內(nèi)存使用高？還是并發(fā)高？還是內(nèi)存換頁(yè)率高？你可能需要全部都要考慮。這些信息要發(fā)送給那個(gè)任務(wù)分配器上，由任務(wù)分配器挑選一臺(tái)負(fù)載最輕的服務(wù)器來(lái)處理。

• 任務(wù)分配服務(wù)器上需要對(duì)任務(wù)隊(duì)列，不能丟任務(wù)啊，所以還需要持久化。并且可以以批量的方式把任務(wù)分配給計(jì)算服務(wù)器。

• 任務(wù)分配服務(wù)器死了怎么辦？這里需要一些如Live-Standby或是failover等高可用性的技術(shù)。我們還需要注意那些持久化了的任務(wù)的隊(duì)列如何轉(zhuǎn)移到別的服務(wù)器上的問(wèn)題。

我看到有很多系統(tǒng)都用靜態(tài)的方式來(lái)分配，有的用hash，有的就簡(jiǎn)單地輪流分析。這些都不夠好，一個(gè)是不能完美地負(fù)載均衡，另一個(gè)靜態(tài)的方法的致命 缺陷是，如果有一臺(tái)計(jì)算服務(wù)器死機(jī)了，或是我們需要加入新的服務(wù)器，對(duì)于我們的分配器來(lái)說(shuō)，都需要知道的。另外，還要重算哈希（一致性hash可以部分解 決這個(gè)問(wèn)題）。

還有一種方法是使用搶占式的方式進(jìn)行負(fù)載均衡，由下游的計(jì)算服務(wù)器去任務(wù)服務(wù)器上拿任務(wù)。讓這些計(jì)算服務(wù)器自己決定自己是否要任務(wù)。這樣的好處是可 以簡(jiǎn)化系統(tǒng)的復(fù)雜度，而且還可以任意實(shí)時(shí)地減少或增加計(jì)算服務(wù)器。但是唯一不好的就是，如果有一些任務(wù)只能在某種服務(wù)器上處理，這可能會(huì)引入一些復(fù)雜度。 不過(guò)總體來(lái)說(shuō)，這種方法可能是比較好的負(fù)載均衡。

五、異步、 throttle 和 批量處理

異步、throttle（節(jié)流閥） 和批量處理都需要對(duì)并發(fā)請(qǐng)求數(shù)做隊(duì)列處理的。

• 異步在業(yè)務(wù)上一般來(lái)說(shuō)就是收集請(qǐng)求，然后延時(shí)處理。在技術(shù)上就是可以把各個(gè)處理程序做成并行的，也就可以水平擴(kuò)展了。但是異步的技術(shù)問(wèn)題大概有這 些，a）被調(diào)用方的結(jié)果返回，會(huì)涉及進(jìn)程線程間通信的問(wèn)題。b）如果程序需要回滾，回滾會(huì)有點(diǎn)復(fù)雜。c）異步通常都會(huì)伴隨多線程多進(jìn)程，并發(fā)的控制也相對(duì) 麻煩一些。d）很多異步系統(tǒng)都用消息機(jī)制，消息的丟失和亂序也會(huì)是比較復(fù)雜的問(wèn)題。

• throttle 技術(shù)其實(shí)并不提升性能，這個(gè)技術(shù)主要是防止系統(tǒng)被超過(guò)自己不能處理的流量給搞垮了，這其實(shí)是個(gè)保護(hù)機(jī)制。使用throttle技術(shù)一般來(lái)說(shuō)是對(duì)于一些自己無(wú)法控制的系統(tǒng)，比如，和你網(wǎng)站對(duì)接的銀行系統(tǒng)。

• 批量處理的技術(shù)，是把一堆基本相同的請(qǐng)求批量處理。比如，大家同時(shí)購(gòu)買同一個(gè)商品，沒(méi)有必要你買一個(gè)我就寫一次數(shù)據(jù)庫(kù)，完全可以收集到一定數(shù)量的 請(qǐng)求，一次操作。這個(gè)技術(shù)可以用作很多方面。比如節(jié)省網(wǎng)絡(luò)帶寬，我們都知道網(wǎng)絡(luò)上的MTU（最大傳輸單元），以態(tài)網(wǎng)是1500字節(jié)，光纖可以達(dá)到4000 多個(gè)字節(jié)，如果你的一個(gè)網(wǎng)絡(luò)包沒(méi)有放滿這個(gè)MTU，那就是在浪費(fèi)網(wǎng)絡(luò)帶寬，因?yàn)榫W(wǎng)卡的驅(qū)動(dòng)程序只有一塊一塊地讀效率才會(huì)高。因此，網(wǎng)絡(luò)發(fā)包時(shí)，我們需要收 集到足夠多的信息后再做網(wǎng)絡(luò)I/O，這也是一種批量處理的方式。批量處理的敵人是流量低，所以，批量處理的系統(tǒng)一般都會(huì)設(shè)置上兩個(gè)閥值，一個(gè)是作業(yè)量，另 一個(gè)是timeout，只要有一個(gè)條件滿足，就會(huì)開(kāi)始提交處理。

所以，只要是異步，一般都會(huì)有throttle機(jī)制，一般都會(huì)有隊(duì)列來(lái)排隊(duì)，有隊(duì)列，就會(huì)有持久化，而系統(tǒng)一般都會(huì)使用批量的方式來(lái)處理。

云風(fēng)同學(xué)設(shè)計(jì)的“排隊(duì)系統(tǒng)” 就是這個(gè)技術(shù)。這和電子商務(wù)的訂單系統(tǒng)很相似，就是說(shuō)，我的系統(tǒng)收到了你的購(gòu)票下單請(qǐng)求，但是我還沒(méi)有真正處理，我的系統(tǒng)會(huì)跟據(jù)我自己的處理能力來(lái)throttle住這些大量的請(qǐng)求，并一點(diǎn)一點(diǎn)地處理。一旦處理完成，我就可以發(fā)郵件或短信告訴用戶你來(lái)可以真正購(gòu)票了。

在這里，我想通過(guò)業(yè)務(wù)和用戶需求方面討論一下云風(fēng)同學(xué)的這個(gè)排隊(duì)系統(tǒng)，因?yàn)槠鋸募夹g(shù)上看似解決了這個(gè)問(wèn)題，但是從業(yè)務(wù)和用戶需求上來(lái)說(shuō)可能還是有一些值得我們?nèi)ド钊胨伎嫉牡胤剑?/p>

1）隊(duì)列的DoS攻擊。首先，我們思考一下，這個(gè)隊(duì) 是個(gè)單純地排隊(duì)的嗎？這樣做還不夠好，因?yàn)檫@樣我們不能杜絕黃牛，而且單純的ticket_id很容易發(fā)生DoS攻擊，比如，我發(fā)起N個(gè) ticket_id，進(jìn)入購(gòu)票流程后，我不買，我就耗你半個(gè)小時(shí)，很容易我就可以讓想買票的人幾天都買不到票。有人說(shuō)，用戶應(yīng)該要用身份證來(lái)排隊(duì)， 這樣在購(gòu)買里就必需要用這個(gè)身份證來(lái)買，但這也還不能杜絕黃牛排隊(duì)或是號(hào)販子。因?yàn)樗麄兛梢宰?cè)N個(gè)帳號(hào)來(lái)排隊(duì)，但就是不買。黃牛這些人這個(gè)時(shí)候只需要干 一個(gè)事，把網(wǎng)站搞得正常人不能訪問(wèn)，讓用戶只能通過(guò)他們來(lái)買。

2）對(duì)列的一致性？對(duì)這個(gè)隊(duì)列的操作是不是需要鎖？只要有鎖，性能一定上不去。試想，100萬(wàn)個(gè)人同時(shí)要求你來(lái)分配位置號(hào)，這個(gè)隊(duì)列將會(huì)成為性能瓶頸。你一定沒(méi)有數(shù)據(jù)庫(kù)實(shí)現(xiàn)得性能好，所以，可能比現(xiàn)在還差。搶數(shù)據(jù)庫(kù)和搶隊(duì)列本質(zhì)上是一樣的。

3）隊(duì)列的等待時(shí)間。購(gòu)票時(shí)間半小時(shí)夠不夠？多不 多？要是那時(shí)用戶正好不能上網(wǎng)呢？如果時(shí)間短了，用戶不夠時(shí)間操作也會(huì)抱怨，如果時(shí)間長(zhǎng)了，后面在排隊(duì)的那些人也會(huì)抱怨。這個(gè)方法可能在實(shí)際操作上會(huì)有很 多問(wèn)題。另外，半個(gè)小時(shí)太長(zhǎng)了，這完全不現(xiàn)實(shí)，我們用15分鐘來(lái)舉例：有1千萬(wàn)用戶，每一個(gè)時(shí)刻只能放進(jìn)去1萬(wàn)個(gè)，這1萬(wàn)個(gè)用戶需要15分鐘完成所有操 作，那么，這1千萬(wàn)用戶全部處理完，需要1000*15m = 250小時(shí)，10天半，火車早開(kāi)了。（我并非信口開(kāi)河，根據(jù)鐵道部專家的說(shuō)明：這幾天，平均一天下單100萬(wàn)，所以，處理1000萬(wàn)的用戶需要十天。這個(gè)計(jì)算可能有點(diǎn)簡(jiǎn)單了，我只是想說(shuō)，在這樣低負(fù)載的系統(tǒng)下用排隊(duì)可能都不能解決業(yè)務(wù)問(wèn)題）

4）隊(duì)列的分布式。這個(gè)排隊(duì)系統(tǒng)只有一個(gè)隊(duì)列好嗎？ 還不足夠好。因?yàn)椋绻惴胚M(jìn)去的可以購(gòu)票的人如果在買同一個(gè)車次的同樣的類型的票（比如某動(dòng)車臥鋪），還是等于在搶票，也就是說(shuō)系統(tǒng)的負(fù)載還是會(huì)有可能 集中到其中某臺(tái)服務(wù)器上。因此，最好的方法是根據(jù)用戶的需求——提供出發(fā)地和目的地，來(lái)對(duì)用戶進(jìn)行排隊(duì)。而這樣一來(lái)，隊(duì)列也就可以是多個(gè)，只要是多個(gè)隊(duì) 列，就可以水平擴(kuò)展了。這樣可以解決性能問(wèn)題，但是沒(méi)有解決用戶長(zhǎng)時(shí)間排隊(duì)的問(wèn)題。

我覺(jué)得完全可以向網(wǎng)上購(gòu)物學(xué)習(xí)。在排隊(duì)（下單）的時(shí)候，收集好用戶的信息和想要買的票，并允許用戶設(shè)置購(gòu)票的優(yōu)先級(jí)，比如，A車次臥鋪買 不到就買 B車次的臥鋪，如果還買不到就買硬座等等，然后用戶把所需的錢先充值好，接下來(lái)就是系統(tǒng)完全自動(dòng)地異步處理訂單。成功不成功都發(fā)短信或郵件通知用戶。這樣，系統(tǒng)不僅可以省去那半個(gè)小時(shí)的用戶交互時(shí)間，自動(dòng)化加快處理，還可以合并相同購(gòu)票請(qǐng)求的人，進(jìn)行批處理（減少數(shù)據(jù)庫(kù)的操作次數(shù)）。這種方法最妙的事是可以知道這些排隊(duì)用戶的需求，不但可以優(yōu)化用戶的隊(duì)列，把用戶分布到不同的隊(duì)列，還可以像亞馬遜的心愿單一樣，通過(guò)一些計(jì)算就可以讓鐵道部做車次統(tǒng)籌安排和調(diào)整（最后，排隊(duì)系統(tǒng)（下單系統(tǒng)）還是要保存在數(shù)據(jù)庫(kù)里的或做持久化，不能只放在內(nèi)存中，不然機(jī)器一down，就等著被罵吧）。

小結(jié)

寫了那么多，我小結(jié)一下：

0）無(wú)論你怎么設(shè)計(jì)，你的系統(tǒng)一定要能容易地水平擴(kuò)展。也就是說(shuō)，你的整個(gè)數(shù)據(jù)流中，所有的環(huán)節(jié)都要能夠水平擴(kuò)展。這樣，當(dāng)你的系統(tǒng)有性能問(wèn)題時(shí)，“加30倍的服務(wù)器”才不會(huì)被人譏笑。

1）上述的技術(shù)不是一朝一夕能搞定的，沒(méi)有長(zhǎng)期的積累，基本無(wú)望。我們可以看到，無(wú)論你用哪種都會(huì)引發(fā)一些復(fù)雜性，設(shè)計(jì)總是在做一種權(quán)衡。

2）集中式的賣票很難搞定，使用上述的技術(shù)可以讓訂票系統(tǒng)能有幾佰倍的性能提升。而在各個(gè)省市建分站，分開(kāi)賣票，是能讓現(xiàn)有系統(tǒng)性能有質(zhì)的提升的最好方法。

3）春運(yùn)前夕搶票且票量供遠(yuǎn)小于求這種業(yè)務(wù)模式是相當(dāng)變態(tài)的，讓幾千萬(wàn)甚至上億的人在某個(gè)早晨的8點(diǎn)鐘同時(shí)登錄同時(shí)搶票的這種業(yè)務(wù)模式是變態(tài)中的變態(tài)。業(yè)務(wù)形態(tài)的變態(tài)決定了無(wú)論他們?cè)趺崔k干一定會(huì)被罵。

4）為了那么一兩個(gè)星期而搞那么大的系統(tǒng)，而其它時(shí)間都在閑著，有些可惜了，這也就是鐵路才干得出來(lái)這樣的事了。

更新2012年9月27日 

 Alexa 統(tǒng)計(jì)的12306的PV （注：Alexa的PV定義是：一個(gè)用戶在一天內(nèi)對(duì)一個(gè)頁(yè)面的多次點(diǎn)擊只算一次）

原文鏈接：http://coolshell.cn/articles/6470.html