大型網站緩存技術

① 如何為大型網站提速頁面靜態化緩存技術memcachemysql優化

1.首先明確是不是一定要上緩存，當前架構的瓶頸在哪裡，若瓶頸真是資料庫操作上，再繼續往下看。 2.明確memcached和redis的區別，到底要使用哪個。前者終究是個緩存，不可能永久保存數據（LRU機制），支持分布式，後者除了緩存的同時也支持把數...

② 大型網站資料庫系統，怎麼連接那麼多並發數量的

按我個人經驗有以下幾種方法：1.在連接資料庫的時候可以優化，使用連接池。主要就是不要頻繁地創建，銷毀連接。這是很費時的一個操作。因此，使用連接池來代替普通的建立連接操作，能提高並發度。2. 使用緩存技術。並不是每次都需要去資料庫裡面查詢的，我們其實可以把前一次的查詢結果放在內存里，如果下一次用戶來查詢相同的內容，直接內存返回即可，不需要再次查詢。這樣可以大大降低查詢頻率。3.使用分布式技術，將資料庫分布在多台伺服器上，同時也將用戶分區（如根據用戶ID的哈希值分區），不同的伺服器負責不同用戶群，這樣就能大大減少單台伺服器的負載，使得整體的吞吐量提高。這幾樣技術可以同時使用，你的並發數量將獲得非常大的提高。

③ 常用的緩存技術

第一章 常用的緩存技術
1、常見的兩種緩存

本地緩存：不需要序列化，速度快，緩存的數量與大小受限於本機內存
分布式緩存：需要序列化，速度相較於本地緩存較慢，但是理論上緩存的數量與大小無限（因為緩存機器可以不斷擴展）
2、本地緩存

Google guava cache：當下最好用的本地緩存
Ehcache：spring默認集成的一個緩存，以spring cache的底層緩存實現類形式去操作緩存的話，非常方便，但是欠缺靈活，如果想要靈活使用，還是要單獨使用Ehcache
Oscache：最經典簡單的頁面緩存
3、分布式緩存

memcached：分布式緩存的標配
Redis：新一代的分布式緩存，有替代memcached的趨勢
3.1、memcached

經典的一致性hash演算法
基於slab的內存模型有效防止內存碎片的產生（但同時也需要估計好啟動參數，否則會浪費很多的內存）
集群中機器之間互不通信（相較於Jboss cache等集群中機器之間的相互通信的緩存，速度更快<--因為少了同步更新緩存的開銷，且更適合於大型分布式系統中使用）
使用方便（這一點是相較於Redis在構建客戶端的時候而言的，盡管redis的使用也不困難）
很專一（專做緩存，這一點也是相較於Redis而言的）
3.2、Redis

可以存儲復雜的數據結構（5種）
strings-->即簡單的key-value，就是memcached可以存儲的唯一的一種形式，接下來的四種是memcached不能直接存儲的四種格式（當然理論上可以先將下面的一些數據結構中的東西封裝成對象，然後存入memcached，但是不推薦將大對象存入memcached，因為memcached的單一value的最大存儲為1M，可能即使採用了壓縮演算法也不夠，即使夠，可能存取的效率也不高，而redis的value最大為1G）
hashs-->看做hashTable
lists-->看做LinkedList
sets-->看做hashSet，事實上底層是一個hashTable
sorted sets-->底層是一個skipList
有兩種方式可以對緩存數據進行持久化
RDB
AOF
事件調度
發布訂閱等
4、集成緩存

專指spring cache，spring cache自己繼承了ehcache作為了緩存的實現類，我們也可以使用guava cache、memcached、redis自己來實現spring cache的底層。當然，spring cache可以根據實現類來將緩存存在本地還是存在遠程機器上。

5、頁面緩存

在使用jsp的時候，我們會將一些復雜的頁面使用Oscache進行頁面緩存，使用非常簡單，就是幾個標簽的事兒；但是，現在一般的企業，前台都會使用velocity、freemaker這兩種模板引擎，本身速度就已經很快了，頁面緩存使用的也就很少了。

總結：

在實際生產中，我們通常會使用guava cache做本地緩存+redis做分布式緩存+spring cache就集成緩存（底層使用redis來實現）的形式
guava cache使用在更快的獲取緩存數據，同時緩存的數據量並不大的情況
spring cache集成緩存是為了簡單便捷的去使用緩存（以註解的方式即可），使用redis做其實現類是為了可以存更多的數據在機器上
redis緩存單獨使用是為了彌補spring cache集成緩存的不靈活
就我個人而言，如果需要使用分布式緩存，那麼首先redis是必選的，因為在實際開發中，我們會緩存各種各樣的數據類型，在使用了redis的同時，memcached就完全可以舍棄了，但是現在還有很多公司在同時使用memcached和redis兩種緩存。

④ 對於大流量的網站,您採用什麼樣的方法來解決訪問量問題

01、|確認伺服器硬體是否足夠支持當前的流量
02、優化資料庫訪問 [緩存技術就是另一個解決方案，就是將動態數據存儲到緩存文件中，動態網頁直接調用這些文件，而不必再訪問
資料庫]
03、禁止外部的盜鏈。
04、優化前後端代碼，不能有冗餘代碼；
05、控制打文件的下載
06、使用不同主機分流主要流量 [分布式]
07、使用流量軟體統計軟體

⑤ php應用中常用的9大緩存技術

一、全頁面靜態化緩存

也就是將頁面全部生成html靜態頁面，用戶訪問時直接訪問的靜態頁面，而不會去走php伺服器解析的流程。此種方式，在CMS系統中比較常見，比如dedecms；

一種比較常用的實現方式是用輸出緩存：

Ob_start()******要運行的代碼*******$content=Ob_get_contents();****將緩存內容寫入html文件*****Ob_end_clean();

二、數據緩存

顧名思義，就是緩存數據的一種方式；比如，商城中的某個商品信息，當用商品id去請求時，就會得出包括店鋪信息、商品信息等數據，此時就可以將這些數據緩存到一個php文件中，文件名包含商品id來建一個唯一標示；下一次有人想查看這個商品時，首先就直接調這個文件裡面的信息，而不用再去資料庫查詢；其實緩存文件中緩存的就是一個php數組之類；

Ecmall商城系統裡面就用了這種方式；

三、查詢緩存

其實這跟數據緩存是一個思路，就是根據查詢語句來緩存；將查詢得到的數據緩存在一個文件中，下次遇到相同的查詢時，就直接先從這個文件裡面調數據，不會再去查資料庫；但此處的緩存文件名可能就需要以查詢語句為基點來建立唯一標示；

按時間變更進行緩存

就是對於緩存文件您需要設一個有效時間，在這個有效時間內，相同的訪問才會先取緩存文件的內容，但是超過設定的緩存時間，就需要重新從資料庫中獲取數據，並生產最新的緩存文件；比如，我將我們商城的首頁就是設置2個小時更新一次。

四、頁面部分緩存

該種方式，是將一個頁面中不經常變的部分進行靜態緩存，而經常變化的塊不緩存，最後組裝在一起顯示；可以使用類似於ob_get_contents的方式實現，也可以利用類似ESI之類的頁面片段緩存策略，使其用來做動態頁面中相對靜態的片段部分的緩存。

該種方式可以用於如商城中的商品頁；

五、Opcode緩存

首先php代碼被解析為Tokens，然後再編譯為Opcode碼，最後執行Opcode碼，返回結果；所以，對於相同的php文件，第一次運行時可以緩存其Opcode碼，下次再執行這個頁面時，直接會去找到緩存下的opcode碼，直接執行最後一步，而不再需要中間的步驟了。

比較知名的是XCache、TurckMMCache、PHPAccelerator等。

六、按內容變更進行緩存

這個也並非獨立的緩存技術，需結合著用；就是當資料庫內容被修改時，即刻更新緩存文件；

比如，一個人流量很大的商城，商品很多，商品表必然比較大，這表的壓力也比較重；我們就可以對商品顯示頁進行頁面緩存；

當商家在後台修改這個商品的信息時，點擊保存，我們同時就更新緩存文件；那麼，買家訪問這個商品信息時，實際問的是一個靜態頁面，而不需要再去訪問資料庫；

試想，如果對商品頁不緩存，那麼每次訪問一個商品就要去資料庫查一次，如果有10萬人在線瀏覽商品，那伺服器壓力就大了；

七、內存式緩存

提到這個，可能大家想到的首先就是Memcached；memcached是高性能的分布式內存緩存伺服器。一般的使用目的是，通過緩存資料庫查詢結果，減少資料庫訪問次數，以提高動態Web應用的速度、提高可擴展性。

它就是將需要緩存的信息，緩存到系統內存中，需要獲取信息時，直接到內存中取；比較常用的方式就是key_>value方式；

connect($memcachehost,$memcacheport)ordie("Couldnotconnect");$memcache->set('key','緩存的內容');$get=$memcache->get($key);//獲取信息?>

八、apache緩存模塊

apache安裝完以後，是不允許被cache的。雲南IT培訓http://www.kmbdqn.cn/認為如果外接了cache或squid伺服器要求進行web加速的話，就需要在htttpd.conf里進行設置，當然前提是在安裝apache的時候要激活mod_cache的模塊。

⑥ 大規模，高並發網站開發經驗都有哪些

高並發量網站解決方案

一個小型的網站，可以使用最簡單的html靜態頁面就實現了，配合一些圖片達到美化效果，所有的頁面均存放在一個目錄下，這樣的網站對系統架構、性能的要求都很簡單。隨著互聯網業務的不斷豐富，網站相關的技術經過這些年的發展，已經細分到很細的方方面面，尤其對於大型網站來說，所採用的技術更是涉及面非常廣，從硬體到軟體、編程語言、資料庫、WebServer、防火牆等各個領域都有了很高的要求，已經不是原來簡單的html靜態網站所能比擬的。

大型網站，比如門戶網站，在面對大量用戶訪問、高並發請求方面，基本的解決方案集中在這樣幾個環節：使用高性能的伺服器、高性能的資料庫、高效率的編程語言、還有高性能的Web容器。這幾個解決思路在一定程度上意味著更大的投入。

1、HTML靜態化

其實大家都知道，效率最高、消耗最小的就是純靜態化的html頁面，所以我們盡可能使我們的網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。但是對於大量內容並且頻繁更新的網站，我們無法全部手動去挨個實現，於是出現了我們常見的信息發布系統CMS，像我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發布系統來管理和實現的，信息發布系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管理、許可權管理、自動抓取等功能，對於一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。

除了門戶和信息發布類型的網站，對於交互性要求很高的社區類型網站來說，盡可能的靜態化也是提高性能的必要手段，將社區內的帖子、文章進行實時的靜態化、有更新的時候再重新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。

同時，html靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用資料庫查詢但是內容更新很小的應用，可以考慮使用html靜態化來實現。比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行後台管理並且存儲在資料庫中，這些信息其實大量被前台程序調用，但是更新頻率很小，可以考慮將這部分內容進行後台更新的時候進行靜態化，這樣避免了大量的資料庫訪問請求。

2、圖片伺服器分離

大家知道，對於Web伺服器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，於是我們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的、甚至很多台的圖片伺服器。這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力，並且可以保證系統不會因為圖片問題而崩潰。

在應用伺服器和圖片伺服器上，可以進行不同的配置優化，比如apache在配置ContentType的時候可以盡量少支持、盡可能少的LoadMole，保證更高的系統消耗和執行效率。

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和ENet之間的差異就促使了很多網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這里不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟體實現的思路，比如Linux上的rsync等工具。

6、負載均衡

負載均衡將是大型網站解決高負荷訪問和大量並發請求採用的高端解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。

（1）、硬體四層交換

第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用伺服器進行處理。

第四層交換功能就像是虛IP，指向物理伺服器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理伺服器基礎上，需要復雜的載量平衡演算法。在IP世界，業務類型由終端TCP或UDP埠地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP埠共同決定。

在硬體四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。「Yahoo中國」當初接近2000台伺服器，只使用了三、四台Alteon就搞定了。

(2)、軟體四層交換

大家知道了硬體四層交換機的原理後，基於OSI模型來實現的軟體四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。但是滿足一定量的壓力還是游刃有餘的，有人說軟體實現方式其實更靈活，處理能力完全看你配置的熟悉能力。

軟體四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux Virtual Server，他提供了基於心跳線heartbeat的實時災難應對解決方案，提高系統的強壯性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應用需求，這對於分布式的系統來說必不可少。

一個典型的使用負載均衡的策略就是，在軟體或者硬體四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裡面增減節點都非常容易。

對於大型網站來說，前面提到的每個方法可能都會被同時使用到，這里介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會。有時一個很小的squid參數或者apache參數設置，對於系統性能的影響就會很大。

最新：CDN加速技術

CDN的全稱是內容分發網路。其目的是通過在現有的Internet中增加一層新的網路架構，將網站的內容發布到最接近用戶的網路「邊緣」，使用戶可以就近取得所需的內容，提高用戶訪問網站的響應速度。

CDN有別於鏡像，因為它比鏡像更智能，或者可以做這樣一個比喻：CDN=更智能的鏡像+緩存+流量導流。因而，CDN可以明顯提高Internet網路中信息流動的效率。從技術上全面解決由於網路帶寬小、用戶訪問量大、網點分布不均等問題，提高用戶訪問網站的響應速度。

CDN的類型特點

CDN的實現分為三類：鏡像、高速緩存、專線。

鏡像站點（Mirror Site），是最常見的，它讓內容直接發布，適用於靜態和准動態的數據同步。但是購買和維護新伺服器的費用較高，還必須在各個地區設置鏡像伺服器，配備專業技術人員進行管理與維護。對於大型網站來說，更新所用的帶寬成本也大大提高了。

高速緩存，成本較低，適用於靜態內容。Internet的統計表明，超過80%的用戶經常訪問的是20%的網站的內容，在這個規律下，緩存伺服器可以處理大部分客戶的靜態請求，而原始的伺服器只需處理約20%左右的非緩存請求和動態請求，於是大大加快了客戶請求的響應時間，並降低了原始伺服器的負載。

CDN服務一般會在全國范圍內的關鍵節點上放置緩存伺服器。

專線，讓用戶直接訪問數據源，可以實現數據的動態同步。

CDN的實例

舉個例子來說，當某用戶訪問網站時，網站會利用全球負載均衡技術，將用戶的訪問指向到距離用戶最近的正常工作的緩存伺服器上，直接響應用戶的請求。

當用戶訪問已經使用了CDN服務的網站時，其解析過程與傳統解析方式的最大區別就在於網站的授權域名伺服器不是以傳統的輪詢方式來響應本地DNS的解析請求，而是充分考慮用戶發起請求的地點和當時網路的情況，來決定把用戶的請求定向到離用戶最近同時負載相對較輕的節點緩存伺服器上。

通過用戶定位演算法和伺服器健康檢測演算法綜合後的數據，可以將用戶的請求就近定向到分布在網路「邊緣」的緩存伺服器上，保證用戶的訪問能得到更及時可靠的響應。

由於大量的用戶訪問都由分布在網路邊緣的CDN節點緩存伺服器直接響應了，這就不僅提高了用戶的訪問質量，同時有效地降低了源伺服器的負載壓力。

⑦ (java WEB)誰能告訴我在大型購物網站中使用什麼技術實現購物車的,在線等....只有50分了,一定給

目前購物車的實現主要是通過cookie、session或結合資料庫的方式。下面分析一下它們的機制及作用。
1. cookie
cookie是由伺服器產生，存儲在客戶端的一段信息。它定義了一種Web伺服器在客戶端存儲和返回信息的機制，cookie文件它包含域、路徑、生存期、和由伺服器設置的變數值等內容。當用戶以後訪問同一個Web伺服器時，瀏覽器會把cookie原樣發送給伺服器。通過讓伺服器讀取原先保存到客戶端的信息，網站能夠為瀏覽者提供一系列的方便，例如在線交易過程中標識用戶身份、安全要求不高的場合避免用戶重復輸入名字和密碼、門戶網站的主頁定製、有針對性地投放廣告等等。利用cookie的特性，大大擴展了WEB應用程序的功能，不僅可以建立伺服器與客戶機的聯系，因為cookie可以由伺服器定製，因此還可以將購物信息生成cookie值存放在客戶端，從而實現購物車的功能。用基於cookie的方式實現伺服器與瀏覽器之間的會話或購物車，有以下特點：
n cookie存儲在客戶端，且佔用很少的資源，瀏覽器允許存放300個cookie，每個cookie的大小為4KB，足以滿足購物車的要求，同時也減輕了伺服器的負荷；
n cookie為瀏覽器所內置，使用方便。即使用戶不小心關閉了瀏覽器窗口，只要在cookie定義的有效期內，購物車中的信息也不會丟失；
n cookie不是可執行文件，所以不會以任何方式執行，因此也不會帶來病毒或攻擊用戶的系統；
n 基於cookie的購物車要求用戶瀏覽器必須支持並設置為啟用cookie，否則購物車則失效；
n 存在著關於cookie侵犯訪問者隱私權的爭論，因此有些用戶會禁止本機的cookie功能。
2. session
session是實現購物車的另一種方法。session提供了可以保存和跟蹤用戶的狀態信息的功能，使當前用戶在session中定義的變數和對象能在頁面之間共享，但是不能為應用中其他用戶所訪問，它與cookie最重大的區別是，session將用戶在會話期間的私有信息存儲在伺服器端，提高了安全性。在伺服器生成session後，客戶端會生成一個sessionid識別號保存在客戶端，以保持和伺服器的同步。這個sessionid是只讀的，如果客戶端禁止cookie功能，session會通過在URL中附加參數，或隱含在表單中提交等其他方式在頁面間傳送。因此利用session實施對用戶的管理則更為安全、有效。
同樣，利用session也能實現購物車，這種方式的特點是：
n session用新的機制保持與客戶端的同步，不依賴於客戶端設置；
n 與cookie相比，session是存儲在伺服器端的信息，因此顯得更為安全，因此可將身份標示，購物等信息存儲在session中；
n session會佔用伺服器資源，加大伺服器端的負載，尤其當並發用戶很多時，會生成大量的session，影響伺服器的性能；
n 因為session存儲的信息更敏感，而且是以文件形式保存在伺服器中，因此仍然存在著安全隱患。
3. 結合資料庫的方式
這也是目前較普遍的模式，在這種方式中，資料庫承擔著存儲購物信息的作用，session或cookie則用來跟蹤用戶。這種方式具有以下特點：
n 資料庫與cookie分別負責記錄數據和維持會話，能發揮各自的優勢，使安全性和伺服器性能都得到了提高；
n 每一個購物的行為，都要直接建立與資料庫的連接，直至對表的操作完成後，連接才釋放。當並發用戶很多時，會影響資料庫的性能，因此，這對資料庫的性能提出了更高的要求；
n 使cookie維持會話有賴客戶端的支持。
各種方式的選擇：
雖然cookie可用來實現購物車，但必須獲得瀏覽器的支持，再加上它是存儲在客戶端的信息，極易被獲取，所以這也限制了它存儲更多，更重要的信息。所以一般cookie只用來維持與伺服器的會話，例如國內最大的當當網路書店就是用cookie保持與客戶的聯系，但是這種方式最大的缺點是如果客戶端不支持cookie就會使購物車失效。
Session 能很好地與交易雙方保持會話，可以忽視客戶端的設置。在購物車技術中得到了廣泛的應用。但session的文件屬性使其仍然留有安全隱患。
結合資料庫的方式雖然在一定程度上解決了上述的問題，但從上面的例子可以看出：在這種購物流程中涉及到對資料庫表的頻繁操作，尤其是用戶每選購一次商品，都要與資料庫進行連接，當用戶很多的時候就加大了伺服器與資料庫的負荷。

PS：以上是參考網上資料，對購物車實現的分析！
結合你自身的web的訪問及部署情況，可考慮優先或結合使用。
如果使用資料庫存儲，一般考慮使用緩存技術去解決性能問題。

有問題再追問，good luck！~

⑧ 請問：大型門戶網站系統系統性能優化技術的方法

大型門戶網站優化有很多種方法的？比較頁面靜態化，還有緩存技術。具體可查看這里
http://www.diandian315.com/thread-32-1-1.html

⑨ 如何搭建大型網站系統

程序員們都希望能通過自己的努力學習，技術提升，拿到更好的收入，技術提升和高收入雖然不是輕易就能實現的，但總是有章可循。

一個成熟的大型網站（如淘寶、京東等）的系統架構並不是開始設計就具備完整的高性能、高可用、安全等特性，它總是隨著用戶量的增加，業務功能的擴展逐漸演變完善的，在這個過程中，開發模式、技術架構、設計思想也發生了很大的變化，就連技術人員也從幾個人發展到一個部門甚至一條產品線。所以成熟的系統架構是隨業務擴展而完善出來的，並不是一蹴而就；不同業務特徵的系統，會有各自的側重點，例如淘寶，要解決海量的商品信息的搜索、下單、支付，例如騰訊，要解決數億的用戶實時消息傳輸，網路它要處理海量的搜索請求，他們都有各自的業務特性，系統架構也有所不同。盡管如此我們也可以從這些不同的網站背景下，找出其中共用的技術，這些技術和手段可以廣泛運行在大型網站系統的架構中，下面就通過介紹大型網站系統的演化過程，來認識這些技術和手段。

一、最開始的網站架構

最初的架構，應用程序、資料庫、文件都部署在一台伺服器上，如圖：

二、應用、數據、文件分離

隨著業務的擴展，一台伺服器已經不能滿足性能需求，故將應用程序、資料庫、文件各自部署在獨立的伺服器上，並且根據伺服器的用途配置不同的硬體，達到最佳的性能效果。

三、利用緩存改善網站性能

在硬體優化性能的同時，同時也通過軟體進行性能優化，在大部分的網站系統中，都會利用緩存技術改善系統的性能，使用緩存主要源於熱點數據的存在，大部分網站訪問都遵循28原則（即80%的訪問請求，最終落在20%的數據上），所以我們可以對熱點數據進行緩存，減少這些數據的訪問路徑，提高用戶體驗。

緩存實現常見的方式是本地緩存、分布式緩存。當然還有CDN、反向代理等，這個後面再講。本地緩存，顧名思義是將數據緩存在應用伺服器本地，可以存在內存中，也可以存在文件，OSCache就是常用的本地緩存組件。本地緩存的特點是速度快，但因為本地空間有限所以緩存數據量也有限。分布式緩存的特點是，可以緩存海量的數據，並且擴展非常容易，在門戶類網站中常常被使用，速度按理沒有本地緩存快，常用的分布式緩存是Memcached、Redis。

四、使用集群改善應用伺服器性能

應用伺服器作為網站的入口，會承擔大量的請求，我們往往通過應用伺服器集群來分擔請求數。應用伺服器前面部署負載均衡伺服器調度用戶請求，根據分發策略將請求分發到多個應用伺服器節點。

常用的負載均衡技術硬體的有F5，價格比較貴，軟體的有LVS、Nginx、HAProxy。LVS是四層負載均衡，根據目標地址和埠選擇內部伺服器，Nginx是七層負載均衡和HAProxy支持四層、七層負載均衡，可以根據報文內容選擇內部伺服器，因此LVS分發路徑優於Nginx和HAProxy，性能要高些，而Nginx和HAProxy則更具配置性，如可以用來做動靜分離（根據請求報文特徵，選擇靜態資源伺服器還是應用伺服器）。

五、資料庫讀寫分離和分庫分表

隨著用戶量的增加，資料庫成為最大的瓶頸，改善資料庫性能常用的手段是進行讀寫分離以及分表，讀寫分離顧名思義就是將資料庫分為讀庫和寫庫，通過主備功能實現數據同步。分庫分表則分為水平切分和垂直切分，水平切換則是對一個資料庫特大的表進行拆分，例如用戶表。垂直切分則是根據業務不同來切換，如用戶業務、商品業務相關的表放在不同的資料庫中。

六、使用CDN和反向代理提高網站性能

假如我們的伺服器都部署在成都的機房，對於四川的用戶來說訪問是較快的，而對於北京的用戶訪問是較慢的，這是由於四川和北京分別屬於電信和聯通的不同發達地區，北京用戶訪問需要通過互聯路由器經過較長的路徑才能訪問到成都的伺服器，返迴路徑也一樣，所以數據傳輸時間比較長。對於這種情況，常常使用CDN解決，CDN將數據內容緩存到運營商的機房，用戶訪問時先從最近的運營商獲取數據，這樣大大減少了網路訪問的路徑。比較專業的CDN運營商有藍汛、網宿。

而反向代理，則是部署在網站的機房，當用戶請求達到時首先訪問反向代理伺服器，反向代理伺服器將緩存的數據返回給用戶，如果沒有沒有緩存數據才會繼續走應用伺服器獲取，也減少了獲取數據的成本。反向代理有Squid，Nginx。

七、使用分布式文件系統

用戶一天天增加，業務量越來越大，產生的文件越來越多，單台的文件伺服器已經不能滿足需求。需要分布式的文件系統支撐。常用的分布式文件系統有NFS。

八、使用NoSql和搜索引擎

對於海量數據的查詢，我們使用nosql資料庫加上搜索引擎可以達到更好的性能。並不是所有的數據都要放在關系型數據中。常用的NOSQL有mongodb和redis，搜索引擎有lucene。

九、將應用伺服器進行業務拆分

隨著業務進一步擴展，應用程序變得非常臃腫，這時我們需要將應用程序進行業務拆分，如網路分為新聞、網頁、圖片等業務。每個業務應用負責相對獨立的業務運作。業務之間通過消息進行通信或者同享資料庫來實現。

十、搭建分布式服務

這時我們發現各個業務應用都會使用到一些基本的業務服務，例如用戶服務、訂單服務、支付服務、安全服務，這些服務是支撐各業務應用的基本要素。我們將這些服務抽取出來利用分部式服務框架搭建分布式服務。淘寶的Dubbo是一個不錯的選擇。

大型網站的架構是根據業務需求不斷完善的，根據不同的業務特徵會做特定的設計和考慮，本文只是講述一個常規大型網站會涉及的一些技術和手段。

如果你還有這些疑問，成熟的網站架構師需要學什麼核心技能？Java程序員如何晉升為互聯網架構師？Java語言在架構搭建中扮演什麼角色？怎樣成為年收入幾十萬的架構師？歡迎來電來訪昆明北大青鳥java培訓。