【正文】 eparestatement，另外避免程序冗余如查找數(shù)據(jù)少用雙重循環(huán)等。據(jù)我分析，絕大部分的開銷就是在 NEW 的時候和連接數(shù)據(jù)庫時候產(chǎn)生的，請盡量避免。 通常是采用 oracle 存儲過程＋ 2 個 weblogic，更新機制也幾乎一樣每簽發(fā)一條新聞，就會生成 靜態(tài)頁面，然后發(fā)往前端的 web 服務(wù)器，前端的 web 都是做負載均衡的。做一個大的網(wǎng)站遠沒有想象中那么簡單，服務(wù)器基本就要百十個的。 網(wǎng)站使用基于 Linux 集群的負載均衡，失敗恢復(fù)，包括應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器，基于linuxha 的服務(wù)狀態(tài)檢測及高可用化。這樣的網(wǎng)站實時性也是相對的，因為在數(shù)據(jù)庫復(fù)制數(shù)據(jù)的時候有一個過程，一般在技術(shù)上可以用到 hibernate 和 ecache，但是如果要使網(wǎng)站工作地更好，可以使用 EJB 和 websphere， weblogic 這樣大型 的服務(wù)器來支持，并且要用 oracle 這樣的大型數(shù)據(jù)庫。它能讓你大量并行 IO 訪問，而且不需要任何重組就能夠增加所需要的磁盤。 squid 將大部分靜態(tài)資源 (圖片， js， css 等）緩存起來，直接返回給訪問者，減少應(yīng)用服務(wù)器的負載 網(wǎng)站的靜態(tài)化網(wǎng)頁并不是真的，而是通過動態(tài)網(wǎng)頁與靜態(tài)網(wǎng)頁網(wǎng)址交換做出現(xiàn)的假象，這可以用 urlrewrite 這樣的開源網(wǎng)址映射器實現(xiàn)，后綴名為 htm 或者 html 并不能說明程序生成了靜態(tài)頁面，可能是通過 url 重寫來實現(xiàn)的，為的只不過是在搜索引擎中提升自己網(wǎng)站的覆蓋面積罷了。因為 Cache Server 對 CPU 消耗不大，而有了 Cache Server 的支援， App Server 對內(nèi)存要求也不是太高，所以 可以和平共處，更有效的利用資源。在面對大量用戶訪問、高并發(fā)請求方面，基本的解決方案集中在這樣幾個環(huán)節(jié)：使用高性能的服務(wù)器、高性能的數(shù)據(jù)庫、高效率的編程語言、還有高性能的Web 容器。但是對于大量內(nèi)容并且頻繁更新的網(wǎng)站，我們無法全部手動去挨個實現(xiàn)，于是出現(xiàn)了我們常見的信息發(fā)布系統(tǒng) CMS，像我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發(fā)布系統(tǒng)來管理和實現(xiàn)的，信息發(fā)布系統(tǒng)可以實現(xiàn)最簡單的信息錄入自動生成靜態(tài)頁面，還能具備頻道管理、權(quán)限管理、自動抓取等功能，對于一個大型網(wǎng)站來說，擁有一套高效、可管理的 CMS 是必不可少的。這樣的架構(gòu)可以降低提供頁面訪問請求的服務(wù)器系統(tǒng)壓力，并且可以保證系統(tǒng)不會因為圖片問題而崩潰，在應(yīng)用服務(wù)器和圖片服務(wù)器上，可以進行不同的配置優(yōu)化，比如 apache 在配置 ContentType 的時候可以盡量少支持，盡可能少的 LoadModule，保證更高的系統(tǒng)消耗和執(zhí)行效率。我們在應(yīng)用程序中安裝業(yè)務(wù)和應(yīng)用或者功能模塊將數(shù)據(jù)庫進行分離，不同的模塊對應(yīng)不同的數(shù)據(jù)庫或者表，再按照一定的策略對某個頁面或者功能進行更小的數(shù)據(jù)庫散列，比如用戶表，按照用戶 ID 進行表散列，這樣就能夠低成本的提升系統(tǒng)的性能并且有很好的擴展性。這里先講述最基本的兩種緩存。另外，在使用 web 語言開發(fā)的時候，各種語言基本都有自己的緩存模塊和方法， PHP 有 Pear 的 Cache 模塊， Java 就更多了， . 不是很熟悉，相信也肯定有。 負載均衡 負載均衡將是大型網(wǎng)站解決高負荷訪問和大量并發(fā)請求采用的終極解決辦法。它傳輸?shù)臉I(yè)務(wù)服從的協(xié)議多種多樣，有 HTTP、 FTP、 NFS、 Tel 或其他協(xié)議。 Yahoo 中國當初接近2020 臺服務(wù)器使用了三四臺 Alteon 就搞定了。 一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎(chǔ)上搭建 squid 集群，這種思路在很多大型網(wǎng)站包括搜索引擎上被采用，這樣的架構(gòu)低成本、高性能還有很強的擴張性，隨時往架構(gòu)里面增減節(jié)點都非常容易。動態(tài)應(yīng)用系統(tǒng)通常與數(shù)據(jù)庫系統(tǒng)、緩存系統(tǒng)、分布式存儲系統(tǒng)等密不可分。該 Web 前端系統(tǒng)基于 Apache/Ligd/Eginx 等的虛擬主機平臺，提供 PHP 程序運行環(huán)境。大多數(shù)網(wǎng)站都是硬件、軟件負載均衡系統(tǒng)并用。 3) 寫數(shù)據(jù)庫有多臺，每臺都可以提供多個應(yīng)用共同使用，這樣可以解決寫庫的性能瓶頸問題和單點故障問題。 緩存系統(tǒng) 緩存分為文件緩存、內(nèi)存緩存、數(shù)據(jù)庫緩存。 減輕對數(shù)據(jù)庫及存儲集服務(wù)器的訪問壓力。 2) 負載均衡 cluster 中的每個節(jié)點都有可能訪問任何一個數(shù)據(jù)對象，每個節(jié)點對數(shù)據(jù)的處理也能被其他節(jié)點共享，因此這些節(jié)點要操作的數(shù)據(jù)從邏輯上看只能是一個整體，不是各自獨立的數(shù)據(jù)資源。 在分布式服務(wù)器管理系統(tǒng)軟件中 有一些比較優(yōu)秀的軟件，其中比較理想的一個是 Cfengine。 代碼發(fā)布系統(tǒng) 結(jié)構(gòu)圖： 隨著網(wǎng)站訪問流量的不斷增加，大多的網(wǎng)絡(luò)服務(wù)都是以負載均衡集群的方式對外提供服務(wù)，隨之集群規(guī)模的擴大，為了 滿足集群環(huán)境下程序代碼的批量分發(fā)和更新，我們還需要一個程序代碼發(fā)布系統(tǒng)。 這里面可以使用常用的工具 Rsync，通過開 發(fā)相應(yīng)的腳本工具實現(xiàn)服務(wù)器集群間代碼同步分發(fā)。它是個可靠的平臺，運行良好，是現(xiàn)在全球最 流行的 Inter 系統(tǒng)架構(gòu)。造成的結(jié)果是，雖然花費很低的成本網(wǎng)站就可以開始運行，但是當擁有大量用戶、 需要擴展規(guī)模的時候，通常就會面臨真正的問題。 使用合適的會話管理 第 一個想到的擴展系統(tǒng)的方法就是添加更多硬件。 會話被定義為單獨的最終用 戶登錄或者連接一 段時間，其中通常會包含多個TCP/IP 的 HTTP 連接、幾個 Web 頁面，通常還包括幾十個甚至上百個頁面元素，如框架、菜單、 Ajax 更新等。在 PHP 中，通常是這樣解決的，在第一次連接或登錄的時候就創(chuàng)建一個會話 ID 并將其放在Cookie 中，然后這個 Cookie 會和每個 HTTP 請求一起發(fā)送。 在前面所舉的中國 Inter 用戶 %的例子中，可能很容易在每秒內(nèi)僅僅為了管理會話就生成上百個查詢。在 Inter 上有很多不錯的關(guān)于良好的會話管理的例子，你可以根據(jù)需要找到最適合的。 除了配置專門的硬件防火墻（像 Cisco 的 ASA）之外，所有服務(wù)器都還應(yīng)該運行像 Iptables 之類的防火墻，它會保護服務(wù)器免受其他威脅和攻擊。例如，默認的 RedHat 或者 CentOS 防火墻的配置說明 只有 10 行，顯然并不實用。如果Apache 只是運行在 Apache 用戶下或者運行在 Nobody 下，那么闖入 Apache 就不是一件容易的事情了。這 會防范 幾乎所有的黑客和針對頁面的攻擊。 使用標準的路徑和安裝配置 一個令人討厭的部署問題是，開發(fā)者很少考慮 他們的軟件會被部署到生產(chǎn) Web服務(wù)器的什么位置，以及如何部署。 你應(yīng)該總是使用標準的安裝包和二進制文件來 安裝像 Apache 之類的服務(wù)器。 Web 服務(wù)器的日志應(yīng)該存放在 /var /logs 或者 /var/logs/app_name 下，而不應(yīng)該位于主代碼區(qū)域。 總是使用日志 在 Web 系統(tǒng)中做多少日 志都不為過。在腳本啟動 /停止、重要的腳本執(zhí)行以及實時數(shù)據(jù)產(chǎn)生的 情況下都要執(zhí)行寫入日志操作。 一個好的系統(tǒng)會對程序進行配置，用來打開或 者關(guān)閉日志，并可以選擇在每模塊或者功能的級別上應(yīng)用不同級別的日志。很多系統(tǒng)都擁有良好的或者至少是可用的數(shù)據(jù)庫設(shè)計，但由于沒有經(jīng)過適當?shù)男阅軠y 試， SQL 代碼質(zhì)量通常都會很差。在增大的過程中，數(shù)據(jù)庫系統(tǒng)看起來運行得很快（因為數(shù)據(jù)都位于內(nèi)存中，而且 很少有并發(fā)的查詢），并且對用戶的響 應(yīng)也很快，但實際上它的內(nèi)部運行效率很低。 MySQL系統(tǒng)應(yīng)該對所有數(shù)據(jù)使用 INNODB存儲引擎，因為 INNODB與之前的 MyISAM相比 ，運行得更快、更穩(wěn)定，并且管理性能和備份工作也更加容易和快捷。 另外，在將所有備份文件從服務(wù)器上轉(zhuǎn)移出來 之前要進行壓縮和加密。文檔中大約有 100 種有用的關(guān)于安全、性能和穩(wěn)定性問題的設(shè)定，包括防止數(shù)據(jù)敗壞，其中很多設(shè)定都是 非常重要的。 盡管概念上很簡單，但是想要合理、精確地實 現(xiàn)并不容易，這可能需要大量的代碼工作。為了達到這個目的，我們可以使用像 MemCached 之類的數(shù) 據(jù)緩存，它是一個高性能的簡單數(shù)據(jù)緩存，已經(jīng)被所有最大型的站點使用。當系統(tǒng) 變得越來越大、越來越復(fù)雜時，測試和管理代碼就會導(dǎo)致嚴重的問題。 使 用版本控制 最后，要對一切使用版本控制，包括測試和生 產(chǎn)環(huán)境的部署。開發(fā)者應(yīng)該將所有一切都簽入，打上標簽，然后將它們簽 出到測試系統(tǒng)。當你構(gòu)建和管理站點的時候，請不要忘了這些重要的問題