網(wǎng)絡架構設計方案

jiajia2obgs51e 2016-08-31

展開全文

網(wǎng)絡架構是現(xiàn)代網(wǎng)絡學習和發(fā)展的一個必須的基礎技術。在選擇機房的時候，根據(jù)網(wǎng)站用戶的地域分布，可以選擇網(wǎng)通或電信機房，但更多時候，可能雙線機房才是合適的。越大的城市，機房價格越貴，從成本的角度看可以在一些中小城市托管服務器，比如說北京的公司可以考慮把服務器托管在天津，廊坊等地，不是特別遠，但是價格會便宜很多。

現(xiàn)在的PHP框架有很多選擇，比如：CakePHP，Symfony，Zend Framework等等，至于應該使用哪一個并沒有唯一的答案，要根據(jù)Team里團隊成員對各個框架的了解程度而定。很多時候，即使沒有使用框架，一樣能寫出好的程序來，比如Flickr據(jù)說就是用Pear+Smarty這樣的類庫寫出來的，所以，是否用框架，用什么框架，一般不是最重要的，重要的是我們的編程思想里要有框架的意識。

網(wǎng)站規(guī)模到了一定的程度之后，代碼里各種邏輯糾纏在一起，會給維護和擴展帶來巨大的障礙，這時我們的解決方式其實很簡單，那就是重構，將邏輯進行分層。通常，自上而下可以分為表現(xiàn)層，應用層，領域層，持久層。

所謂表現(xiàn)層，并不僅僅就指模板，它的范圍要更廣一些，所有和表現(xiàn)相關的邏輯都應該被納入表現(xiàn)層的范疇。比如說某處的字體要顯示為紅色，某處的開頭要空兩格，這些都屬于表現(xiàn)層。很多時候，我們?nèi)菀追傅腻e誤就是把本屬于表現(xiàn)層的邏輯放到了其他層面去完成，這里說一個很常見的例子：我們在列表頁顯示文章標題的時候，都會設定一個最大字數(shù)，一旦標題長度超過了這個限制，就截斷，并在后面顯示“..”，這就是最典型的表現(xiàn)層邏輯，但是實際情況，有很多程序員都是在非表現(xiàn)層代碼里完成數(shù)據(jù)的獲取和截斷，然后賦值給表現(xiàn)層模板，這樣的代碼最直接的缺點就是同樣一段數(shù)據(jù)，在這個頁面我可能想顯示前10個字，再另一個頁面我可能想顯示前15個字，而一旦我們在程序里固化了這個字數(shù)，也就喪失了可移植性。正確的做法是應該做一個視圖助手之類的程序來專門處理此類邏輯，比如說：Smarty里的truncate就屬于這樣的視圖助手（不過它那個實現(xiàn)不適合中文）。

所謂應用層，它的主要作用是定義用戶可以做什么，并把操作結果反饋給表現(xiàn)層。至于如何做，通常不是它的職責范圍（而是領域層的職責范圍），它會通過委派把如何做的工作交給領域層去處理。在使用MVC架構的網(wǎng)站中，我們可以看到類似下面這樣的URL： domain/articles/view/123，其內(nèi)部編碼實現(xiàn)，一般就是一個Articles控制器類，里面有一個view方法，這就是一個典型的應用層操作，因為它定義了用戶可以做一個查看的動作。在MVC架構中，有一個準則是這么說的：Rich Model Is Good。言外之意，就是Controller要保持“瘦”一些比較好，進而說明應用層要盡量簡單，不要包括涉及領域內(nèi)容的邏輯。

所謂領域層，最直接的解釋就是包含領域邏輯的層。它是一個軟件的靈魂所在。先來看看什么叫領域邏輯，簡單的說，具有明確的領域概念的邏輯就是領域邏輯，比如我們在ATM機上取錢，過程大致是這樣的：插入銀聯(lián)卡，輸入密碼，輸入取款金額，確定，拿錢，然后ATM吐出一個交易憑條。在這個過程中，銀聯(lián)卡在ATM機器里完成錢從帳戶上劃撥的過程就是一個領域邏輯，因為取錢在銀行中是一個明確的領域概念，而ATM機吐出一個交易憑條則不是領域邏輯，而僅是一個應用邏輯，因為吐出交易憑條并不是銀行中一個明確的領域概念，只是一種技術手段，對應的，我們?nèi)″X后不吐交易憑條，而發(fā)送一條提醒短信也是可能的，但并不是一定如此，如果在實際情況中，我們要求取款后必須吐出交易憑條，也就是說吐出交易憑條已經(jīng)和取款緊密結合，那么你也可以把吐出交易憑條看作是領域邏輯的一部分，一切都以問題的具體情況而定。

在Eric那本經(jīng)典的領域驅動設計中，把領域層分為了五種基本元素：實體，值對象，服務，工廠，倉儲。具體可以參閱書中的介紹。領域層最常犯的錯誤就是把本應屬于領域層的邏輯泄露到了其他層次，比如說在一個CMS系統(tǒng)，對熱門文章的定義是這樣的：每天被瀏覽的次數(shù)多于1000次，被評論的次數(shù)多于100次，這樣的文章就是熱門文章。對于一個

CMS來說，熱門文章這個詞無疑是一個重要的領域概念，那么我們?nèi)绾螌崿F(xiàn)這個邏輯的設計的？你可能會給出類似下面的代碼：“SELECT ... FROM ... WHERE 瀏覽> 1000 AND評論 > 100”，沒錯，這是最簡單的實現(xiàn)方式，但是這里需要注意的是“每天被瀏覽的次數(shù)多于1000次，被評論的次數(shù)多于100次”這個重要的領域邏輯被隱藏到了SQL語句中，SQL語句顯然不屬于領域層的范疇，也就是說，我們的領域邏輯泄露了。

網(wǎng)站的性能瓶頸分析

網(wǎng)站的性能影響因素很多，下面主要從如下4個方面進行分析說明：

網(wǎng)絡負載

公網(wǎng)負載

內(nèi)網(wǎng)負載

WEB應用服務器性能

CPU

存儲，I/O訪問

內(nèi)存

并發(fā)TCP/IP連接數(shù)

數(shù)據(jù)庫服務器性能

數(shù)據(jù)庫參數(shù)配置

服務器性能（CPU、內(nèi)存、存儲）

數(shù)據(jù)結構的合理性

不同WEB應用的處理方式而對不同的性能瓶頸

對于靜態(tài)的網(wǎng)站：

靜態(tài)的HTML頁面嚴格地由標準的HTML標示語言構成，并不需要服務器端即時運算生成。這意味著，對一個靜態(tài)HTML文檔發(fā)出訪問請求后，服務器端只是簡單地將該文檔傳輸?shù)娇蛻舳?。從服務器運行的那個時間片來看，這個傳輸過程僅僅占用了很小的CPU資http://m./m/prod_view.aspx?TypeId=65&Id=184&Fid=t3:65:3&typefid=65源。對于靜態(tài)HTML的訪問瓶頸為：網(wǎng)絡帶寬、磁盤I/O以及cache(高速緩沖存儲器)。

對于動態(tài)頁面

因為服務器解析動態(tài)頁面必須在其傳輸?shù)娇蛻舳饲熬屯ㄟ^服務器來進行解釋，這樣就會給應用服務器添加額外的性能消耗，如果進一步要訪問數(shù)據(jù)庫，則會增加數(shù)據(jù)庫服務器的性能消耗，則動態(tài)頁面還有額外的瓶頸：應用服務器的性能，數(shù)據(jù)庫服務器的性能。

系統(tǒng)架構

設計

總體思路

為提高網(wǎng)站的高并發(fā)性能,提高開發(fā)效率及運營效率,主要按如下幾個思路進行規(guī)劃設計:

負載均衡

四層交換負載均衡：

采用負載均衡器來實現(xiàn)硬件級的四層交換負載均衡，或采用LVS來實現(xiàn)軟件的四層交換負載均衡。

通過第三方軟件來實現(xiàn)負載均衡,同時實現(xiàn)頁面請求的緩存。

通過Nginx實現(xiàn)反向代理服務器集群，同時搭建squid集群以作為靜態(tài)頁面和圖片的緩存。

通過web服務器的配置來實現(xiàn)負載均衡

即通過apache或是Nginx 將客戶請求均衡的分給tomcat1,tomcat2....去處理。

WEB應用開發(fā)架構思路

應用開發(fā)實現(xiàn)MVC架構三層架構進行web應用開發(fā)

頁面盡可能靜態(tài)化以減少動態(tài)數(shù)據(jù)訪問，如果是資訊類的網(wǎng)站可以考慮采用第三方開源的CMS系統(tǒng)來生成靜態(tài)的內(nèi)容頁面。

采用Oscache實現(xiàn)頁面緩存,采用Memcached實現(xiàn)數(shù)據(jù)緩存

采用獨立的圖片服務器集群來實現(xiàn)圖片資源的存儲及WEB請求

數(shù)據(jù)存儲的設計思路

數(shù)據(jù)庫拆分,把生產(chǎn)數(shù)據(jù)庫和查詢數(shù)據(jù)庫分離，對生產(chǎn)數(shù)據(jù)庫采用RAC實現(xiàn)數(shù)據(jù)庫的集群。

采用高效的網(wǎng)絡文件共享策略，采用圖片服務器來實現(xiàn)頁面的圖片存儲。

不同網(wǎng)絡用戶訪問考慮

通過引入CDN來解決不同網(wǎng)絡服務商的接入速度問題，一般只能解決靜態(tài)頁面的訪問問題。

在不同運營商機房部署服務器，通過鏡像技術來實現(xiàn)不同網(wǎng)絡服務商的接入速度問題。

總體架構

網(wǎng)站的開發(fā)架構

網(wǎng)絡

拓撲結構

備注：

采用雙防火墻雙交換機做網(wǎng)絡冗余，保障平臺服務

采用雙防火墻通知接通2線路互聯(lián)網(wǎng)接入，設備之間采用VRRP協(xié)議，在任何一個防火墻、互聯(lián)網(wǎng)發(fā)生故障后均可自動將流量切換到另一端，保證網(wǎng)站的正運行，設備或網(wǎng)絡恢復后，自動恢復。

采用雙千兆交換機分別接在2臺防火墻上，當某臺設備或者網(wǎng)絡鏈路發(fā)生故障后，好設備自動接管已壞設備的工作，不影響網(wǎng)站的整體運行，根據(jù)業(yè)務及真實服務器的數(shù)量，交換機可以隨時增加。

采用硬件設備負載均衡器，實現(xiàn)網(wǎng)絡流量的負載均衡

使用硬件設備負載均衡器，將網(wǎng)絡流量均衡的分擔到WEB服務器集群各節(jié)點服務器，保障平臺服務器資源均衡的使用。

采用代理服務器，實現(xiàn)軟件級的網(wǎng)絡負載均衡。

數(shù)據(jù)庫服務器分離成生產(chǎn)數(shù)據(jù)庫集群和查詢數(shù)據(jù)庫集群，實現(xiàn)生產(chǎn)讀寫與后臺查詢統(tǒng)計進行分離，同時生產(chǎn)數(shù)據(jù)庫采用rac技術進行

架構涉及技術的詳解

負載均衡

基于DNS的負載均衡--一個域名綁定多個IP

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

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

通過硬件四層交換實現(xiàn)負載均衡

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

通過軟件四層交換實現(xiàn)負載均衡

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

一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集群，這種思路在很多大型網(wǎng)站包括搜索引擎上被采用，這樣的架構低成本、高性能還有很強的擴張性。

通過反向代理服務器實現(xiàn)負載均衡

反向代理服務器又稱為 WEB 加速服務器，它位于 WEB 服務器的前端，充當WEB服務器的內(nèi)容緩存器,反向代理服務器是針對 WEB 服務器設置的，后臺 WEB 服務器對互聯(lián)網(wǎng)用戶是透明的，用戶只能看到反向代理服務器的地址，不清楚后臺 WEB 服務器是如何組織架構的。當互聯(lián)網(wǎng)用戶請求 WEB 服務時，DNS 將請求的域名解析為反向代理服務器的 IP 地址，這樣 URL 請求將被發(fā)送到反向代理服務器，由反向代理服務器負責處理用戶的請求與應答、與后臺WEB 服務器交互。利用架構涉及技術的詳解

負載均衡

基于DNS的負載均衡--一個域名綁定多個IP

通過硬件四層交換實現(xiàn)負載均衡

通過軟件四層交換實現(xiàn)負載均衡

通過反向代理服務器實現(xiàn)負載均衡

反向代理服務器減輕了后臺 WEB 服務器的負載，提高了訪問速度，同時避免了因用戶直接與 WEB 服務器通信帶來的安全隱患。

目前有許多反向代理軟件，比較有名的有 Nginx 和 Squid 。

Nginx 是由 Igor Sysoev 為俄羅斯訪問量第二的 Rambler.ru 站點開發(fā)的，是一個高性能的 HTTP 和反向代理服務器，也是一個 IMAP/POP3/SMTP 代理服務器。

Squid是由美國政府大力資助的一項研究計劃，其目的為解決網(wǎng)絡帶寬不足的問題，支持HTTP，HTTPS，FTP 等多種協(xié)議，是現(xiàn)在 Unix 系統(tǒng)上使用、最多功能也最完整的一套軟體。

Squid

Squid 是一個開源的軟件，利用它的反向代理技術可以提高網(wǎng)站系統(tǒng)的訪問速度,下面將重點介紹 Squid 反向代理的實現(xiàn)原理和在提高網(wǎng)站性能方面的應用。

Squid反向代理服務器位于本地 WEB 服務器和 Internet 之間 , 組織架構如下圖：

客戶端請求訪問 WEB 服務時，DNS 將訪問的域名解析為 Squid 反向代理服務器的 IP 地址。

這樣客戶端的 URL 請求將被發(fā)送到反向代理服務器。如果 Squid 反向代理服務器中緩存了該請求的資源，則將該請求的資源直接返回給客戶端，否則反向代理服務器將向后臺的 WEB 服務器請求資源，然后將請求的應答返回給客戶端，同時也將該應答緩存在本地，供下一個請求者使用。

Squid 反向代理一般只緩存可緩沖的數(shù)據(jù)（比如 html 網(wǎng)頁和圖片等），而一些 CGI 腳本程序或者 ASP、JSP 之類的動態(tài)程序默認不緩存。它根據(jù)從 WEB 服務器返回的 HTTP 頭標記來緩沖靜態(tài)頁面, 有四個最重要 HTTP 頭標記：

Last-Modified: 告訴反向代理頁面什么時間被修改

Expires: 告訴反向代理頁面什么時間應該從緩沖區(qū)中刪除

Cache-Control: 告訴反向代理頁面是否應該被緩沖

Pragma: 用來包含實現(xiàn)特定的指令，最常用的是Pragma:no-cache

注：DNS 的輪詢機制將某一個域名解析為多個IP地址。

Nginx

Nginx (“engine x”) 是俄羅斯人Igor Sysoev(塞索耶夫)編寫的一款高性能的 HTTP 和反向代理服務器。

Nginx 已經(jīng)在俄羅斯最大的門戶網(wǎng)站── Rambler Media（www.rambler.ru）上運行了4年時間，同時俄羅斯超過20%的虛擬主機平臺采用Nginx作為反向代理服務器。

在國內(nèi)，已經(jīng)有新浪博客、新浪播客、搜狐通行證、網(wǎng)易新聞、網(wǎng)易博客、金山逍遙網(wǎng)、金山愛詞霸、校內(nèi)網(wǎng)、YUPOO相冊、豆瓣、迅雷看看等多家網(wǎng)站、頻道使用 Nginx 服務器。

Nginx 特點

如下：

工作在OSI模型的第7層（應用層

）

高并發(fā)連接

官方測試能夠支撐5萬并發(fā)連接，在實際生產(chǎn)環(huán)境中跑到2～3萬并發(fā)連接數(shù)。

內(nèi)存消耗少

在3萬并發(fā)連接下，開啟的10個Nginx 進程才消耗150M內(nèi)存（15M*10=150M）。

配置文件非常簡單

風格跟程序一樣通俗易懂。

成本低廉

Nginx為開源軟件，可以免費使用。而購買F5 BIG-IP、NetScaler等硬件負載均衡交換機則需要十多萬至幾十萬人民幣。

支持Rewrite重寫規(guī)則

能夠根據(jù)域名、URL的不同，將 HTTP 請求分到不同的后端服務器群組。

內(nèi)置的健康檢查功能

如果 Nginx Proxy 后端的某臺 Web 服務器宕機了，不會影響前端訪問。

節(jié)省帶寬

支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭。

穩(wěn)定性高

用于反向代理，宕機的概率微乎其微。

Nginx+squid頁面緩存來實現(xiàn)反向代理負載均衡

通過Nginx反向代理和squid緩存實現(xiàn)動靜分離的架構圖如下所示：

Apache +tomcat集群實現(xiàn)負載均衡。

使用 apache和多個tomcat 配置一個可以應用的web網(wǎng)站，用Apache進行分流，把請求按照權重以及當時負荷分tomcat1,tomcat2...去處理，要達到以下要求：

Apache 做為HttpServer ，通過mod_jk連接器連接多個 tomcat 應用實例，并進行負載均衡。

同時還要配置session復制，也就是說其中任何一個tomcat的添加的session，是要同步復制到其它tomcat，集群內(nèi)的tomcat都有相同的session，并為系統(tǒng)（包括 Apache 和 tomcat）設定Session 超時時間。

緩存

系統(tǒng)架構方面的緩存

Squid緩存

架構方面使用Squid進行緩存。

注：SQUID使用了LM算法，LM就是頁面Header里時間(Date)和Last-Modified時間的差。Date一般是Squid從后面取頁面的時間，Last-Modified 一般是頁面生成時間。

Nginx的緩存功能

Nginx從0.7.48版本開始，支持了類似Squid的緩存功能；

緩存把URL及相關組合當作Key，用md5編碼哈希后保存；

Nginx的Web緩存服務只能為指定URL或狀態(tài)碼設置過期時間，不支持類似Squid的PURGE指令，手動清除指定緩存頁面；

采用MMAP實現(xiàn)，設置的緩存區(qū)大小不能超過物理內(nèi)存+SWEB的值

基于memcache

d的緩存

nginx對memcached

有所支持，但是功能并不是特別之強，性能上還是非常之優(yōu)秀。

location /mem/ { if ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" ) { set $memcached_key "$1"; memcached_pass 192.168.1.2:11211; } expires 70;}

這個配置會將http:///mem/abc指明到memcached的abc這個key去取數(shù)據(jù)。

Nginx目前沒有寫入memcached的任何機制，所以要往memcached里寫入數(shù)據(jù)得用后臺的動態(tài)語言完成，可以利用404定向到后端去寫入數(shù)據(jù)。

目前有許多反向代理軟件，比較有名的有 Nginx 和 Squid 。

Nginx 是由 Igor Sysoev 為俄羅斯訪問量第二的 Rambler.ru 站點開發(fā)的，是一個高性能的 HTTP 和反向代理服務器，也是一個 IMAP/POP3/SMTP 代理服務器。

Squid

Squid反向代理服務器位于本地 WEB 服務器和 Internet 之間 , 組織架構如下圖：

該請求的資源，則將該請求的資源直接返回給客戶端，否則反向代理服務器將向后臺的 WEB 服務器請求資源，然后將請求的應答返回給客戶端，同時也將該應答緩存在本地，供下一個請求者使用。

Last-Modified: 告訴反向代理頁面什么時間被修改

Expires: 告訴反向代理頁面什么時間應該從緩沖區(qū)中刪除

Cache-Control: 告訴反向代理頁面是否應該被緩沖

Pragma: 用來包含實現(xiàn)特定的指令，最常用的是Pragma:no-cache

注：DNS 的輪詢機制將某一個域名解析為多個IP地址。

Nginx

Nginx (“engine x”) 是俄羅斯人Igor Sysoev(塞索耶夫)編寫的一款高性能的 HTTP 和反向代理服務器。

Nginx 特點如下：

工作在OSI模型的第7層（應用層）

高并發(fā)連接

官方測試能夠支撐5萬并發(fā)連接，在實際生產(chǎn)環(huán)境中跑到2～3萬并發(fā)連接數(shù)。

內(nèi)存消耗少

在3萬并發(fā)連接下，開啟的10個Nginx 進程才消耗150M內(nèi)存（15M*10=150M）。

配置文件非常簡單

風格跟程序一樣通俗易懂。

成本低廉

Nginx為開源軟件，可以免費使用。而購買F5 BIG-IP、NetScaler等硬件負載均衡交換機則需要十多萬至幾十萬人民幣。

支持Rewrite重寫規(guī)則

能夠根據(jù)域名、URL的不同，將 HTTP 請求分到不同的后端服務器群組。

內(nèi)置的健康檢查功能

如果 Nginx Proxy 后端的某臺 Web 服務器宕機了，不會影響前端訪問。

節(jié)省帶寬

支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭。

穩(wěn)定性高

用于反向代理，宕機的概率微乎其微。

Nginx+squid頁面緩存來實現(xiàn)反向代理負載均衡

Apache 做為HttpServer ，通過mod_jk連接器連接多個 tomcat 應用實例，并進行負載均衡。

緩存

系統(tǒng)架構方面的緩存

Squid緩存

架構方面使用Squid進行緩存。

注：SQUID使用了LM算法，LM就是頁面Header里時間(Date)和Last-Modified時間的差。Date一般是Squid從后面取頁面的時間，Last-Modified 一般是頁面生成時間。

Nginx的緩存功能

Nginx從0.7.48版本開始，支持了類似Squid的緩存功能；

緩存把URL及相關組合當作Key，用md5編碼哈希后保存；

Nginx的Web緩存服務只能為指定URL或狀態(tài)碼設置過期時間，不支持類似Squid的PURGE指令，手動清除指定緩存頁面；

采用MMAP實現(xiàn)，設置的緩存區(qū)大小不能超過物理內(nèi)存+SWEB的值

基于memcache

d的緩存

nginx對memcached

有所支持，但是功能并不是特別之強，性能上還是非常之優(yōu)秀。

location /mem/ { if ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" ) { set $memcached_key "$1"; memcached_pass 192.168.1.2:11211; } expires 70;}

這個配置會將http:///mem/abc指明到memcached的abc這個key去取數(shù)據(jù)。

Nginx目前沒有寫入memcached的任何機制，所以要往memcached里寫入數(shù)據(jù)得用后臺的動態(tài)語言完成，可以利用404定向到后端去寫入數(shù)據(jù)。

OSCache

OSCache由OpenSymphony設計，它是一種開創(chuàng)性的JSP定制標記應用，提供了在現(xiàn)有JSP頁面之內(nèi)實現(xiàn)快速內(nèi)存緩沖的功能，OSCache是個一個廣泛采用的高性能的J2EE緩存框架，OSCache能用于任何Java應用程序的普通的緩存解決方案。OSCache有以下特點：緩存任何對象，你可以不受限制的緩存部分jsp頁面或HTTP請求，任何java對象都可以緩存。擁有全面的API--OSCache API給你全面的程序來控制所有的OSCache特性。永久緩存--緩存能隨意的寫入硬盤，因此允許昂貴的創(chuàng)建（expensive-to-create）數(shù)據(jù)來保持緩存，甚至能讓應用重啟。支持集群--集群緩存數(shù)據(jù)能被單個的進行參數(shù)配置，不需要修改代碼。緩存記錄的過期--你可以有最大限度的控制緩存對象的過期，包括可插入式的刷新策略（如果默認性能不需要時）。

OSCache是當前運用最廣的緩存方案，JBoss,Hibernate,Spring等都對其有支持。

OSCache的特點:

1) 緩存任何對象：你可以不受限制的緩存部分jsp頁面或HTTP請求，任何java對象都可以緩存。

2) 擁有全面的API：OSCache API允許你通過編程的方式來控制所有的OSCache特性。

3) 永久緩存：緩存能被配置寫入硬盤，因此允許在應用服務器的多次生命周期間緩存創(chuàng)建開銷昂貴的數(shù)據(jù)。

4) 支持集群：集群緩存數(shù)據(jù)能被單個的進行參數(shù)配置，不需要修改代碼。

5) 緩存過期：你可以有最大限度的控制緩存對象的過期，包括可插入式的刷新策略（如果默認性能不能滿足需要時）。

Memcached

memcached是高性能的分布式內(nèi)存緩存服務器。一般的使用目的是，通過緩存數(shù)據(jù)庫查詢結果，減少數(shù)據(jù)庫訪問次數(shù)，以提高動態(tài)Web應用的速度、提高可擴展性。

Memcached是以Key/Value的形式單個對象緩存。

自主開發(fā)的內(nèi)存數(shù)據(jù)緩存服務

獨立進程方式的緩存服務

對于一些常用的動態(tài)數(shù)據(jù)通過開發(fā)程序服務緩存在內(nèi)存中，提供給其他子系統(tǒng)調(diào)用，如下面的數(shù)據(jù)就可以通過這樣方式進行緩存。

用戶基本信息及狀態(tài)的信息緩沖

列表緩存，就像論壇里帖子的列表

記錄條數(shù)的緩存，比如一個論壇板塊里有多少個帖子，這樣才方便實現(xiàn)分頁。

復雜一點的group，sum，count查詢，比如積分的分類排名

信息發(fā)布系統(tǒng)(CMS)可以實現(xiàn)最簡單的信息錄入自動生成靜態(tài)頁面，對于一個大型網(wǎng)站來說，擁有一套高效、可管理的CMS是必不可少的。

同時，HTML靜態(tài)化也是某些緩存策略使用的手段，對于系統(tǒng)中頻繁使用數(shù)據(jù)庫查詢但是內(nèi)容更新很小的應用，可以考慮使用HTML靜態(tài)化來實現(xiàn)，比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行后臺管理并且存儲

再數(shù)據(jù)庫中，這些信息其實大量被前臺程序調(diào)用，但是更新頻率很小，可以考慮將這部分內(nèi)容進行后臺更新的時候進行靜態(tài)化，這樣避免了大量的數(shù)據(jù)庫訪問請求。

在進行html靜態(tài)化的時候還可以使用一種折中的方法，就是前端繼續(xù)使用動態(tài)實現(xiàn)，在一定的策略下通過后臺模塊進行定時把動態(tài)網(wǎng)頁生成靜態(tài)頁面，并定時判斷調(diào)用，這個能實現(xiàn)很多靈活性的操作。

為了提高靜態(tài)HTML的訪問效率，主要可以對以下幾個方面進行優(yōu)化：網(wǎng)絡帶寬、磁盤I/O以及cache(高速緩沖存儲器)。

數(shù)據(jù)庫配置及優(yōu)化

數(shù)據(jù)庫集群

對生產(chǎn)數(shù)據(jù)庫采用RAC實現(xiàn)數(shù)據(jù)庫的集群。

數(shù)據(jù)庫及表的散列

把生產(chǎn)數(shù)據(jù)庫和查詢數(shù)據(jù)庫進行分離，針對系統(tǒng)業(yè)務數(shù)據(jù)的特點，把大的表進行拆分，對于訪問較多的表采用分區(qū)表。

使用讀/寫數(shù)據(jù)庫分離，隨著系統(tǒng)變得越來越龐大，特別是當它們擁有很差的SQL時，一臺數(shù)據(jù)庫服務器通常不足以處理負載。但是多個數(shù)據(jù)庫意味著重復，除非你對數(shù)據(jù)進行了分離。更一般地，這意味著建立主/從副本系統(tǒng)，其中程序會對主庫編寫所有的Update、Insert和Delete變更語句，而所有Select的數(shù)據(jù)都讀取自從數(shù)據(jù)庫（或者多個從數(shù)據(jù)庫）。

盡管概念上很簡單，但是想要合理、精確地實現(xiàn)并不容易，這可能需要大量的代碼工作。因此，即便在開始時使用同一臺數(shù)據(jù)庫服務器，也要盡早計劃在PHP中使用分離的DB連接來進行讀寫操作。如果正確地完成該項工作，那么系統(tǒng)就可以擴展到2臺、3臺甚至12臺服務器，并具備高可用性和穩(wěn)定性。

擁有良好的DB配置和備份

很多公司都沒有良好的備份機制，也不知道如何恰當?shù)赝瓿蛇@項工作。只有imp是不夠的，還需要進行熱備份，從而得到超快的速度和超高的可靠性。

另外，在將所有備份文件從服務器上轉移出來之前要進行壓縮和加密。另外還要確保擁有設計合理的、有用的關于安全、性能和穩(wěn)定性問題的設定，包括防止數(shù)據(jù)敗壞，其中很多設定都是非常重要的。

硬件擴容策略

當網(wǎng)站發(fā)展到一定階段，隨著用戶量不斷擴大，現(xiàn)有的網(wǎng)絡資源和服務器資源不能滿足用戶需要的時候，就需要對平臺進行服務器和網(wǎng)絡的擴容。以下是兩種平臺擴容的方式：

增加服務器

對于web的并發(fā)處理有瓶頸時，新增的web服務器，把新增的web服務器填加到Web服務器集群中，以增加WEB的并發(fā)處理能力。

對于數(shù)據(jù)庫有處理壓力時，可以增加數(shù)據(jù)庫服務器，增加數(shù)據(jù)庫服務器加入數(shù)據(jù)庫的集群中。

增加存儲

對于存儲容量不能滿足業(yè)務需要時，可以考慮在磁盤柜中新增加硬盤，甚至考慮新增磁盤柜。

升級服務器

可以升級服務器的內(nèi)存、硬盤，甚至考慮用新的性能更高的服務器來替換。