【正文】 ID 來查找會(huì)話數(shù)據(jù)。所有這些 HTTP 請(qǐng)求都需要知道用戶是誰，才能滿足安全的要求，并向用戶傳送適當(dāng)?shù)膬?nèi)容，因?yàn)檫@些都是會(huì)話的組成部分。例如，使用兩臺(tái)服務(wù)器而不是一臺(tái)。畢竟，中國(guó)擁有三億八千萬的 Inter 用戶，如果其中的 %訪問這個(gè) 站點(diǎn)，就很容易引發(fā) 25 萬 ~50 萬的頁面訪問量。然而，我們很難對(duì) 其規(guī)模進(jìn)行正確的擴(kuò)展并保持安全性，因?yàn)槊總€(gè)應(yīng)用層都有其自身的問題、缺陷和最佳實(shí)踐。 大型高性能網(wǎng)站的十項(xiàng)規(guī)則 見 過多種不同類型的網(wǎng)站和系統(tǒng)，有好也有差。 這個(gè)發(fā)布系統(tǒng)可以幫我們實(shí)現(xiàn)下面的目標(biāo)： 1) 生產(chǎn)環(huán)境的服務(wù)器以虛擬主機(jī)方式提供服務(wù)，不需要開發(fā)人員介入維護(hù)和直接操作，提供發(fā)布系統(tǒng)可以實(shí)現(xiàn)不需要登陸服務(wù)器就能把程序分發(fā)到目標(biāo)服務(wù)器。它可以對(duì)服務(wù)器進(jìn)行分組，不同的分組可以分別定制系統(tǒng)配置文件、計(jì)劃任務(wù)等配置。 因此高性能的分布式存儲(chǔ)系統(tǒng)對(duì)于大型網(wǎng)站應(yīng)用來說是非常重要的一環(huán)。 Memcached 服務(wù)器有多臺(tái)，避免單點(diǎn)故障，提供高可靠性和可擴(kuò)展性，提高性能。在大型 Web 應(yīng)用中使用最多且效率最高的是內(nèi)存緩存。 4) 讀數(shù)據(jù)庫有多臺(tái)，通過負(fù)載均衡設(shè)備實(shí)現(xiàn)負(fù)載均衡，從而達(dá)到讀數(shù)據(jù)庫的高性能、高可靠和高可擴(kuò)展性。 數(shù)據(jù)庫集群系統(tǒng) 結(jié)構(gòu)圖： 由于 Web 前端采用了負(fù)載均衡集群結(jié)構(gòu)提高了服務(wù)的有效性和擴(kuò)展性，因此數(shù)據(jù)庫必須也是高可靠的，才能保證整個(gè)服務(wù)體系的高可靠性，如何構(gòu)建一個(gè)高可靠的、可以提供大規(guī)模并發(fā)處理的數(shù)據(jù)庫體系？ 我們可以采用如上圖所示的方案： 1) 使用 MySQL 數(shù)據(jù)庫，考慮到 Web 應(yīng)用的數(shù)據(jù) 庫讀多寫少的特點(diǎn)，我們主要對(duì)讀數(shù)據(jù)庫做了優(yōu)化，提供專用的讀數(shù)據(jù)庫和寫數(shù)據(jù)庫，在應(yīng)用程序中實(shí)現(xiàn)讀操作和寫操作分別訪問不同的數(shù)據(jù)庫。服務(wù)器對(duì)開發(fā)人員是透明的，不需要開發(fā)人員介入服務(wù)器管理 負(fù)載均衡系統(tǒng) 負(fù)載均衡系統(tǒng)分為硬件和軟件兩種。 大型動(dòng)態(tài)應(yīng)用系統(tǒng)平臺(tái)主要是針對(duì)于大流量、高并發(fā)網(wǎng)站建立的底層系統(tǒng)架構(gòu)。這樣的架構(gòu)我準(zhǔn)備空了專門詳細(xì)整理一下和大家探討。 軟件四層交換 大家知道了硬件四層交換機(jī)的原理后，基于 OSI 模型來實(shí)現(xiàn)的軟件四層交換也就應(yīng)運(yùn)而生，這樣的解決方案實(shí)現(xiàn)的原理一致，不過性能稍差。這些業(yè)務(wù)在物理服務(wù)器基礎(chǔ)上，需要復(fù)雜的載量平衡算法。 負(fù)載均衡技術(shù)發(fā)展了多年，有很多專業(yè)的服務(wù)提供商和產(chǎn)品可以選擇，我個(gè)人接觸過一些解決方法，其中有兩個(gè)架構(gòu)可以給大家做參考。 鏡像 鏡像是大型網(wǎng)站常采用的提高性能和數(shù)據(jù)安全性的方式，鏡像的技術(shù)可以解決不同網(wǎng)絡(luò)接入商和地域帶來的用戶訪問速度差異，比如 ChinaNet 和 EduNet 之間的差異就促使了很多網(wǎng)站在教育網(wǎng)內(nèi)搭建鏡像站點(diǎn)，數(shù)據(jù)進(jìn)行定時(shí)更新或者實(shí)時(shí)更新。高級(jí)和分布式的緩存在后面講述。sohu 的論壇就是采用了這樣的架構(gòu)，將論壇的用戶、設(shè)置、帖子等信息進(jìn)行數(shù)據(jù)庫分離，然 后對(duì)帖子、用戶按照板塊和 ID 進(jìn)行散列數(shù)據(jù)庫和表，最終可以在配置文件中進(jìn)行簡(jiǎn)單的配置便能讓系統(tǒng)隨時(shí)增加一臺(tái)低成本的數(shù)據(jù)庫進(jìn)來補(bǔ)充系統(tǒng)性能。 數(shù)據(jù)庫集群和庫表散列 大型網(wǎng)站都有復(fù)雜的應(yīng)用，這些應(yīng)用必須使用數(shù)據(jù)庫，那么在面對(duì)大量訪問的時(shí)候，數(shù)據(jù)庫的瓶頸很快就能顯現(xiàn)出來，這時(shí)一臺(tái)數(shù)據(jù)庫將很快無法滿足應(yīng)用，于是我們需要使用數(shù)據(jù)庫集群或者庫表散列。 除了門戶和信息發(fā)布類型的網(wǎng)站，對(duì)于交互性要求很高的社區(qū)類型網(wǎng)站來說，盡可能的靜態(tài)化也是提高性能的必要手段，將社區(qū)內(nèi)的帖子、文章進(jìn)行實(shí)時(shí)的靜態(tài)化，有更新的時(shí)候再重新靜態(tài)化也是大量使用的策略，像 Mop 的大雜燴就是使用了這樣的策略，網(wǎng)易社區(qū)等也是如此。但是除了這幾個(gè)方面，還沒法根本解決大型網(wǎng)站面臨的高負(fù)載和高并發(fā)問題。 以上一些不太成熟的想法，可以從某一個(gè)層次開始，逐步細(xì)化，把產(chǎn)品的性能指標(biāo)提高上去。 生成靜態(tài)頁面的服務(wù)器和 服務(wù)器是兩組不同的服務(wù)器，頁面生成后才會(huì)到 服務(wù)器，一部 分?jǐn)?shù)據(jù)庫并不是關(guān)系數(shù)據(jù)庫，這樣更適合信息衍生， 、 mail 服務(wù)器、路由器多，主要用負(fù)載平衡解決訪問瓶頸。 頁面數(shù)據(jù)調(diào)用更要認(rèn)真設(shè)計(jì)，一些數(shù)據(jù)查詢可以不通過數(shù)據(jù)庫的方式，實(shí)時(shí)性要求不高的可以使用 lucene 來實(shí)現(xiàn)，即使有實(shí)時(shí)性的要求也可以用 lucene， lucene+pass 還是非常優(yōu)秀的。 大型門戶網(wǎng)站不建議使用 Mysql 數(shù)據(jù)庫，除非你對(duì) Mysql 數(shù)據(jù)的優(yōu)化非常熟悉。 應(yīng)用服務(wù)器集群可以采用 apache+tomcat 集群和 weblogic 集群等； web 服務(wù)器集群可以用反向代理，也可以用 NAT 的方式，或者多域名解析都可以； Squid 也可以，方法很多，可以根據(jù)情況選擇。 這樣可以大大增加一臺(tái)計(jì)算機(jī)的處理速度，如果一臺(tái)機(jī)器處理不了，可以用 erver 集群來解決問題了。另外還有定時(shí)的程序，每 515 分鐘自動(dòng)生成一次。另外可以用一些內(nèi)存測(cè)試工具來做一個(gè) demo 說明hibernate 和 ibatis 誰更快！前臺(tái)你想用什么就用什么， struts,webwork 都成，如果覺得自己挺牛 X 可以試試用 tapestry。另外選用優(yōu)秀的開源框架加以支持，我個(gè)人認(rèn)為中后臺(tái)的支持是最最重要的，可以選取 spring＋ ibatis。 一個(gè)好的程序員寫出來的程序會(huì)非常簡(jiǎn)潔、性能很好，一個(gè)初級(jí)程序員可能會(huì)犯很多低級(jí)錯(cuò)誤，這也是影響網(wǎng)站性能的原因之一。 大型網(wǎng)站數(shù)據(jù)庫優(yōu)化 千萬人同時(shí)訪問的網(wǎng)站，一般是有很多個(gè)數(shù)據(jù)庫同時(shí)工作，說明白一點(diǎn)就是數(shù)據(jù)庫集群和并發(fā)控制，這樣的網(wǎng)站實(shí)時(shí)性也是相對(duì)的。而這個(gè)時(shí)候可能是最讓人困擾的的問題了，數(shù)據(jù)基于網(wǎng)絡(luò)傳輸根據(jù)數(shù)據(jù)庫的設(shè)計(jì)的不同，數(shù)據(jù)延遲是很可怕的問題，也是不可避免的問題，這樣的話，我們就需要通過另外的手段來保證在這延遲的幾秒或者更長(zhǎng)的幾分鐘時(shí)間內(nèi)，實(shí)現(xiàn)有效的交互。對(duì)于一些群發(fā)，基本上是不可能的。對(duì)于一些計(jì)算量大的 AJAX 請(qǐng)求的話，我們可以構(gòu)造一個(gè)發(fā)包機(jī)，很容易就可以把一個(gè) webserver 干掉。為了保證各地的訪問速度，我們就需要面對(duì)一個(gè)絕大的問題，就是如何有效的實(shí)現(xiàn)數(shù)據(jù)同步和更新，實(shí)現(xiàn)各地服務(wù)器的實(shí)時(shí)通訊有是一個(gè)不得不需要考慮的問題。 數(shù)據(jù)索引的問題 眾所周知，索引是提高數(shù)據(jù)庫效率查詢的最方面最廉價(jià)最容易實(shí)現(xiàn)的方案。如果這個(gè)時(shí)候還涉及上傳，磁盤很容易就 over 了。 另外，就是數(shù)據(jù)庫的死鎖問題，也許平時(shí)我們感覺不到，死鎖在高并發(fā)的情況下的出現(xiàn)的概率是非常高的，磁盤緩存就是一個(gè)大問題。 數(shù)據(jù)并發(fā)的處理 在一些時(shí)候， 的 CTO 都有個(gè)尚方寶劍，就是緩存。 這里討論一下大型網(wǎng)站需要注意和考慮的問題。我們這里不討論是 PHP 還是 JSP 或者 .NET 環(huán)境，我們從架構(gòu)的方面去看問題，實(shí)現(xiàn)語言方面并不是問題，語言的優(yōu)勢(shì)在于實(shí)現(xiàn)而不是好壞，不論你選擇任何語言，架構(gòu)都是必須要面對(duì)的。在這個(gè)時(shí)候我們對(duì)于一個(gè)表的 select 和update 的時(shí)候 (還不說多表聯(lián)合查詢 )的成本的非常高的。這個(gè)時(shí)候，就需要一個(gè)好的數(shù)據(jù)并發(fā)處理策略以及緩存策略。但是當(dāng)文件量是海量的數(shù)據(jù)的情況下，如果一塊硬盤存貯了 500 個(gè) G 的瑣碎文件，那么維護(hù)的時(shí)候和使用的時(shí)候磁盤的 Io 就是一個(gè)巨大的問題，哪怕你的帶寬足夠，但是你的磁盤也未必響應(yīng)過來。必須有效的把多表聯(lián)合查詢降到最低。 分布式處理 對(duì)于 網(wǎng)站由于其高互動(dòng)性， CDN 實(shí)現(xiàn)的效果基本上為 0，內(nèi)容是實(shí)時(shí)更新的，我們常規(guī)的處理。但是在 AJAX 處理的時(shí)候，如果我們使用一個(gè)抓包工具的話，對(duì)數(shù)據(jù)返回和處理是一目了然。也許我們可以很的意的說，我們可以采用更高級(jí)別的判斷甚至 HTTPS 來實(shí)現(xiàn)，注意，當(dāng)你做這些處理的時(shí)候付出的將是海量的 database， io 以及 CPU 的成本。 數(shù)據(jù)同步和集群的 處理的問題 當(dāng)我們的一臺(tái) databaseserver 不堪重負(fù)的時(shí)候，這個(gè)時(shí)候我們就需要做基于數(shù)據(jù)庫的負(fù)載和集群了。這個(gè)時(shí)候一個(gè)有效的數(shù)據(jù)共享平臺(tái)，數(shù)據(jù)開放平臺(tái)就成為必不可少的途徑了，而在開放的接口的情況保證數(shù)據(jù)的安全性和性能，又是一個(gè)我們必須要認(rèn)真思考的問題了。 軟件架構(gòu)方面，做網(wǎng)站首先需要很多 web 服務(wù)器存儲(chǔ)靜態(tài)資源，比如圖片、視頻、靜態(tài)頁等，千萬不要把靜態(tài)資源和應(yīng)用服務(wù)器放在一起。第二，程序上的優(yōu)化，這個(gè)非常的有講究，比如說重要一點(diǎn)就是要規(guī)范ＳＱＬ語句，少用 in 多用 or，多用 pr