創(chuàng)新互聯(lián)www.cdcxhl.cn八線動態(tài)BGP香港云服務(wù)器提供商，新人活動買多久送多久，劃算不套路！
本篇文章給大家分享的是有關(guān)youtube使用的是什么python框架，小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
YouTube發(fā)展迅速，每天超過1億的視頻點(diǎn)擊量，但只有很少人在維護(hù)站點(diǎn)和確保伸縮性。這點(diǎn)和PlentyOfFish類似，少數(shù)人維護(hù)龐大系統(tǒng)。是什么原因呢？放心絕對不是靠人品，也不是靠寂寞，下面就來看看YouTube的整體技術(shù)架構(gòu)吧。
平臺
·Apache
·Python
·Linux(SuSe)
·MySQL
·psyco，一個動態(tài)的Python到C的編譯器
·lighttpd代替Apache做視頻查看
狀態(tài)
·支持每天超過1億的視頻點(diǎn)擊量
·成立于2005年2月
·于2006年3月達(dá)到每天3千萬的視頻點(diǎn)擊量
·于2006年7月達(dá)到每天1億的視頻點(diǎn)擊量
·2個系統(tǒng)管理員，2個伸縮性軟件架構(gòu)師
·2個軟件開發(fā)工程師，2個網(wǎng)絡(luò)工程師，1個DBA
Web服務(wù)器
（1）NetScaler用于負(fù)載均衡和靜態(tài)內(nèi)容緩存。
（2）使用mod_fast_cgi運(yùn)行Apache。
（3）使用一個Python應(yīng)用服務(wù)器來處理請求的路由。
（4）應(yīng)用服務(wù)器與多個數(shù)據(jù)庫和其他信息源交互來獲取數(shù)據(jù)和格式化html頁面。
（5）一般可以通過添加更多的機(jī)器來在Web層提高伸縮性。
（6）Python的Web層代碼通常不是性能瓶頸，大部分時間阻塞在RPC。
（7）Python允許快速而靈活的開發(fā)和部署。
（8）通常每個頁面服務(wù)少于100毫秒的時間。
（9）使用psyco(一個類似于JIT編譯器的動態(tài)的Python到C的編譯器)來優(yōu)化內(nèi)部循環(huán)。
（10）對于像加密等密集型CPU活動，使用C擴(kuò)展。
（11）對于一些開銷昂貴的塊使用預(yù)先生成并緩存的html。
（12）數(shù)據(jù)庫里使用行級緩存。
（13）緩存完整的Python對象。
（14）有些數(shù)據(jù)被計算出來并發(fā)送給各個程序，所以這些值緩存在本地內(nèi)存中。這是個使用不當(dāng)?shù)牟呗浴?/p>
應(yīng)用服務(wù)器里最快的緩存將預(yù)先計算的值發(fā)送給所有服務(wù)器也花不了多少時間。只需弄一個代理來監(jiān)聽更改，預(yù)計算，然后發(fā)送。
視頻服務(wù)
（1）花費(fèi)包括帶寬，硬件和能源消耗。
（2）每個視頻由一個迷你集群來host，每個視頻被超過一臺機(jī)器持有。
（3）使用一個集群意味著：
-更多的硬盤來持有內(nèi)容意味著更快的速度。
-failover。如果一臺機(jī)器出故障了，另外的機(jī)器可以繼續(xù)服務(wù)。
-在線備份
（4）使用lighttpd作為Web服務(wù)器來提供視頻服務(wù)：
-Apache開銷太大。
-使用epoll來等待多個fds。
-從單進(jìn)程配置轉(zhuǎn)變?yōu)槎噙M(jìn)程配置來處理更多的連接。
（5）大部分流行的內(nèi)容移到CDN：
-CDN在多個地方備份內(nèi)容，這樣內(nèi)容離用戶更近的機(jī)會就會更高。
-CDN機(jī)器經(jīng)常內(nèi)存不足，因為內(nèi)容太流行以致很少有內(nèi)容進(jìn)出內(nèi)存的顛簸。
（6）不太流行的內(nèi)容(每天1-20瀏覽次數(shù))在許多colo站點(diǎn)使用YouTube服務(wù)器
-長尾效應(yīng)。一個視頻可以有多個播放，但是許多視頻正在播放。隨機(jī)硬盤塊被訪問。
-在這種情況下緩存不會很好，所以花錢在更多的緩存上可能沒太大意義。
-調(diào)節(jié)RAID控制并注意其他低級問題。
-調(diào)節(jié)每臺機(jī)器上的內(nèi)存，不要太多也不要太少 。
視頻服務(wù)關(guān)鍵點(diǎn)
（1）保持簡單和廉價。
（2）保持簡單網(wǎng)絡(luò)路徑，在內(nèi)容和用戶間不要有太多設(shè)備。
（3）使用常用硬件，昂貴的硬件很難找到幫助文檔。
（4）使用簡單而常見的工具，使用構(gòu)建在Linux里或之上的大部分工具。
（5）很好的處理隨機(jī)查找(SATA，tweaks)。
縮略圖服務(wù)
（1）做到高效令人驚奇的難。
（2）每個視頻大概4張縮略圖，所以縮略圖比視頻多很多。
（3）縮略圖僅僅host在幾個機(jī)器上。
（4）持有一些小東西所遇到的問題：
-OS級別的大量的硬盤查找和inode和頁面緩存問題。
-單目錄文件限制，特別是Ext3，后來移到多分層的結(jié)構(gòu)。內(nèi)核2.6的最近改進(jìn)可能讓 Ext3允許大目錄，但在一個文件系統(tǒng)里存儲大量文件不是個好主意。
-每秒大量的請求，因為Web頁面可能在頁面上顯示60個縮略圖。
-在這種高負(fù)載下Apache表現(xiàn)的非常糟糕。
-在Apache前端使用squid，這種方式工作了一段時間，但是由于負(fù)載繼續(xù)增加而以失敗告終。它讓每秒300個請求變?yōu)?0個。
-嘗試使用lighttpd但是由于使用單線程它陷于困境。遇到多進(jìn)程的問題，因為它們各自保持自己單獨(dú)的緩存。
-如此多的圖片以致一臺新機(jī)器只能接管24小時。
-重啟機(jī)器需要6-10小時來緩存。
（5）為了解決所有這些問題YouTube開始使用Google的BigTable，一個分布式數(shù)據(jù)存儲：
-避免小文件問題，因為它將文件收集到一起。
-快，錯誤容忍。
-更低的延遲，因為它使用分布式多級緩存，該緩存與多個不同collocation站點(diǎn)工作。
-更多信息參考Google Architecture，GoogleTalk Architecture和BigTable。
數(shù)據(jù)庫
（1）早期
-使用MySQL來存儲元數(shù)據(jù)，如用戶，tags和描述。
-使用一整個10硬盤的RAID 10來存儲數(shù)據(jù)。
-依賴于信用卡所以YouTube租用硬件。
-YouTube經(jīng)過一個常見的革命：單服務(wù)器，然后單master和多read slaves，然后數(shù)據(jù)庫分區(qū)，然后sharding方式。
-痛苦與備份延遲。master數(shù)據(jù)庫是多線程的并且運(yùn)行在一個大機(jī)器上所以它可以處理許多工作，slaves是單線程的并且通常運(yùn)行在小一些的服務(wù)器上并且備份是異步的，所以slaves會遠(yuǎn)遠(yuǎn)落后于master。
-更新引起緩存失效，硬盤的慢I/O導(dǎo)致慢備份。
-使用備份架構(gòu)需要花費(fèi)大量的money來獲得增加的寫性能。
-YouTube的一個解決方案是通過把數(shù)據(jù)分成兩個集群來將傳輸分出優(yōu)先次序：一個視頻查看池和一個一般的集群。
（2）后期
-數(shù)據(jù)庫分區(qū)。
-分成shards，不同的用戶指定到不同的shards。
-擴(kuò)散讀寫。
-更好的緩存位置意味著更少的IO。
-導(dǎo)致硬件減少30%。
-備份延遲降低到0。
-現(xiàn)在可以任意提升數(shù)據(jù)庫的伸縮性。
數(shù)據(jù)中心策略
（1）依賴于信用卡，所以最初只能使用受管主機(jī)提供商。
（2）受管主機(jī)提供商不能提供伸縮性，不能控制硬件或使用良好的網(wǎng)絡(luò)協(xié)議。
（3）YouTube改為使用colocation arrangement。現(xiàn)在YouTube可以自定義所有東西并且協(xié)定自己的契約。
（4）使用5到6個數(shù)據(jù)中心加CDN。
（5）視頻來自任意的數(shù)據(jù)中心，不是最近的匹配或其他什么。如果一個視頻足夠流行則移到CDN。
（6）依賴于視頻帶寬而不是真正的延遲?？梢詠碜匀魏蝐olo。
（7）圖片延遲很嚴(yán)重，特別是當(dāng)一個頁面有60張圖片時。
（8）使用BigTable將圖片備份到不同的數(shù)據(jù)中心，代碼查看誰是最近的。
關(guān)于擴(kuò)展性的思考
以下雖然都不是什么新思想，但希望對你有所助益。
分而治之是擴(kuò)展性技術(shù)的靈魂?？紤]以層次化的方式完成所有的工作。這也是數(shù)據(jù)分片的癥結(jié)所在。要知道如何將數(shù)據(jù)分區(qū)，以及如何將已分區(qū)的數(shù)據(jù)進(jìn)行關(guān)聯(lián)?？偠灾?，保持簡單與松散的耦合非常必要。
充分利用Python的動態(tài)特性，構(gòu)建易于擴(kuò)展的軟件架構(gòu)。
近似的正確性。要相信監(jiān)控系統(tǒng)所報告的系統(tǒng)運(yùn)行狀態(tài)。如果問題沒有出現(xiàn)，就認(rèn)為一切良好。
不一致的數(shù)據(jù)模型。例如，閱讀評論的人和寫評論的人對你刷新頁面的動作會有不同的反應(yīng)，但也不必完全基于事務(wù)處理進(jìn)行系統(tǒng)設(shè)計，這會顯得矯枉過正。我們依然需要不一致的數(shù)據(jù)模型。
分布式系統(tǒng)的隨機(jī)性。分布式系統(tǒng)就如同氣象系統(tǒng)一樣，對分布式系統(tǒng)進(jìn)行調(diào)試會存在更多的隨機(jī)性。例如，緩存過期。一般情況下，服務(wù)器會將流行的視頻緩存24小時。如果一旦出現(xiàn)緩存同時過期的情況，服務(wù)器將同時開始緩存，荷載如聞驚雷！
最快的函數(shù)調(diào)用就是不做任何調(diào)用。合理設(shè)計事務(wù)處理發(fā)生的間隔和次數(shù)。
仔細(xì)觀察API，并做到心中有數(shù)。如何定義輸入、輸出？所有的函數(shù)調(diào)用本質(zhì)上都是圍繞數(shù)據(jù)發(fā)生的，那在函數(shù)調(diào)用之后，又會發(fā)生什么？
在Python中運(yùn)用RPC重定向。程序員是代碼的構(gòu)建者，因此要做好約定。如果代碼不幸失敗了，還可以從RPC輸出中追查原因。
沒有完美的組件。一個組件的運(yùn)行周期可能持續(xù)1-6個月，具體多久，誰也說不清。隨著時間的推移，我們會用Python和C重寫一些東西，這證明你正在淘汰舊的組件，當(dāng)你觀察到一個新組件出現(xiàn)的時候，它誕生了。
沒有人了解整個系統(tǒng)的運(yùn)作機(jī)制。因此，我們需要定義組件。視頻轉(zhuǎn)碼和視頻搜索截然不同，建立良好的數(shù)據(jù)規(guī)范非常重要。
效率與擴(kuò)展性并重。最有效率的是用C實現(xiàn)進(jìn)程，但這樣的方式缺乏擴(kuò)展性。
著眼于宏觀層面、組件及其失敗的原因。使用RPC是否明智？內(nèi)聯(lián)如何？進(jìn)行分解研究，也許會發(fā)現(xiàn)不同之處。
重視算法。與其絞盡腦汁用Python來實現(xiàn)高效的算法，不如用它做些更有實用價值的事。在這方面，C語言有它的優(yōu)勢。
我們很少從事面向?qū)ο笤O(shè)計。我們使用了大量的名稱空間，使用類來組織數(shù)據(jù)，但極少面向?qū)ο蟆?/p>
我樂意用下面的詞匯來形容我們的代碼樹：簡單、實用、優(yōu)雅、正交、可組合，這是我們的追求。
總結(jié)
YouTube解決問題的哲學(xué)只有一個詞：簡單。許多YouTube的產(chǎn)品最初只是源于一個簡單的Python腳本。這正是應(yīng)了我們的一句老話，不積跬步，無以至千里；不積小流，無以成江海。
以上就是youtube使用的是什么python框架，小編相信有部分知識點(diǎn)可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。
重慶分公司
重慶分公司
