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