<s id="qx03x"></s>
  • <tt id="qx03x"><noscript id="qx03x"></noscript></tt><rt id="qx03x"><nav id="qx03x"></nav></rt>

    <strong id="qx03x"><li id="qx03x"></li></strong>
    <tt id="qx03x"></tt>

        1. 分頁: 1/1 第一頁 1 最后頁 [ 顯示模式: 摘要 | 列表 ]
            在淘寶上350多元,買了個基于ARM平臺的超小電腦 cubieboard,配置如下:

            1G ARM cortex-A8 processor, NEON, VFPv3, 256KB L2 cache
            Mali400, OpenGL ES GPU
            512M/1GB DDR3 @480MHz
            HDMI 1080p Output
            10/100M Ethernet
            4GB Nand Flash
            2 USB Host, 1 micro SD slot, 1 SATA, 1 ir
            96 extend pin including I2C, SPI, RGB/LVDS, CSI/TS, FM-IN, ADC, CVBS, VGA, SPDIF-OUT, R-TP..
            Running Android, Ubuntu and other Linux distributions

            點擊在新窗口中瀏覽此圖片

            點擊在新窗口中瀏覽此圖片

            找了臺支持HDMI的顯示器,安裝了Ubuntu Linaro,然后很方便的安裝了SSH Server、VNC Server、Nginx、PHP 5.3、MySQL 5.5:
          apt-get install openssh-server
          apt-get install vnc-server
          apt-get install mysql-server mysql-client
          apt-get install nginx
          apt-get install php5-fpm
          apt-get install php5-mysql php5-curl php5-gd php5-intl php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-ming php5-ps php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl


            C/C++的開發環境安裝:
          apt-get install gcc
          apt-get install g++
          apt-get install cmake
          apt-get install make

           ?。ū疚膩碜浴冻绦騿T》雜志2011年01期,《程序員》官網地址:http://www.programmer.com.cn/4544/

            主持人:馮大輝,現任丁香園 (http://www.dxy.cn)網站CTO。曾歷任支付寶架構師、數據庫團隊負責人等職。

          點擊在新窗口中瀏覽此圖片  許式偉:作為系統架構師,您一般會從哪些方面來保證網站的高可用性(降低故障時間)?

            張宴:很多因素都會導致網站發生故障,從而影響網站的高可用性,比如服務器硬件故障、軟件系統故障、IDC機房故障、程序上線前測試未發現的Bug、遭受分布式攻擊、突發訪問人數劇增等。

            一套良好的網站系統架構,應該盡可能地避免只有一臺服務器、一個數據庫、一套軟件節點等單點故障的存在。單點故障一旦發生,將直接導致網站服務不可用,恢復正常服務所需的時間也比較長,甚至還可能無法恢復。負載均衡集群、雙節點熱備、分布式處理等都可以用來解決單點故障,比如提供相同業務的Web服務器、MySQL數據庫從庫,都可以構建負載均衡集群。一旦集群中的一臺服務器、一個服務出現故障,自動實時摘除,對用戶來說是不可感知的,不會影響到整個網站的訪問,可以為運維工程師留下足夠的時間去排查和解決故障。

            對于重要的MySQL數據庫主庫,我們習慣于從硬件層和軟件層來實現熱備,避免單點。越是復雜的設備,發生故障的概率越大。在磁盤沒有損壞的情況下,應用程序導致服務器宕機的概率,遠高于簡單的磁盤陣列宕機的概率。所以,從硬件層解決的話,可以在兩臺服務器上安裝相同的數據庫版本、進行相同的配置,用SAS或SCSI線連接一臺磁盤陣列,將數據庫數據文件存放到盤陣上。正常情況下用服務器A掛載盤陣分區,啟動MySQL,綁定虛擬IP;如果服務器A宕機,則用服務器B掛載盤陣分區,啟動MySQL,接管虛擬IP。從軟件層解決的話,則可以借助DRBD等軟件做鏡像。

            IDC機房發生故障的概率較小,但如果發生的話,影響面也是最大的。如果所有服務器都托管在一個IDC機房,一旦該機房遭遇長時間流量攻擊、斷電、斷網、地方政策性封網等,通常只能聯系IDC去處理,除此之外束手無策,解決時間也比較長。如果成本允許,將網站服務器分布在兩個以上的IDC機房,當某個IDC發生故障時,可以臨時切換DNS域名解析來優先恢復服務。

            雖然程序代碼上線前,經過了測試人員的嚴格測試,但測試環境和生產環境畢竟有差異,所以一些會急劇影響性能、正常服務的Bug往往在程序上線之后,才會被發現,這就要求我們在發現Bug后,能夠迅速回滾到上一正常版本。我們在SVN的基礎上,開發了Web代碼發布系統,會將每個發布版本之間的文件變更記錄下來,一鍵實現程序代碼在多臺Web服務器上的發布和回滾。

            遭遇DDOS分布式拒絕服務攻擊,使用防火墻來對付半連接、假IP,還算比較容易。而那種專挑復雜動態應用程序URL進行的分布式CC攻擊,來源為真實IP、真實HTTP請求,具有模擬正規瀏覽器User-Agent、單個IP的每秒請求數不高、有成千上萬個攻擊源等特征,很難與正常訪問區分開,比較難對付。但是,正常通過瀏覽器訪問一個URL,會加載該URL中引入的JavaScript腳本、CSS樣式、圖片等文件。遇到CC攻擊,需要及時分析日志,找出訪問量異常上漲的URL,然后用事先寫好的shell腳本找出哪些IP的請求只訪問了該URL,而不加載該URL引入的文件,對這些IP進行自動封鎖。

            系統架構設計時,需要事先考慮到高于目前訪問量多少倍的突發訪問。對于網游站點來說,訪問量受廣告集中時間段投放、線上活動的影響較大,帶寬峰值時間不固定,對于靜態內容,可以使用商業CDN,按實際使用量計費。對于動態內容,如果遇到突發訪問人數劇增,超過現有服務器處理能力,最簡單的臨時處理辦法就是增加服務器。上架新服務器需要時間,但是,同一個IDC機房內,可以借助其他業務的服務器,在不同端口開啟一組新進程,加入到原有負載均衡池中。另外,可以臨時關閉一些Web中的次要功能,來減少服務器消耗。



            許式偉:您在任務切分上,有什么經驗分享?您通過哪些手段保證任務的獨立性?

            張宴:相信很多人都遇到過這種情況:在一個老項目上修改、增加一些新功能所花費的時間,不比重新來做一個包含所有功能的新項目時間用得少。一個需要長期維護的項目,不可避免地會面臨老員工的離職、新員工的接手,很多時候,項目代碼的可維護性將決定一個項目的生存周期。讓一個新員工在規定開發時間的壓力下,去面對一個文檔不夠詳細、陌生的、功能復雜的龐大項目,短時間弄明白所有功能邏輯不是一件容易的事。所以,任務需要切分,將一個大的任務切分成一個個小模塊之后,各模塊之間可以做到代碼獨立,互不影響,可維護性也大大增強。

            關于任務切分,我以本人今年負責的兩個重要項目架構設計為例來介紹一下。在第一個項目:金山游戲官網的《用戶行為分析系統》中,由于數據挖掘計算需要消耗較高的內存、CPU資源,一臺服務器的處理能力不夠,而商業的分布式數據倉庫價格又太貴,所以,只有從程序應用中下手,進行任務切分。我們先按需要挖掘的數據指標,將整個數據挖掘任務切分成多個數據挖掘插件,每個插件可以在不同的服務器上運行,多個插件可以同時在多臺服務器上。多個數據挖掘插件之間,如果用到相同的某項數據,那么,就將該項數據以冗余方式,復制幾份提供給需要的插件,從而實現插件之間無交互、無關聯,保證了超大數據量下插件的運算速度。

            在第二個項目:金山游戲新版運營管理系統中,則將整個任務切分成了PHP Web管理界面、PHP Web API功能接口、C/C++中間件引擎三部分。這是一種分層結構切分,最上層的“PHP Web管理界面”調用“PHP Web API功能接口”,“PHP Web API功能接口”調用運行在游戲服務器端的“C/C++中間件引擎”,“C/C++中間件引擎”與“游戲服務器端進程”通過TCP、UDP二進制協議、信號、命令行等多種方式通信。四者之間相對獨立,代碼無關聯,通過一層層API接口實現交互?!癙HP Web管理界面”負責通用界面實現?!癙HP Web API功能接口”內部,又按接入的游戲模塊、子功能模塊進行了更細的切分,各功能模塊之間通過內部API交互?!癈/C++中間件引擎”大而全,不處理具體指令,但兼容TCP、UDP、HTTP、HTTPS/SSL、信號、命令行等大多數通信方式,負責和各種類型的游戲服務端交互。這是一套完全由API接口驅動的系統架構,一款新游戲接入運營管理系統時,只需在“PHP Web API功能接口”中增加一個模塊;一個游戲新管理功能的增加,只需要在“PHP Web API功能接口”中增加一個子模塊。通過任務切分,將復雜功能簡單化,也將原來接入一款新游戲所需要的幾個月時間,縮短為1~2周。



            許式偉:您通過哪些手段,來保障產品的質量?您傾向于多久更新一次您的網站?
            此文為《程序員》雜志約稿,發表在2010年6月刊。

            文章以“KBI用戶行為分析”的項目架構為原型,對Web商業智能平臺的架構設計進行了概要介紹。實現海量數據的分析挖掘計算相對較易,如何以靈活的可擴展性框架,來便捷地應對項目開發周期中,來自眾多項目干系人的需求變更,才是難點。
            [文章作者:張宴 本文版本:v1.0 最后修改:2009.05.28 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/post/414/]

            “客戶端訪問”與“服務器端響應”,猶如一場戰爭。初期,訪問量較小,弄幾臺服務器隨便拉起一只隊伍,就能抵抗住客戶端的進攻。慢慢的,訪問量大起來,這時候,就需要講究排兵布陣、戰略戰術、多兵種協調作戰。于是,開始有了負載均衡服務器、Web服務器、緩存服務器、數據庫服務器、存儲服務器等多兵種;開始有了系統架構等戰略戰術。隨著新項目和運營需求的越來越多,我們開始了多線作戰。慢慢地,我總結了以下一些思考:

            1、“收編綠林隊伍”與“自己招兵買馬”:

            兩者的關系就猶如“使用開源軟件、框架”與“自己開發模塊、寫框架”,如果已有的開源軟件、框架、架構能夠較好地用于自己的項目,并便于擴展,則優先使用開源軟件;如果沒有現成的東西,或者已有的開源軟件性能不高、擴展性差、學習成本高,則可以取長補短,在項目中打造自己的“隊伍”。


            2、適當利用“雇傭軍”:

            在多個項目同時進行時,不要認為自己能打贏每一場戰斗,而每一場戰斗都由自己親自去打。確實,我相信很多人能夠打贏一場場戰斗,卻只有少數人能夠打贏一場戰爭。前暴雪北方“四大佬”創建的旗艦工作室的倒閉,印證了這樣一個事實:一群天才,卻沒有讓一個劃時代意義的游戲誕生。旗艦工作室放著捷徑不走卻事必躬親,自己做客戶端、自己做語聊系統、自己做圖像引擎、自己做客服系統,最終自己被自己給拖垮了。

            不要讓戰線拉得太廣,適當利用“雇傭軍”,項目中的一些非重要、非核心的組成部分可以購買其他公司的成熟產品與服務,時間、費用、維護成本可能要更低。最近,我工作中的兩項服務使用了“雇傭軍”:(1)、購買ChinaCache CDN的Flash Media Server點播加速服務,支撐金山游戲視頻宣傳站點,節省了部署多節點的成本和時間;(2)、購買快網的智能DNS解析服務,來做金山游戲官網動態內容“北京多線、珠海電信、天津網通”三個機房服務器的智能DNS解析服務,節省了收集、整理,將來更新維護IP信息等工作。


            3、打造“高技術兵器”:

            現代戰爭的特點都擁一個有共同的前提那就是:都不可能離開“高技術兵器”。同樣,要想承擔高并發訪問,而又希望系統架構簡單一點、程序開發快捷一點,那么,則需要一款服務器端的“高技術兵器”。Web 2.0網站主要組成部分有內容頁和列表頁,內容頁可以采用key-value形式的Memcached、Squid等開源產品來實現緩存,高并發訪問下需要實時更新的列表頁緩存,目前還沒有合適的開源產品來解決。MySQL等數據庫在高并發連接、大數據記錄情況下性能低下,實時更新的列表頁,成為最主要的瓶頸。我目前正在基于一些開源類庫,開發的一款簡單關系型數據庫,將實現MySQL單表擁有的大部分復雜條件查詢功能,并將達到單表千萬級以上記錄下,Memcached 60%左右的并發查詢性能,預計6月6日開發完成進入測試階段。

            4、精簡軍隊,提高戰斗力:

            軍隊越多,補給、后勤等開支也會越大,同樣,服務器越多,維護成本、托管成本、復雜度也越高。所以,服務器不是越多越好,在能夠保證容錯性、避免單點故障的情況下,如果能用一臺高配置服務器來解決的事,不要同兩臺低配置的服務器來干。

            傳統的系統架構只不過圍繞負載均衡設備或服務器、Web服務器集群、數據庫服務器集群、搜索引擎服務器集群、分布式存儲服務器集群、緩存系統服務器集群等等,技術含量并不是特別高,只不過很多人沒有生產環境的機會去實踐而已。隨著內存價格的下降,單臺服務器擴充到64G內存的事情不再罕見;Intel將會在下周面向高端服務器領域發布代號為Nehalem-EX的8核XEON處理器。隨著硬件性能的不斷提高,我預測,將來的系統架構與服務器集群將不再從服務類型上劃分,而將按“CPU密集型服務器集群”、“內存密集型服務器集群”、“存儲密集型服務器集群”劃分。我現在所設計的架構與開發的服務器端程序,也逐漸向后者轉移。

            最近,Google的工程師Luiz André Barroso and Urs H?lzle發表了一篇長達120頁的論文,提出了一個數據中心就是一臺計算機(The Datacenter as a Computer - An Introduction to the Design of Warehouse-Scale Machines )

          珠海金山軟件之行[原創]

          [不指定 2009-4-19 23:56 | by 張宴 ]
            [文章作者:張宴 本文版本:v1.0 最后修改:2009.04.19 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/post/410/]

            2009年4月14日(星期二)

            下班后,和同事打的到首都國際機場,乘21:10起飛的中國南方航空CZ3734航班飛往珠海。這也是我第一次坐飛機。

            波音737穿越著寧靜的天空,云端望月的景象,罕見而優美。經過的三個小時的飛行,掠過了大半個中國,飛機降落在珠海三灶機場。

            走出飛機,打的前往吉大區的如家快捷酒店,沿途海風撲面,濕氣彌漫,與北京的干燥行成鮮明的對比。



            2009年4月15日(星期三)

            上午10點,我們去了珠海金山軟件公司,在“萬花谷”會議室跟西山居工作室開了個小會,隨后參觀了三樓的《劍俠世界》研發團隊和四樓的《劍俠情緣網絡版3》研發團隊,向他們請教了100多人協作開發的項目管理經驗。

            下午,跟金山網游公司CTO的會議,是我主要關心的議題,以下幾項收獲也不錯:

            1、我所設計的“廣州電信機房、天津網通機房、北京電信通多線機房”三個核心IDC的系統架構得以通過,只是做了點小調整,將“廣州電信機房”換成了“珠海電信機房”,因為金山享有珠海電信在帶寬和線路上的特殊待遇。

            點擊在新窗口中瀏覽此圖片


            PS:百度網頁搜索前端服務器也分布在三個機房:北京電信機房、北京網通機房、北京長城寬帶多線機房。

            全國所有電信用戶訪問 www.baidu.com 將被解析到以下兩個VIP:
            220.181.6.19 (北京市·電信)
            220.181.6.18 (北京市·電信)

            全國所有網通用戶訪問 www.baidu.com 將被解析到以下兩個VIP:
            202.108.22.5 (北京市·網通)
            202.108.22.43 (北京市·網通)

            全國鐵通、教育網等其他訪問 www.baidu.com 將被解析到以下兩個VIP:
            119.75.213.50 (北京市·長城寬帶)
            119.75.213.51 (北京市·長城寬帶)



            2、獲批了20臺服務器。搭建我三個IDC的架構平臺,硬件資源得以滿足,剩下要解決的就是這20臺服務器盡快到位的問題了。



            3、允許了將來購買 Adobe 即將推出的 Flash Media Server 4.0 授權,利用 Flash Player 10 和 RTMFP協議(支持P2P)提供 FLV/MP4(H264) 視頻流媒體點播服務。

            目前逍遙網《基于開源Flash Server:Red5構建RTMP流媒體播放平臺》,采用的是 RTMP 協議,生產環境(劍網3相關視頻:http://jx3.xoyo.com/xgxz/video/)平均每個視頻播放所消耗的帶寬是25KB/秒,100M獨享帶寬可以支撐500人同時在線觀看。將來采用 RTMFP 協議進行 Flash P2P 視頻點播服務,將大大地節省帶寬。

            RTMFP 是 Real‐Time Media Flow Protocol的縮寫,是Adobe推出的一種新的通信協議,這種通信協議可以讓 Flash 客戶端直接和另外一個Flash 客戶端之間進行數據通信,也就是常說的P2P的方式進行通信。

            RTMFP 將會大大地減少音視頻直播、點播、多人在線游戲等應用的網絡帶寬的消耗,減輕服務器的負擔。因為很多數據都是客戶端之間直接傳輸了,無須再經過服務器中轉了。RTMFP由于使用了UDP網絡協議,所以相對之前的TCP協議在數據傳輸效率上也會大大提高,這種優勢在音視頻數據傳輸方面是非常明顯的。

            下面的示意圖表現了RTMFP和RTMP的不同之處:
            以下是 Google 檢索系統的架構師、Google Mapreduce 的發明者 Jeff Dean 在 WSDM 2009 上的主題演講:《Challenges in Building Large-Scale Information Retrieval Systems》。在這個主題演講中,Jeff Dean 講述了 Google 在10年中,Google 檢索系統的演變和發展。

            英文原文:http://research.google.com/people/jeff/WSDM09-keynote.pdf
            演講視頻:http://videolectures.net/wsdm09_dean_cblirs/

            中文譯文(由銀杏泰克有限公司郝培強翻譯):
          Tags:
            [文章作者:張宴 本文版本:v1.0 最后修改:2008.09.21 轉載請注明原文鏈接:http://blog.www.lukangtou.cn/post/369/]

            9月20日下午,我應邀參加了 ChinaUnix 舉辦的以“如何搞定服務器負載均衡?”為主題的技術沙龍(http://linux.chinaunix.net/bbs/thread-1019366-1-1.html),很高興能夠跟諸多業界精英一起探討交流,很榮幸能夠與Unix資深系統工程師──田逸、HonestQiao,以及F5資深技術工程師──楊明非,同臺演講。

            點擊在新窗口中瀏覽此圖片



            《使用Nginx輕松實現開源負載均衡》是我的演講PPT(PowerPiont),現提供下載。

            PPT分為四個部分:
            1、介紹Nginx的基本特征,以及使用Nginx做負載均衡器的理由。

            2、用實例,來介紹Nginx負載均衡在大型網站的典型應用。

            3、以實現網站動靜分離為原型,對NetScaler硬件七層負載均衡和Nginx軟件負載均衡做一個對比。
            [文章作者:張宴 本文版本:v1.1 最后修改:2008.07.17 轉載請注明出自:http://blog.www.lukangtou.cn]

            Citrix NetScaler是一款不錯的4-7層硬件負載均衡交換機,市場占有率僅次于F5 BIG-IP,位居第二。NetScaler 8.0是美國思杰系統有限公司(Citrix Systems, Inc)正式推出的最新版本NetScaler產品系列。

            從我的實際測試來看,NetScaler 8.0在七層負載均衡方面,性能和功能都要比F5 BIG-IP強。

            NetScaler 8.0的負載均衡監控中,可以對MySQL數據庫進行健康檢查,而F5 BIG-IP目前只支持對Oracle和Microsoft SQL Server數據庫的健康檢查。

            點擊在新窗口中瀏覽此圖片

            但是,NetScaler 8.0自帶的MySQL健康檢查腳本(nsmysql.pl)并不完善,它只能檢查一條SQL語句執行是否出錯,并不能檢查MySQL主從結構中的MySQL Slave數據庫同步是否正常、表有無損壞、同步延遲是否過大、是否出現錯誤、非sleeping狀態的連程數是否過高等情況。于是,我根據自己的需要,為NetScaler 8.0寫了一個MySQL Slave數據庫負載均衡健康檢查腳本(nsmysql-slave.pl),實現了上述需求。

            有了“nsmysql-slave.pl”做健康檢查,利用NetScaler的VIP(虛擬IP),就可以完美實現多臺MySQL Slave數據庫的負載均衡了。當一臺MySQL Slave數據庫出現不同步、表損壞、同步延遲過大(本腳本中默認設置的落后MySQL主庫600秒視為延遲,可根據具體應用修改)、活動連程數太高(本腳本中默認設置的是大于200視為連程數太高,可根據具體應用修改)等情況,“nsmysql-slave.pl”就會自動將其檢查出來,并告知NetScaler,NetScaler會將該數據庫標識為宕機,從而不將用戶的查詢請求傳送到這臺發生故障的數據庫上。故障一旦修復,“nsmysql-slave.pl”會自動告知NetScaler,該數據庫已經可以使用。

            “nsmysql-slave.pl”源代碼如下:
          Tags: , , , , ,
            [文章作者:張宴 本文版本:v1.0 最后修改:2008.05.22 轉載請注明出自:http://blog.www.lukangtou.cn/f5_big_ip]

            前言:最近一直在對比測試F5 BIG-IP和Citrix NetScaler負載均衡器的各項性能,于是寫下此篇文章,記錄F5 BIG-IP的常見應用配置方法。

            目前,許多廠商推出了專用于平衡服務器負載的負載均衡器,如F5 Network公司的BIG-IP,Citrix公司的NetScaler。F5 BIG-IP LTM 的官方名稱叫做本地流量管理器,可以做4-7層負載均衡,具有負載均衡、應用交換、會話交換、狀態監控、智能網絡地址轉換、通用持續性、響應錯誤處理、IPv6網關、高級路由、智能端口鏡像、SSL加速、智能HTTP壓縮、TCP優化、第7層速率整形、內容緩沖、內容轉換、連接加速、高速緩存、Cookie加密、選擇性內容加密、應用攻擊過濾、拒絕服務(DoS)攻擊和SYN Flood保護、防火墻—包過濾、包消毒等功能。

            以下是F5 BIG-IP用作HTTP負載均衡器的主要功能:
           ?、?、F5 BIG-IP提供12種靈活的算法將所有流量均衡的分配到各個服務器,而面對用戶,只是一臺虛擬服務器。
           ?、?、F5 BIG-IP可以確認應用程序能否對請求返回對應的數據。假如F5 BIG-IP后面的某一臺服務器發生服務停止、死機等故障,F5會檢查出來并將該服務器標識為宕機,從而不將用戶的訪問請求傳送到該臺發生故障的服務器上。這樣,只要其它的服務器正常,用戶的訪問就不會受到影響。宕機一旦修復,F5 BIG-IP就會自動查證應用已能對客戶請求作出正確響應并恢復向該服務器傳送。
           ?、?、F5 BIG-IP具有動態Session的會話保持功能。
           ?、?、F5 BIG-IP的iRules功能可以做HTTP內容過濾,根據不同的域名、URL,將訪問請求傳送到不同的服務器。



            下面,結合實例,配置F5 BIG-IP LTM v9.x:

            點擊在新窗口中瀏覽此圖片

           ?、?、如圖,假設域名blog.www.lukangtou.cn被解析到F5的外網/公網虛擬IP:61.1.1.3(vs_squid),該虛擬IP下有一個服務器池(pool_squid),該服務器池下包含兩臺真實的Squid服務器(192.168.1.11和192.168.1.12)。
           ?、?、如果Squid緩存未命中,則會請求F5的內網虛擬IP:192.168.1.3(vs_apache),該虛擬IP下有一個默認服務器池(pool_apache_default),該服務器池下包含兩臺真實的Apache服務器(192.168.1.21和192.168.1.22),當該虛擬IP匹配iRules規則時,則會訪問另外一個服務器池(pool_apache_irules),該服務器池下同樣包含兩臺真實的Apache服務器(192.168.1.23和192.168.1.24)。
           ?、?、另外,所有真實服務器的默認網關指向F5的自身內網IP,即192.168.1.2。
           ?、?、所有的真實服務器通過SNAT IP地址61.1.1.4訪問互聯網。



            詳細配置步驟:
          Tags: , , , , , ,

          YouTube 系統架構

          [不指定 2007-12-27 18:08 | by 張宴 ]
            視頻演講:Cuong Do (YouTube/Google 的一位工程部經理)
            演講地點:西雅圖擴展性的技術研討會

            以下為 Kyle Cordes 根據上述視頻寫下的文章:

            YouTube Scalability Talk

            Cuong Do of YouTube / Google recently gave a Google Tech Talk on scalability.

            I found it interesting in light of my own comments on YouTube’s 45 TB a while back.

            Here are my notes from his talk, a mix of what he said and my commentary:

            In the summer of 2006, they grew from 30 million pages per day to 100 million pages per day, in a 4 month period. (Wow! In most organizations, it takes nearly 4 months to pick out, order, install, and set up a few servers.)

            YouTube uses Apache for FastCGI serving. (I wonder if things would have been easier for them had they chosen nginx, which is apparently wonderful for FastCGI and less problematic than Lighttpd)
          分頁: 1/1 第一頁 1 最后頁 [ 顯示模式: 摘要 | 列表 ]
          在线精品国产在线视频