大型網站架構演進(4)使用應用伺服器叢集
使用應用伺服器叢集是解決高併發的常用手段,當一臺應用伺服器的處理能力不足時,不要企圖更換配置更高的伺服器,對於大型網站而言,不管多麼強大的伺服器,都滿足不了持續增長的業務需求,在這種情況下,更好的做法是增加一臺應用伺服器去分擔原來伺服器的壓力。因為這樣使得系統的可擴充套件和可伸縮性更好。
使用應用伺服器叢集
架構如下圖:
總結:
使用應用伺服器集群后,應用伺服器這一層的高併發問題就解決了,但是高併發的壓力就轉移到資料庫了,所以後面要繼續優化架構去解決資料庫的壓力問題,這個階段應用層理論上併發數是不受限制的,因為隨時可以擴充應用伺服器。
同時使用應用伺服器叢集,會帶來一個典型的問題:Session會話問題,如何保證接下來的每次請求都落在同一個伺服器上。常用的有兩種解決方案:
1,固定Nginx的路由,一般使用Hash源地址雜湊法,將來自同一IP的請求,都轉發到相同伺服器處理。參考:http://www.cnblogs.com/itfly8/p/5043452.html
2,Session集中儲存,使用redis實現session共享。參考:http://www.cnblogs.com/yanweidie/p/4719692.html
相關推薦
大型網站架構演進(4)使用應用伺服器叢集
原文: 大型網站架構演進(4)使用應用伺服器叢集 使用應用伺服器叢集是解決高併發的常用手段,當一臺應用伺服器的處理能力不足時,不要企圖更換配置更高的伺服器,對於大型網站而言,不管多麼強大的伺服器,都滿足不了持續增長的業務需求,在這種情況下,更好的做法是增加一臺應用伺服器去分擔原來伺服器的壓力
大型網站架構演進(4)使用應用服務器集群
gin 常用 die 這一 html 散列 str 系統 com 原文:大型網站架構演進(4)使用應用服務器集群 使用應用服務器集群是解決高並發的常用手段,當一臺應用服務器的處理能力不足時,不要企圖更換配置更高的服務器,對於大型網站而言,不管多麽強大的服務器,都滿足不了
大型網站架構演進(2)資料庫與應用伺服器分離
原文: 大型網站架構演進(2)資料庫與應用伺服器分離 隨著使用者量和併發數的增加,單臺伺服器出現了效能問題,此時必須要將應用程式和資料庫分離,分離後整個網站變成三臺伺服器了:應用伺服器(或稱web伺服器),資料庫伺服器和檔案伺服器。這三臺伺服器對伺服器的配置要求是不一樣的,應用伺服器需要處理大量的業務邏
大型網站架構演進(2)數據庫與應用服務器分離
並發 www ref 使用 大型 spa 和數 logs 三臺 原文:大型網站架構演進(2)數據庫與應用服務器分離 隨著用戶量和並發數的增加,單臺服務器出現了性能問題,此時必須要將應用程序和數據庫分離,分離後整個網站變成三臺服務器了:應用服務器(或稱web服務器),數據庫
程式架構探討—005 應用伺服器叢集的伸縮性之反向代理負載均衡
利用反向代理也可以做負載均衡。如下圖所示, 反向代理伺服器處於WEB伺服器的前面,既可以提供反向代理,也可以管理一組web伺服器,將請求根據負載均衡演算法轉發到不同的web伺服器上。web伺服器處理完
大型網站架構演進的五大階段盤點
一個創業公司起步時很可能就兩臺機器,一臺Web 伺服器、一臺資料庫伺服器,在一個應用系統中集成了
大型網站架構演進(3)使用緩存改善網站性能
大型網站 限制 bubuko .com ack 兩種 png 我們 項目開發 原文:大型網站架構演進(3)使用緩存改善網站性能 網站的訪問也是遵循二八定律:80%的業務訪問集中在20%的數據上,如果我們把這20%的數據做緩存,是不是可以減輕數據庫的訪問壓力呢?在項目開發過
大型網站架構演進(5)數據庫讀寫分離
這一 流數據 tar share 讀數 應用 庫服務器 兩個 .com 原文:大型網站架構演進(5)數據庫讀寫分離 在使用緩存後,使大部分的數據讀操作訪問都可以不通過數據庫就能完成,但是仍有一部分讀操作(包括未命中緩存的,和緩存過期的)和全部的寫操作需要訪問數據庫,當網站
大型網站架構演進(1)單機網站
原文: 大型網站架構演進(1)單機網站 初始階段的網站一般訪問量都很小(QPS<500),此時只需要一臺伺服器就足夠,應用程式,資料庫和檔案都放在這一臺伺服器上。如果是.net的話,通常作業系統使用windows server,應用程式開發使用asp.net,然後應用程式部署在IIS上,資料庫使用
大型網站架構演進(3)使用快取改善網站效能
原文: 大型網站架構演進(3)使用快取改善網站效能 網站的訪問也是遵循二八定律:80%的業務訪問集中在20%的資料上,如果我們把這20%的資料做快取,是不是可以減輕資料庫的訪問壓力呢?在專案開發過程中,我們通常將一些基礎資訊快取起來,比如商旅系統中的國家,城市,航空公司,機場和航站樓資訊。 使用快取改
大型網站架構演進(9)服務化
原文: 大型網站架構演進(9)服務化 隨著業務越拆越小,而且各個應用又是獨立部署和維護的,這樣的架構存在以下問題: 1,資料庫連線數的問題,如果各個應用都連線現有資料庫,當使用叢集和併發訪問量大的情形下,就會導致資料庫連線數超過限制。當然,如果各個應用都有自己的資料庫,則不存在這個問題。 2,程式碼
大型網站架構演進(7)資料庫拆分
原文: 大型網站架構演進(7)資料庫拆分 能過資料庫的讀寫分離和使用NoSQL,以及搜尋引擎後,能夠降低主庫的壓力,解決資料儲存方面的問題,不過隨著業務的繼續發展,我們的資料庫主庫還是會遇到效能瓶頸,所以為了減小資料庫主庫的壓力,我們有資料庫垂直拆分和水平拆分兩種方式。 資料庫拆分 資料庫拆分有兩種
大型網站架構演進(8)業務拆分
原文: 大型網站架構演進(8)業務拆分 大型網站為了應對日益複雜的業務需求,通過使用分而治之的手段將整個網站的業務分成不同的產品線,然後交給不同的開發團隊負責。這樣一方面方便應用的擴充套件和維護,同時不同的應用對應不同的資料庫,也減小了原來所有業務資料都在一個數據庫的壓力。 業務拆分 原來一個網站拆
大型網站架構演進(6)使用NoSQL和搜尋引擎
原文: 大型網站架構演進(6)使用NoSQL和搜尋引擎 隨著網站業務越來越複雜,對資料儲存和檢索的需求也越來越複雜,網站需要採用一些非關係型資料庫技術(即NoSQL)和非資料庫查詢技術如搜尋引擎。NoSQL資料庫一般使用MongoDb,搜尋引擎一般使用ElasticSearch,最好可以研究ELK整套解
大型網站架構演進(5)資料庫讀寫分離
原文: 大型網站架構演進(5)資料庫讀寫分離 在使用快取後,使大部分的資料讀操作訪問都可以不通過資料庫就能完成,但是仍有一部分讀操作(包括未命中快取的,和快取過期的)和全部的寫操作需要訪問資料庫,當網站的訪問量繼續增加後,資料庫會因為負載壓力過高導致成為網站的效能瓶頸。 目前大部分的主流資料庫都提
大型網站架構演進
1. 初始階段的網站架構一般來講,大型網站都是從小型網站發展而來,一開始的架構都比較簡單,隨著業務複雜和使用者量的激增,才開始做很多架構上的改進。當它還是小型網站的時候,沒有太多訪客,一般來講只需要一臺伺服器就夠了,這時應用程式、資料庫、檔案等所有資源都在一臺伺服器上,網站架構如下圖所示: &
大型網站架構的技術演進
網站初期架構 幾乎所有的大型網站都是從小型網站發展而來的,網站架構也一樣,是從小型網站技術架構逐步演化而來的。小型網站最開始沒有太多訪問量,可能只需要一臺伺服器就能夠應付了,這時的網站架構如下圖所示。 即將應用程式、資料庫、檔案等所有的資源都在同一臺伺服器上。很多
關於大型網站技術演進的思考(四)--儲存的瓶頸(4)
如果資料庫需要進行水平拆分,這其實是一件很開心的事情,因為它代表公司的業務正在迅猛的增長,對於開發人員而言那就是有不盡的專案可以做,雖然會感覺很忙,但是人過的充實,心裡也踏實。 資料庫水平拆分簡單說來就是先將原資料庫裡的一張表在做垂直拆分出來放置在單獨的資料庫和單獨的表裡後更進一步的把本來是一個整體
關於大型網站技術演進的思考(十二)--網站靜態化處理—快取(4)
上篇我補充了下SSI的知識,SSI是一個十分常見的技術,記得多年前我看到很多入口網站頁面的字尾是.shtml,那麼這就說明很多入口網站都曾經使用過SSI技術,其實現在搜狐網站也還在用shtml,如下圖所示: 由此可見SSI在網際網路的應用還是非常廣泛的。其實網際網路很多網頁如果我們按照動靜分離
關於大型網站技術演進的思考(四):儲存的瓶頸(4)
如果資料庫需要進行水平拆分,這其實是一件很開心的事情,因為它代表公司的業務正在迅猛的增長,對於開發人員而言那就是有不盡的專案可以做,雖然會感覺很忙,但是人過的充實,心裡也踏實。 資料庫水平拆分簡單說來就是先將原資料庫裡的一張表在做垂直拆分出來放置在單獨的資料庫和單