一點一滴，編程人生

業(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ù)器的時間精確同步了就可以了，無需在當(dāng)時操作任何數(shù)據(jù)庫。可以訂單數(shù)夠后，停止秒殺，然后批 量寫數(shù)據(jù)庫。火車票這個豈止是秒殺那么簡單。能不能買到票得當(dāng)時告訴用戶啊。

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

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

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

• 庫存是B2C的惡夢，庫存管理相當(dāng)?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ù)米?10萬TCP鏈接的建立 的話，那沒有問題。但在數(shù)據(jù)一致性面前，這10萬就完完全全成了一個可望不可及的理論值了。

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

一、前端負載均衡

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

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

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

五、優(yōu)化查詢

六、緩存的問題

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

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

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

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

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

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

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

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

五、異步、 throttle 和 批量處理

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

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

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

小結(jié)