色情業(yè)是個(gè)大行業(yè)。互聯(lián)網(wǎng)上沒(méi)有多少網(wǎng)站的流量能和最大的色情網(wǎng)站相匹敵。

要搞定這巨大的流量很難。更困難的是，在色情網(wǎng)站上提供的很多內(nèi)容都是低延遲的實(shí)時(shí)流媒體而不是簡(jiǎn)單的靜態(tài)視頻。但是對(duì)于所有碰到過(guò)的挑戰(zhàn)，我很少看到有搞定過(guò)它們的開(kāi)發(fā)人員寫(xiě)的東西。所以我決定把自己在這方面的經(jīng)驗(yàn)寫(xiě)出來(lái)。 

問(wèn)題是什么？

幾年前，我正在為當(dāng)時(shí)全世界訪問(wèn)量排名26的網(wǎng)站工作 — 這里不是說(shuō)的色情網(wǎng)站排名，而是全世界排名。

當(dāng)時(shí)，該網(wǎng)站通過(guò)RTMP(Real Time Messaging protocol)協(xié)議響應(yīng)對(duì)色情流媒體的請(qǐng)求。更具體地說(shuō)，它使用了Adobe的FMS(Flash Media Server)技術(shù)為用戶提供實(shí)時(shí)流媒體。基本過(guò)程是這樣的：

1. 用戶請(qǐng)求訪問(wèn)某個(gè)實(shí)時(shí)流媒體
2. 服務(wù)器通過(guò)一個(gè)RTMP session響應(yīng)，播放請(qǐng)求的視頻片段

因?yàn)槟承┰颍現(xiàn)MS對(duì)我們并不是一個(gè)好的選擇，首先是它的成本，包括了購(gòu)買以下兩者：

1. 為每一臺(tái)運(yùn)行FMS的服務(wù)器購(gòu)買Windows的版權(quán)
2. 大約4000美元一個(gè)的FMS特定版權(quán)，由于我們的規(guī)模，我們必須購(gòu)買的版權(quán)量數(shù)以百計(jì)，而且每天都在增加。

所有這些費(fèi)用開(kāi)始不斷累積。撇開(kāi)成本不提，F(xiàn)MS也是一個(gè)比較挫的產(chǎn)品，特別是在它的功能方面（我過(guò)一會(huì)再詳細(xì)說(shuō)這個(gè)問(wèn)題）。所以我決定拋棄FMS，自己從頭開(kāi)始寫(xiě)一個(gè)自己的RTMP解析器。

最后，我終于把我們的服務(wù)效率提升了大約20倍。

開(kāi)始

這里涉及到兩個(gè)核心問(wèn)題：首先，RTMP和其他的Adobe協(xié)議及格式都不是開(kāi)放的，這就很難使用它們。要是對(duì)文件格式都一無(wú)所知，你如何能對(duì)它進(jìn) 行反向工程或者解析它呢？幸運(yùn)的是，有一些反向工程的嘗試已經(jīng)在公開(kāi)領(lǐng)域出現(xiàn)了（并不是Adobe出品的，而是osflash.org，它破解了一些協(xié) 議），我們的工作就是基于這些成果。

注：Adobe后來(lái)發(fā)布了所謂的“規(guī)格說(shuō)明書(shū)”，比起在非Adobe提供的反向工程wiki和文檔中披露的內(nèi)容，這個(gè)說(shuō)明書(shū)里也沒(méi)有啥新東西。他們 給的規(guī)格說(shuō)明書(shū)的質(zhì)量之低劣達(dá)到了荒謬的境地，近乎不可能通過(guò)該說(shuō)明書(shū)來(lái)使用它們的庫(kù)。而且，協(xié)議本身看起來(lái)常常也是有意做成具有誤導(dǎo)性的。例如：

1. 他們使用29字節(jié)的整形數(shù)。
2. 他們?cè)趨f(xié)議頭上所有地方都采用低地址存放最高有效字節(jié)(big endian)的格式，除了在某一個(gè)字段（而且未標(biāo)明）上采用低地址存放最低有效字節(jié)(little endian)的格式。
3. 他們?cè)趥鬏?K的視頻時(shí)，不惜耗費(fèi)計(jì)算能力去壓縮數(shù)據(jù)減少空間，這基本上是沒(méi)意義的，因?yàn)樗麄冞@么折騰一次也就是減少幾位或幾個(gè)字節(jié)，對(duì)這樣的一個(gè)文件大小可以忽略不計(jì)了。

還有，RTMP是高度以session為導(dǎo)向的，這使得它基本上不可能對(duì)流進(jìn)行組播。理想狀態(tài)下，如果多個(gè)用戶要求觀看同一個(gè)實(shí)時(shí)視頻流，我們可以 直接向他們傳回指向單個(gè)session的指針，在該session里傳輸這個(gè)視頻流（這就是組播的概念）。但是用RTMP的話，我們必須為每一個(gè)要求訪問(wèn) 特定流的用戶創(chuàng)建全新的一個(gè)實(shí)例。這是完全的浪費(fèi)。

[[72331]] 

我的解決辦法

想到了這些，我決定把典型的響應(yīng)流重新打包和解析為FLV“標(biāo)簽”（這里的“標(biāo)簽”指某個(gè)視頻、音頻或者元數(shù)據(jù)）。這些FLV標(biāo)簽可以在RTMP下順利地傳輸。

這樣一個(gè)方法的好處是：

• 我們只需要給流重新打包一次（重新打包是一個(gè)噩夢(mèng)，因?yàn)槿鄙僖?guī)格說(shuō)明，還有前面說(shuō)到的惡心協(xié)議）。
• 通過(guò)套用一個(gè)FLV頭，我們可以在客戶端之間順暢地重用任何流，而用內(nèi)部的FLV標(biāo)簽指針（配以某種聲明其在流內(nèi)部確切位置的位移值）就可以訪問(wèn)到真正的內(nèi)容。

我一開(kāi)始用我當(dāng)時(shí)最熟悉的C語(yǔ)言進(jìn)行開(kāi)發(fā)。一段時(shí)間后，這個(gè)選擇變得麻煩了，所以我開(kāi)始學(xué)習(xí)Python并移植我的C代碼。開(kāi)發(fā)過(guò)程加快了，但在做 了一些演示版本后，我很快遇到了資源枯竭的問(wèn)題。Python的socket處理并不適合處理這些類型的情況，具體說(shuō)，我們發(fā)現(xiàn)在自己的Python代碼 里，每個(gè)action都進(jìn)行了多次系統(tǒng)調(diào)用和context切換，這增加了巨大的系統(tǒng)開(kāi)銷。

改進(jìn)性能：混合使用Python和C

在對(duì)代碼進(jìn)行梳理之后，我選擇將性能最關(guān)鍵的函數(shù)移植到內(nèi)部完全用C語(yǔ)言編寫(xiě)的一個(gè)Python模塊中。這基本是底層的東西，具體地說(shuō)，它利用了內(nèi)核的epoll機(jī)制提供了一個(gè)O(log n)的算法復(fù)雜度。

在異步socket編程方面，有一些機(jī)制可以提供有關(guān)特定socket是否可讀/可寫(xiě)/出錯(cuò)之類的信息。過(guò)去，開(kāi)發(fā)人員們可以用select()系 統(tǒng)調(diào)用獲取這些信息，但很難大規(guī)模使用。Poll()是更好的選擇，但它仍然不夠好，因?yàn)槟忝看握{(diào)用的時(shí)候都要傳遞一大堆socket描述符。

Epoll的神奇之處在于你只需要登記一個(gè)socket，系統(tǒng)會(huì)記住這個(gè)特定的socket并處理所有內(nèi)部的雜亂的細(xì)節(jié)。這樣在每次調(diào)用的時(shí)候就沒(méi) 有傳遞參數(shù)的開(kāi)銷了。而且它適用的規(guī)模也大有可觀，它只返回你關(guān)心的那些socket，相比用其他技術(shù)時(shí)必須從10萬(wàn)個(gè)socket描述符列表里挨個(gè)檢查 是否有帶字節(jié)掩碼的事件，其優(yōu)越性真是非同小可啊。

不過(guò)，為了性能的提高，我們也付出了代價(jià)：這個(gè)方法采用了完全和以前不同的設(shè)計(jì)模式。該網(wǎng)站以前的方法是（如果我沒(méi)記錯(cuò)的話）單個(gè)原始進(jìn)程，在接收和發(fā)送時(shí)會(huì)阻塞。我開(kāi)發(fā)的是一套事件驅(qū)動(dòng)方案，所以為了適應(yīng)這個(gè)新模型，我必須重構(gòu)其他的代碼。

具體地說(shuō)，在新方法中，我們有一個(gè)主循環(huán)，它按如下方式處理接收和發(fā)送：

1. 接收到的數(shù)據(jù)（作為消息）被傳遞到RTMP層
2. RTMP包被解析，從中提取出FLV標(biāo)簽
3. FLV數(shù)據(jù)被傳輸?shù)骄彺婧徒M播層，在該層對(duì)流進(jìn)行組織并填充到底層傳輸緩存中
4. 發(fā)送程序?yàn)槊總€(gè)客戶端保存一個(gè)結(jié)構(gòu)，包含了最后一次發(fā)送的索引，并盡可能多地向客戶端傳送數(shù)據(jù)

這是一個(gè)滾動(dòng)的數(shù)據(jù)窗口，并包含了某些試探性算法，當(dāng)客戶端速度太慢無(wú)法接收時(shí)會(huì)丟棄一些幀。總體來(lái)說(shuō)運(yùn)行的很好。 

系統(tǒng)層級(jí)，架構(gòu)和硬件問(wèn)題

但是我們又遇到另外一個(gè)問(wèn)題：內(nèi)核的context切換成為了一個(gè)負(fù)擔(dān)。結(jié)果，我們選擇每100毫秒發(fā)送一次而不是實(shí)時(shí)發(fā)送。這樣可以把小的數(shù)據(jù)包匯總起來(lái)，也避免了context切換的爆炸式出現(xiàn)。

也許更大的一個(gè)問(wèn)題在于服務(wù)器架構(gòu)方面：我們需要一個(gè)具備負(fù)載均衡和容錯(cuò)能力的服務(wù)器集群，畢竟因?yàn)榉?wù)器功能異常而失去用戶不是件好玩的事情。一 開(kāi)始，我們采用了專職總管服務(wù)器的方法，它指定一個(gè)”總管“負(fù)責(zé)通過(guò)預(yù)測(cè)需求來(lái)產(chǎn)生和消除播放流。這個(gè)方法華麗麗地失敗了。實(shí)際上，我們嘗試過(guò)的每個(gè)方法 都相當(dāng)明顯地失敗了。最后，我們采用了一個(gè)相對(duì)暴力的方法，在集群的各個(gè)節(jié)點(diǎn)之間隨機(jī)地共享播放的流，使流量基本平衡了。

這個(gè)方法是有效的，但是也有一些不足：雖然一般情況下它處理的很好，我們也碰到了當(dāng)所有網(wǎng)站用戶（或者相當(dāng)大比例的用戶）觀看單個(gè)廣播流的時(shí)候，性 能會(huì)變得非常糟糕。好消息是，除了一次市場(chǎng)宣傳活動(dòng)（marketing campaign）之外，這種情況再也沒(méi)出現(xiàn)過(guò)。我們部署了另外一套單獨(dú)的集群來(lái)處理這種情況，但真實(shí)的情況是我們先分析了一番，覺(jué)得為了一次市場(chǎng)活動(dòng)而 犧牲付費(fèi)用戶的體驗(yàn)是說(shuō)不過(guò)去的，實(shí)際上，這個(gè)案例也不是一個(gè)真實(shí)的事件（雖然說(shuō)能處理所有想象得到的情況也是很好的）。 

結(jié)論

這里有最后結(jié)果的一些統(tǒng)計(jì)數(shù)字：每天在集群里的流量在峰值時(shí)是大約10萬(wàn)用戶（60%負(fù)載），平均是5萬(wàn)。我管理了2個(gè)集群（匈牙利和美國(guó)），每個(gè) 里有大約40臺(tái)服務(wù)器共同承擔(dān)這個(gè)負(fù)載。這些集群的總帶寬大約是50 Gbps，在負(fù)載達(dá)到峰值時(shí)大約使用了10 Gbps。最后，我努力做到了讓每臺(tái)服務(wù)器輕松地能提供10 Gbps帶寬，也就等于一臺(tái)服務(wù)器可以承受30萬(wàn)用戶同時(shí)觀看視頻流。

已有的FMS集群包含了超過(guò)200臺(tái)服務(wù)器，我只需要15臺(tái)就可以取代他們，而且其中只有10臺(tái)在真正提供服務(wù)。這就等于200除以10，等于20 倍的性能提高。大概我在這個(gè)項(xiàng)目里最大的收獲就是我不應(yīng)讓自己受阻于學(xué)習(xí)新技能的困難。具體說(shuō)來(lái)，Python、轉(zhuǎn)碼、面向?qū)ο缶幊蹋@些都是我在做這個(gè) 項(xiàng)目之前缺少專業(yè)經(jīng)驗(yàn)的概念。

這個(gè)信念，以及實(shí)現(xiàn)你自己的方案的信心，會(huì)給你帶來(lái)很大的回報(bào)。

【1】后來(lái)，當(dāng)我們把新代碼投入生產(chǎn)，我們又遇到了硬件問(wèn)題，因?yàn)槲覀兪褂美系膕r2500 Intel架構(gòu)服務(wù)器，由于它們的PCI總線帶寬太低，不能支持10 Gbit的以太網(wǎng)卡。沒(méi)轍，我們只好把它們用在1-4×1 Gbit的以太網(wǎng)池中（把多個(gè)網(wǎng)卡的性能匯總為一個(gè)虛擬網(wǎng)卡）。最終，我們獲得了一些更新的sr2600 i7 Intel架構(gòu)服務(wù)器，它們通過(guò)光纖達(dá)到了無(wú)性能損耗的10 Gbps帶寬。所有上述匯總的結(jié)果都是基于這樣的硬件條件來(lái)計(jì)算的。

英文原文：GERGELY KALMAN，編譯：@老碼農(nóng)的自留地

譯文鏈接：http://blog.jobbole.com/39323/