1. 程式人生 > >大型入口網站架構分析[轉]

大型入口網站架構分析[轉]

千萬人同時訪問的網站,一般是有很多個數據庫同時工作,說明白一點就是資料庫叢集和併發控制,這樣的網站實時性也是相對的。這些網站都有一些共同的特點:

資料量大,線上人數多,併發請求多,pageview高,響應速度快。總結了一下各個大網站的架構,主要提高效率及穩定性的幾個地方包括:

1、程式
程式開發是一方面,系統架構設計(硬體+網路+軟體)是另一方面。
軟體架構方面,做網站首先需要很多web伺服器儲存靜態資源,比如圖片、視訊、靜態頁等,千萬不要把靜態資源和應用伺服器放在一起。
一個好的程式設計師寫出來的程式會非常簡潔、效能很好,一個初級程式設計師可能會犯很多低階錯誤,這也是影響網站效能的原因之一。
網站要做到效率高,不光是程式設計師的事情,資料庫優化、程式優化這是必須的

,在效能優化上要資料庫和程式齊頭並進!快取也是兩方面同時入手

第一,資料庫快取和資料庫優化,這個由dba完成(而且這個有非常大的潛力可挖,只是由於我們都是程式設計師而忽略了他而已)。

第二,程式上的優化,這個非常的有講究,比如說重要一點就是要規範SQL語句,少用in 多用or,多用preparestatement 儲存過程,另外避免程式冗餘如查詢資料少用雙重迴圈等。另外選用優秀的開源框架加以支援,我個人認為中後臺的支援是最最重要的,可以選取spring+ibatis。因為ibatis直接操作SQL並有快取機制。spring的好處就不用我多說了,IOC的機制可以避免new物件,這樣也節省開銷。據我分析,絕大部分的開銷就是在NEW的時候和連線資料庫時候產生的,請儘量避免。另外可以用一些記憶體測試工具

來做一個demo說明hibernate和ibatis誰更快!前臺你想用什麼就用什麼,struts,webwork都成,如果覺得自己挺牛X可以試試用tapestry。
用資料庫也未必不能解決訪問量巨大所帶來的問題,作成靜態檔案硬碟的定址時間也未必少於資料庫的搜尋時間,當然對資料的索引要下一翻工夫。我自己覺得門戶往往也就是當天、熱門的資料點選率較高,將其做快取最多也不過1~2G的資料量吧,舉個例子:

◎ 拿網易新聞來說http://news.163.com/07/0606/09/3GA0D10N00011229.html
格式化一下,方便理解:http://域名/年/月日/新聞所屬分類/新聞ID.html
可以把當天釋出的、熱門的、瀏覽量大的作個快取
,用hashtable(key:年-月-日-分類-ID,value:新聞物件),靜態將其放到記憶體(速度絕對快過硬碟定址靜態頁面)。

通常是採用oracle儲存過程+2個weblogic,更新機制也幾乎一樣每簽發一條新聞,就會生成靜態頁面,然後發往前端的web伺服器,前端的web都是做負載均衡的。另外還有定時程式,每5-15分鐘自動生成一次。在釋出新聞的同時將資料快取。當然快取也不會越來越大,在個特定的時間段(如凌晨)刪除過期的資料。做一個大的網站遠沒有想象中那麼簡單,伺服器基本就要百十個的。
這樣可以大大增加一臺計算機的處理速度,如果一臺機器處理不了,可以用httpserver叢集來解決問題了。

2、網路
中國的網路分南電信和北網通,訪問的ip就要區分南北進入不同的網路。

3、叢集
通常會使用CDN與GSBL與DNS負載均衡技術,每個地區一組前臺伺服器群,比如新浪和搜狐,而網易,百度使用了DNS負載均衡技術,每個頻道一組前臺伺服器;一搜使用了DNS負載技術,所有頻道共用一組前臺伺服器叢集。
網站使用基於Linux叢集的負載均衡,失敗恢復,包括應用伺服器和資料庫伺服器,基於linux-ha的服務狀態檢測及高可用化。
應用伺服器叢集可以採用apache+tomcat叢集和weblogic叢集等;web伺服器叢集可以用反向代理,也可以用NAT的方式,或者多域名解析都可以;Squid也可以,方法很多,可以根據情況選擇。

4、資料庫
因為是千萬人同時訪問的網站,所以一般是有很多個數據庫同時工作的,說明白一點就是資料庫叢集和併發控制,資料分佈到地理位置不同的資料中心,以免發生斷電事故。

主流的資料庫有Sun的是MySQL和Oracle。
Oracle是一款優秀的、廣泛採用的商業資料庫管理軟體。有很強大的功能和安全性,可以處理相對海量的資料。而MySQL是一款非常優秀的開源資料庫管理軟體,非常適合用多臺PC Server組成多點的儲存節點陣列(這裡我所指的不是MySQL自身提供的叢集功能),每單位的資料儲存成本也非常的低廉。用多臺PC Server安裝MySQL組成一個儲存節點陣列,通過MySQL自身的Replication或者應用自身的處理,可以很好的保證容錯(允許部分節點失效),保證應用的健壯性和可靠性。可以這麼說,在關係資料庫管理系統的選擇上,可以考慮應用本身的情況來決定。

MySQL資料庫伺服器的master-slave模式,利用資料庫伺服器在主從伺服器間進行同步,應用只把資料寫到主伺服器,而讀資料時則根據負載選擇一臺從伺服器或者主伺服器來讀取,將資料按不同策略劃分到不同的伺服器(組)上,分散資料庫壓力。

另外還有一點的是,那些網站的靜態化網頁並不是真的,而是通過動態網頁與靜態網頁網址交換所出現的假象,這可以用urlrewrite這樣的開源網址對映器實現。這樣的網站實時性也是相對的,因為在資料庫複製資料的時候有一個過程,一般在技術上可以用到hibernate和ecache,但是如果要使網站工作地更好,可以使用EJB和websphere,weblogic這樣大型的伺服器來支援,並且要用oracle這樣的大型資料庫。
大型入口網站不建議使用Mysql資料庫,除非你對Mysql資料的優化非常熟悉。Mysql資料庫伺服器的master-slave模式,利用資料庫伺服器在主從伺服器間進行同步,應用只把資料寫到主伺服器,而讀資料時則根據負載選擇一臺從伺服器或者主伺服器來讀取,將資料按不同策略劃分到不同的伺服器(組)上,分散資料庫壓力。
大型網站要用oracle,資料方面操作儘量多用儲存過程,絕對提升效能;同時要讓DBA對資料庫進行優化,優化後的資料庫與沒優化的有天壤之別;同時還可以擴充套件分散式資料庫,以後這方面的研究會越來越多;

5、頁面
從開始就考慮使用虛擬儲存/簇檔案系統。它能讓你大量並行IO訪問,而且不需要任何重組就能夠增加所需要的磁碟。
頁面資料呼叫更要認真設計,一些資料查詢可以不通過資料庫的方式,實時性要求不高的可以使用lucene來實現,即使有實時性的要求也可以用lucene(基於Java的全文索引/檢索引擎),lucene+compass還是非常優秀的。
新聞類的網站可以用靜態頁儲存,採用定時更新機制減輕伺服器負擔;首頁每個小模組可以使用oscache快取,這樣不用每次都拉資料。
前端的基於靜態頁面快取的web加速器,主要應用有squid等。squid 將大部分靜態資源(圖片,js,css等)快取起來,直接返回給訪問者,減少應用伺服器的負載
網站的靜態化網頁並不是真的,而是通過動態網頁與靜態網頁網址交換做出現的假象,這可以用urlrewrite這樣的開源網址對映器實現,字尾名為htm或者html並不能說明程式生成了靜態頁面,可能是通過url重寫來實現的,為的只不過是在搜尋引擎中提升自己網站的覆蓋面積罷了。
生成靜態頁面的伺服器和www伺服器是兩組不同的伺服器頁面生成後才會到www伺服器,一部分資料庫並不是關係資料庫,這樣更適合資訊衍生,www、mail伺服器、路由器多,主要用負載平衡解決訪問瓶頸。
◎ 靜態頁面的缺點:
1) 增加了程式的複雜度
2) 不利於管理資料
3) 速度不是最快
4) 傷硬碟

6、快取
從一開始就應該使用快取,快取記憶體是一個更好的地方儲存臨時資料,比如Web站點上跟蹤一個特定使用者的會話產生的臨時檔案,就不再需要記錄到資料庫裡。
不能用lucene實現的可以用快取,分散式快取可以用memcached,如果有錢的話用10來臺機器做快取,> 10G的儲存量相信存什麼都夠了;如果沒錢的話可以在頁面快取和資料快取上下功夫,多用OSCACHE和EHCACHE,SWARMCACHE也可以,不過據說同步性不是很好;
可以使用Memcache(分散式快取)進行快取,用大記憶體把這些不變的資料全都快取起來,而當修改時就通知cache過期,memcache是LJ開發的一款分散式快取產品,很多大型網站在應用,我們可以把Cache Server與App Server裝在一起。因為Cache Server對CPU消耗不大,而有了Cache Server的支援,App Server對記憶體要求也不是太高,所以可以和平共處,更有效的利用資源。

單機記憶體快取、檔案快取、資料庫快取等的策略都是可以很簡單的實現的,例如可以使用微軟的Caching Application Block,但如何在叢集環境中使多個快取、多層快取並儲存同步是個重大問題。大型網站一般都使用快取伺服器群,並使用多層快取。業內最常用的有:

Squid cache,Squid伺服器群,把它作為web伺服器端前置cache伺服器快取相關請求來提高web伺服器速度。Squid將大部分靜態資源(圖片,js,css等)快取起來,直接返回給訪問者,減少應用伺服器的負載

memcache,memcache伺服器群,一款分散式快取產品,很多大型網站在應用; 它可以應對任意多個連線,使用非阻塞的網路IO。由於它的工作機制是在記憶體中開闢一塊空間,然後建立一個HashTable,Memcached自管理這些HashTable。因為通常網站應用程式中最耗費時間的任務是資料在資料庫的檢索,而多個使用者查詢相同的SQL時,資料庫壓力會增大,而通過memcache的查詢快取命中,資料直接從memcache記憶體中取,每次快取命中將替換到資料庫伺服器的一次往返,到達資料庫伺服器的請求更少,間接地提高了資料庫伺服器的效能,從而使應用程式執行得更快。它通過基於記憶體快取物件來減少資料庫查詢的方式改善網站系統的反應,其最吸引人的一個特性就是支援分散式部署。有關memcache,以下文章可以參考:參考1參考2參考3官方站點

e-Accelerator,比較特殊,PHP的快取和加速器。是一個免費開源的PHP加速、優化、編譯和動態快取的專案,它可以通過快取PHP程式碼編譯後的結果來提高PHP指令碼的效能,使得一向很複雜和離我們很遠的 PHP指令碼編譯問題完全得到解決。通過使用eAccelerator,可以優化你的PHP程式碼執行速度,降低伺服器負載,可以提高PHP應用執行速度最高達10倍。

7、伺服器作業系統與Web伺服器
最底層首先是作業系統。好的作業系統能提高好的效能、穩定性和安全性,而這些對大型網站的效能、安全性和穩定性都是至關重要的。

  • 淘寶網(阿里巴巴): Linux作業系統 + Web 伺服器: Apache
  • 新浪:FreeBSD + Web 伺服器:Apache
  • Yahoo:FreeBSD + Web 伺服器:自己的
  • Google: 部分Linux + Web 伺服器:自己的
  • 百度:Linux + Web 伺服器: Apache
  • 網易:Linux + Web 伺服器: Apache
  • eBay: Windows Server 2003/8 (大量) + Web 伺服器:Microsoft IIS
  • MySpace: Windows Server 2003/8 + Web 伺服器:Microsoft IIS

由此可見,開源作業系統做Web應用是首選已經是一個既定事實。在開源作業系統中Linux和FreeBSD差不太多,很難說哪個一定比另外一個要優秀很多、能夠全面的超越對手,應該是各有所長。但熟悉Linux的技術人員更多些,利於系統管理、優化等,所以Linux使用更廣泛。而Windows Server和IIS雖然有的網站使用,但不開源,而且需要購買微軟的一系列應用產品,限制了其使用。總之,開源作業系統,尤其是Linux做Web應用是首選已經是一個既定事實。
常用的系統架構是:

  • Linux + Apache + PHP + MySQL
  • Linux + Apache + Java (WebSphere) + Oracle
  • Windows Server 2003/2008 + IIS + C#/ASP.NET + 資料庫

以上一些不太成熟的想法,可以從某一個層次開始,逐步細化,把產品的效能指標提高上去。

以下內容為轉載:淺析大型網站的架構
一個小型的網站,比如個人網站,可以使用最簡單的html靜態頁面就實現了,配合一些圖片達到美化效果,所有的頁面均存放在一個目錄下,這樣的網站對系統架構、效能的要求都很簡單,隨著網際網路業務的不斷豐富,網站相關的技術經過這些年的發展,已經細分到很細的方方面面,尤其對於大型網站來說,所採用的技術更是涉及面非常廣,從硬體到軟體、程式語言、資料庫、WebServer、防火牆等各個領域都有了很高的要求,已經不是原來簡單的html靜態網站所能比擬的。
大型網站,比如入口網站。在面對大量使用者訪問、高併發請求方面,基本的解決方案集中在這樣幾個環節:使用高效能的伺服器、高效能的資料庫、高效率的程式語言、還有高效能的Web容器。但是除了這幾個方面,還沒法根本解決大型網站面臨的高負載和高併發問題。
上面提供的幾個解決思路在一定程度上也意味著更大的投入,並且這樣的解決思路具備瓶頸,沒有很好的擴充套件性,下面我從低成本、高效能和高擴充套件性的角度來說說我的一些經驗。
1、HTML靜態化
其實大家都知道,效率最高、消耗最小的就是純靜態化的html頁面,所以我們儘可能使我們的網站上的頁面採用靜態頁面來實現,這個最簡單的方法其實也是最有效的方法。但是對於大量內容並且頻繁更新的網站,我們無法全部手動去挨個實現,於是出現了我們常見的資訊釋出系統CMS,像我們常訪問的各個門戶站點的新聞頻道,甚至他們的其他頻道,都是通過資訊釋出系統來管理和實現的,資訊釋出系統可以實現最簡單的資訊錄入自動生成靜態頁面,還能具備頻道管理、許可權管理、自動抓取等功能,對於一個大型網站來說,擁有一套高效、可管理的CMS是必不可少的。
除了門戶和資訊釋出型別的網站,對於互動性要求很高的社群型別網站來說,儘可能的靜態化也是提高效能的必要手段,將社群內的帖子、文章進行實時的靜態化,有更新的時候再重新靜態化也是大量使用的策略,像Mop的大雜燴就是使用了這樣的策略,網易社群等也是如此。
同時,html靜態化也是某些快取策略使用的手段,對於系統中頻繁使用資料庫查詢但是內容更新很小的應用,可以考慮使用html靜態化來實現,比如論壇中論壇的公用設定資訊,這些資訊目前的主流論壇都可以進行後臺管理並且儲存再資料庫中,這些資訊其實大量被前臺程式呼叫,但是更新頻率很小,可以考慮將這部分內容進行後臺更新的時候進行靜態化,這樣避免了大量的資料庫訪問請求。
2、圖片伺服器分離
大家知道,對於Web伺服器來說,不管是Apache、IIS還是其他容器,圖片是最消耗資源的,於是我們有必要將圖片與頁面進行分離,這是基本上大型網站都會採用的策略,他們都有獨立的圖片伺服器,甚至很多臺圖片伺服器。這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力,並且可以保證系統不會因為圖片問題而崩潰,在應用伺服器和圖片伺服器上,可以進行不同的配置優化,比如apache在配置ContentType的時候可以儘量少支援,儘可能少的LoadModule,保證更高的系統消耗和執行效率。
3、資料庫叢集和庫表雜湊
大型網站都有複雜的應用,這些應用必須使用資料庫,那麼在面對大量訪問的時候,資料庫的瓶頸很快就能顯現出來,這時一臺資料庫將很快無法滿足應用,於是我們需要使用資料庫叢集或者庫表雜湊。
在資料庫叢集方面,很多資料庫都有自己的解決方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是類似的方案,您使用了什麼樣的DB,就參考相應的解決方案來實施即可。
上面提到的資料庫叢集由於在架構、成本、擴張性方面都會受到所採用DB型別的限制,於是我們需要從應用程式的角度來考慮改善系統架構,庫表雜湊是常用並且最有效的解決方案。我們在應用程式中安裝業務和應用或者功能模組將資料庫進行分離,不同的模組對應不同的資料庫或者表,再按照一定的策略對某個頁面或者功能進行更小的資料庫雜湊,比如使用者表,按照使用者ID進行表雜湊,這樣就能夠低成本的提升系統的效能並且有很好的擴充套件性。sohu的論壇就是採用了這樣的架構,將論壇的使用者、設定、帖子等資訊進行資料庫分離,然後對帖子、使用者按照板塊和ID進行雜湊資料庫和表,最終可以在配置檔案中進行簡單的配置便能讓系統隨時增加一臺低成本的資料庫進來補充系統性能。
4、快取
快取一詞搞技術的都接觸過,很多地方用到快取。網站架構和網站開發中的快取也是非常重要。這裡先講述最基本的兩種快取。高階和分散式的快取在後面講述。
架構方面的快取,對Apache比較熟悉的人都能知道Apache提供了自己的快取模組,也可以使用外加的Squid模組進行快取,這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程式開發方面的快取,Linux上提供的Memory Cache是常用的快取介面,可以在web開發中使用,比如用Java開發的時候就可以呼叫MemoryCache對一些資料進行快取和通訊共享,一些大型社群使用了這樣的架構。另外,在使用web語言開發的時候,各種語言基本都有自己的快取模組和方法,PHP有Pear的Cache模組,Java就更多了,.net不是很熟悉,相信也肯定有。
5、映象
映象是大型網站常採用的提高效能和資料安全性的方式,映象的技術可以解決不同網路接入商和地域帶來的使用者訪問速度差異,比如ChinaNet和EduNet之間的差異就促使了很多網站在教育網內搭建映象站點,資料進行定時更新或者實時更新。在映象的細節技術方面,這裡不闡述太深,有很多專業的現成的解決架構和產品可選。也有廉價的通過軟體實現的思路,比如Linux上的rsync等工具。
6、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。
負載均衡技術發展了多年,有很多專業的服務提供商和產品可以選擇,我個人接觸過一些解決方法,其中有兩個架構可以給大家做參考。
硬體四層交換
第四層交換使用第三層和第四層資訊包的報頭資訊,根據應用區間識別業務流,將整個區間段的業務流分配到合適的應用伺服器進行處理。 第四層交換功能就象是虛 IP,指向物理伺服器。它傳輸的業務服從的協議多種多樣,有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理伺服器基礎上,需要複雜的載量平衡演算法。在IP世界,業務型別由終端TCP或UDP埠地址來決定,在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP埠共同決定。
在硬體四層交換產品領域,有一些知名的產品可以選擇,比如Alteon、F5等,這些產品很昂貴,但是物有所值,能夠提供非常優秀的效能和很靈活的管理能力。Yahoo中國當初接近2000臺伺服器使用了三四臺Alteon就搞定了。
軟體四層交換
大家知道了硬體四層交換機的原理後,基於OSI模型來實現的軟體四層交換也就應運而生,這樣的解決方案實現的原理一致,不過效能稍差。但是滿足一定量的壓力還是遊刃有餘的,有人說軟體實現方式其實更靈活,處理能力完全看你配置的熟悉能力。


軟體四層交換我們可以使用Linux上常用的LVS來解決,LVS就是Linux Virtual Server,他提供了基於心跳線heartbeat的實時災難應對解決方案,提高系統的魯棒性,同時提供了靈活的虛擬VIP配置和管理功能,可以同時滿足多種應用需求,這對於分散式的系統來說必不可少。
一個典型的使用負載均衡的策略就是,在軟體或者硬體四層交換的基礎上搭建squid叢集,這種思路在很多大型網站包括搜尋引擎上被採用,這樣的架構低成本、高效能還有很強的擴張性,隨時往架構裡面增減節點都非常容易。這樣的架構我準備空了專門詳細整理一下和大家探討。
對於大型網站來說,前面提到的每個方法可能都會被同時使用到,我這裡介紹得比較淺顯,具體實現過程中很多細節還需要大家慢慢熟悉和體會,有時一個很小的squid引數或者apache引數設定,對於系統性能的影響就會很大,希望大家一起討論,達到拋磚引玉之效。

 ===================================為什麼做映象伺服器?==================================

映象伺服器的主要目的就是為了伺服器之間的負載均衡!
而在我們國家,映象伺服器更多用於解決南北線路不通(網通電信互聯緩慢)的問題!

如何做映象伺服器?

1.基於特定伺服器軟體的負載均衡
這種技術是利用網路協議的重定向功能來實現負載均衡的,例如在Http協議中支援定位指令,接收到這個指令的瀏覽器將自動重定向到該指令指明的另一個URL上。由於和執行服務請求相比,傳送定位指令對Web伺服器的負載要小得多,因此可以根據這個功能來設計一種負載均衡的伺服器。一旦Web伺服器認為自己的負載較大,它就不再直接傳送回瀏覽器請求的網頁,而是送回一個定位指令,讓瀏覽器去伺服器叢集中的其他伺服器上獲得所需要的網頁。在這種方式下,伺服器本身必須支援這種功能,然而具體實現起來卻有很多困難,例如一臺伺服器如何能保證它重定向過的伺服器是比較空閒的,並且不會再次傳送定位指令?定位指令和瀏覽器都沒有這方面的支援能力,這樣很容易在瀏覽器上形成一種死迴圈。因此這種方式實際應用當中並不多見,使用這種方式實現的伺服器叢集軟體也較少。

2.基於DNS的負載均衡
DNS負載均衡技術是最早的負載均衡解決方案,它是通過DNS服務中的隨機名字解析來實現的,在DNS伺服器中,可以為多個不同的地址配置同一個名字,而最終查詢這個名字的客戶機將在解析這個名字時得到其中的一個地址。因此,對於同一個名字,不同的客戶機會得到不同的地址,它們也就訪問不同地址上的Web伺服器,從而達到負載均衡的目的。

這種技術的優點是,實現簡單、實施容易、成本低、適用於大多數TCP/IP應用;但是,其缺點也非常明顯,首先這種方案不是真正意義上的負載均衡,DNS伺服器將Http請求平均地分配到後臺的Web伺服器上,而不考慮每個Web伺服器當前的負載情況;如果後臺的Web伺服器的配置和處理能力不同,最慢的Web伺服器將成為系統的瓶頸,處理能力強的伺服器不能充分發揮作用;其次未考慮容錯,如果後臺的某臺Web伺服器出現故障,DNS伺服器仍然會把DNS請求分配到這臺故障伺服器上,導致不能響應客戶端。最後一點是致命的,有可能造成相當一部分客戶不能享受Web服務,並且由於DNS快取的原因,所造成的後果要持續相當長一段時間(一般DNS的重新整理週期約為24小時)。所以在國外最新的建設中心Web站點方案中,已經很少採用這種方案了。

3.基於四層交換技術的負載均衡
這種技術是在第四層交換機上設定Web服務的虛擬IP地址,這個虛擬IP地址是DNS伺服器中解析到的Web伺服器的IP地址,對客戶端是可見的。當客戶訪問此Web應用時,客戶端的Http請求會先被第四層交換機接收到,它將基於第四層交換技術實時檢測後臺Web伺服器的負載,根據設定的演算法進行快速交換。常見的演算法有輪詢、加權、最少連線、隨機和響應時間等。

4.基於七層交換技術的負載均衡
基於第七層交換的負載均衡技術主要用於實現Web應用的負載平衡和服務質量保證。它與第四層交換機比較起來有許多優勢:第七層交換機不僅能檢查TCP/IP資料包的TCP和UDP埠號,從而轉發給後臺的某臺伺服器來處理,而且能從會話層以上來分析Http請求的URL,根據URL的不同將不同的Http請求交給不同的伺服器來處理(可以具體到某一類檔案,直至某一個檔案),甚至同一個URL請求可以讓多個伺服器來響應以分擔負載(當客戶訪問某一個URL,發起Http請求時,它實際上要與伺服器建立多個會話連線,得到多個物件,例如.txt/.gif/.jpg文件,當這些物件都下載到本地後,才組成一個完整的頁面)。

5.站點映象技術
以上幾種負載均衡技術主要應用於一個站點內的伺服器群,但是由於一個站點接入Internet的頻寬是有限的,因此可以把負載均衡技術開始應用於不同的網路站點之間,這就是站點映象技術,站點映象技術實際上利用了DNS負載均衡技術。

===============================如何做映象伺服器--相關問題==================================
問題1:因為現在電信和網通的原因,很多網通的朋友總是反應速度慢,鬱悶啊,我看到有的站可以自行選擇是網通還是電信的,不知道,這個功能是怎麼是實現的?
答案:
[html]
[/html]

然後在你每個空間的根目錄放 1個較大圖片 1.gif (最好 30 KB左右)

問題2:分別有網通、電信伺服器,想兩個伺服器內都放網站整站程式,我新增檔案的時候是在電信網站上新增,想讓網通網站上也自動同步與電信,我該怎麼做啊

答案:

1。介紹

  現在的網站隨著訪問量的增加,單一伺服器無法承擔巨大的訪問量,有沒有什麼方便快捷的方式解決這個問題呢,答案是”有”!

比如建立伺服器群,進行均衡負載。但是如果要解決像電信網通這樣的互訪問題(中國網民的悲哀),這個解決辦法就無能為力了!

  要解決這個問題最方便快捷的方式就是建立映象網站!由訪問者自己選擇適合自己網路的速度最快的網站!這樣即可以解決線路問題,又可以解決訪問量問題!

2。網站同步的資料分類

  網站資料基本分為兩類:
  一類是檔案,比如HTML,ASP,PHP等網頁檔案,或者RAR,ZIP,RM,AVI等可下載檔案!
  要實現他們的同步很簡單,用FTP同步軟體就可以了!至於哪幾個我會在後面做詳細介紹。

  一類是資料庫資料檔案,比如MySQL,SQL Server等等!
  資料庫同步的方法也很多,最簡單的辦法只是將資料庫目錄同步一下就OK了!
  在後面我也會做詳細講解!

3。網站檔案的同步

  在這裡用到的主要工具就是FTP,網站檔案同步分兩種情況,一種是本地到遠端,一種是遠端到遠端(FXP)!第一種不用說了,第二種遠端到遠端即FXP,支援它的軟體也很多,但是真正適合多網站同步映象的卻不多!

下面我介紹幾個我認為不錯的軟體!

  下面我介紹幾個我認為不錯的軟體!

  1.首先我要推薦的是國產的FTP軟體”網路傳神”,功能非常強大,特別是在網站的同步映象方面,可惜的是,這款非常經典的軟體已經不再更新了,最後更新時間是2003年3月,最後一個版本是3。12!雖然如此還是非常好用的!下面是一段官方的簡介:

  網路傳神完全吸收了Cuteftp和UpdataNow的全部功能,並且增加了其他軟體沒有的多項功能:支援網站互傳;支援網站同步(UPDATA NOW);支援後臺上傳(多執行緒上傳多個檔案);可同時開啟多個站點;多站點計劃上傳功能,支援映象站點;支援巨集操作支援計劃操作;支援檔案高階比較上傳;支援目錄隱藏過濾(為用ForntPage作主頁的朋友帶來福音);伺服器自動識別功能;資源管理器瀏覽方式;可以自定義命令;支援RFC959標準具有更好的穩定性;完備的資訊返回機制及錯誤監控機制完整的中文幫助。

  2.第二款是由ReGet同一開發公司製作的專用於網站同步的軟體”WebSynchronizer”,用這款軟體,你才會體驗到網站同步的方便快捷,簡單容易。最新版本是1。3。62,網上能找到XX的最後版本是1。1版!下面是一段簡介:

  檔案同步化工具 - WebSynchronizer,由知名續傳軟體 ReGet 之軟體出版公司所推出,是網站同步化、檔案映象、檔案備份的絕佳工具,可以執行下列主要工作:1) 本機資料夾及遠端資料夾的同步化;2) 兩臺遠端計算機中的資料夾同步化;3) 兩個本機資料之同步化。

  3.其他還有一些軟體如同步快梭(AutoSyncFTP),也能實現簡單的網站同步,不過,這款軟體非常不穩定,而且2001年就已經停止開發。所以,不用考慮了!還有上次有朋友提到的SiteMirro,由於網上找不到可以用的版本,所以沒有辦法測試 !

相關推薦

大型入口網站架構分析[]

千萬人同時訪問的網站,一般是有很多個數據庫同時工作,說明白一點就是資料庫叢集和併發控制,這樣的網站實時性也是相對的。這些網站都有一些共同的特點: 資料量大,線上人數多,併發請求多,pageview高,響應速度快。總結了一下各個大網站的架構,主要提高效率及穩定性的幾個地方

中國頂級入口網站架構分析1

首先宣告,下面的內容都是我個人根據一些工具形成的猜想。並不保證和現實中各大入口網站所用的架構一摸一樣,不過我認為八九不離十了^_^ 。 整篇文章我想分2個部分來講:第一部分是分析國內2大頂級入口網站首頁和頻道的初步的基本構架。第二部分我將自己做的實驗文件記錄下來。希望每個SA

中國頂級入口網站架構分析 2

前天講了最基本的推測方法,今天稍微深入一些:)1. 難道就根據幾個域名的ip相同就可以證明他們是使用squid的嘛?   當然不是,前面都只是推測。下面才是真正的證實我上面的猜測。先nslookup一把sina的體育頻道。nslookup sports.sina.com.c

大型Web網站架構演變

活動 let isp ali ring 裝載 模式 增加 目的 前言 我們以Java Web為例,來搭建一個簡單的電商系統,看看這個系統可以如何一步步演變。該系統具備的功能: 用戶模塊:用戶註冊和管理 商品模塊:商品展示和管理 交易模塊:創建交易和管理 正文 階段一

讀書筆記:大型分散式網站架構設計與實踐(5)

5 資料分析 隨著網際網路行業的深入發展,資料的量級呈指數級增長。而資料是非常重要的資訊,對資料進行收集和分析是一直在做的事情。當大資料時代來臨之後,相應地也產生了一些新的資料收集、分析的工具。 5.1 日誌收集 對於線上執行的系統來說,每天都會產生大量日誌資訊,需要對這些日

讀書筆記:大型分散式網站架構設計與實踐(1)

原計劃花一年半時間看完十二本書,目錄如下: (1)大型分散式網站架構設計與實踐(陳康賢,電子工業出版社) (2)大型網站系統與Java中介軟體實踐(曾憲傑,電子工業出版社) (3)Java併發程式設計實戰(童雲蘭等譯,機械工業出版社) (4)Java併發

PHP大型入口網站核心技術之MySql優化

大型入口網站核心技術-Mysql優化01 關鍵技術 大型入口網站核心技術-Mysql優化02 表的設計 大型入口網站核心技術-Mysql優化03 慢查詢(一) 大型入口網站核心技術-Mysql優化04 慢查詢(二) 大型入口網站核心技術-Mysql優化05 慢查

讀書筆記:大型分散式網站架構設計與實踐(2)

2 分散式系統基礎設施 一個大型、成熟的分散式系統的背後,往往會涉及眾多的支撐系統,也即所謂的分散式系統的基礎設施,如第一章介紹過的分散式協作及配置管理系統Zookeeper,還有本章將要介紹的分散式快取系統、持久化儲存系統、分散式訊息系統、搜尋引擎,另外還有C

大型入口網站的RBAC使用者許可權管理設計

這是我在網上找的一些設計比較好的RBAC許可權管理不知道,像新浪、搜狐、網易、百度、阿里巴巴、淘寶網的RBAC使用者許可權這一塊,都是這種細顆粒的RBAC設計開發,還是把他們像使用者組、角色組、許可權組、操作組、資源組的表盒資料等都封裝成工具類,持久化曾通過一個數據庫檢視V

大型分散式網站架構設計與實踐pdf

第1章 面向服務的體系架構(SOA) 1   本章主要介紹和解決以下問題,這些也是全書的基礎:   HTTP協議的工作方式與HTTP網路協議棧的結構。   如何實現基於HTTP協議和TCP協議的RPC呼叫,它們之間有何差別,分別適應何種場景。   如何實現服務的動態註冊和路由,以及軟負載均衡的實現。   1

大型入口網站是這樣煉成的》 專案原始碼視訊教程免費下載

大家都知道資料結構和英語,就如同程式設計師的兩條腿一樣;只有不斷的積累,學習,擁有了健壯的“雙腿”才能越走越遠;在資料結構和演算法的領域,不得不承認自己就是一隻菜鳥;需要不斷的學習;在學習過程中,經常會有一些自己的看法,和別人獨特的見解;我都會一一做好筆記,以便進步; 正文:

大型分散式網站架構技術總結

本文是學習大型分散式網站架構的技術總結。對架構一個高效能,高可用,可伸縮,可擴充套件的分散式網站進行了概要性描述,並給出一個架構參考。一部分為讀書筆記,一部分是個人經驗總結。對大型分散式網站架構有很好的參考價值。(如果感覺對大家有幫助,請幫忙點推薦,謝謝。本部落格會逐步推出一系列的關於大型分散式網站架構,設

大型分散式網站架構設計與實踐》

一、面向服務的體系架構SOA 1、RPC:遠端過程呼叫 2、OutputStream中直接寫入一個int型別,會擷取其低8位,丟棄其高24位 3、HTTP請求與響應過程: 1)瀏覽器根據所使用的http協議,解析出url對應的域名 2)通過DNS域名解析,查詢出該域名對應的

大型分散式網站架構設計與實踐1

第1章 面向服務的體系架構(SOA) 分散式應用架構的演變:單一應用架構--->垂直應用架構----->分散式應用架構 1.1 基於TCP協議的RPC 1.1.1 RPC名詞解釋 1、RPC:remote process call,遠端過程呼叫,有RMI、WebService等諸多成熟的方案2、如

大型網站架構之分布式消息隊列()

工作經驗 大型網站 異步處理 消費 min 實現 通知 ima 可能 以下是消息隊列以下的大綱,本文主要介紹消息隊列概述,消息隊列應用場景和消息中間件示例(電商,日誌系統)。 本次分享大綱 消息隊列概述 消息隊列應用場景 消息中間件示例 JMS消息服務 常用

大型網站架構系列:電商網站架構案例(1)(

大型網站架構是一個系列文件,歡迎大家關注。本次分享主題:電商網站架構案例。從電商網站的需求,到單機架構,逐步演變為常用的,可供參考的分散式架構的原型。除具備功能需求外,還具備一定的高效能,高可用,可伸縮,可擴充套件等非功能質量需求(架構目標)。 根據實際需要,進行改造,擴充套件,支援千萬PV,是沒問題的。

大型網站架構系列:訊息佇列(二)(

本文是大型網站架構系列:訊息佇列(二),主要分享JMS訊息服務,常用訊息中介軟體(Active MQ,Rabbit MQ,Zero MQ,Kafka)。【第二篇的內容大部分為網路資源的整理和彙總,供大家學習總結使用,最後有文章來源】 本次分享大綱 訊息佇列概述(見第一篇:大型網站架構系列:分散式訊息

大型網站架構系列:分散式訊息佇列(一)(

以下是訊息佇列以下的大綱,本文主要介紹訊息佇列概述,訊息佇列應用場景和訊息中介軟體示例(電商,日誌系統)。 本次分享大綱 訊息佇列概述 訊息佇列應用場景 訊息中介軟體示例 JMS訊息服務(見第二篇:大型網站架構系列:分散式訊息佇列(二)) 常用訊息佇列(見第二篇:大型網站架構系列:分

大型網站架構系列:20本技術書籍推薦(

學習是技術人員成長的基礎,本次分享20本技術方面的書籍,這些書不是每一本都是經典,但是每一本都有其特點。以下20本大部分本人都看過,因此推薦給大家。(本次推薦的20本只是一個參考,比如像Head First,Java程式設計思想等經典書籍是大家都知道,因此不在推薦之列) 本次分享大綱 大型網站架構系

瘋狂程式碼 大型網站架構系列 未完待續

分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!