【正文】 道的 ，可以很容易的判斷他的加密，并有效的寫一個(gè)跟他一樣的加密和解密方法出來的 )。但是，在高UPDATE 的情況下， update 和 delete 付出的成本會高的無法想想，筆者遇到過一個(gè)情況，在更新一個(gè)聚焦索引的時(shí)候需要 10 分鐘來完成，那么對于站點(diǎn) 來說，這些基本上是不可忍受的。 文件存貯的問題 對于一些支持文件上傳的 的站點(diǎn)，在慶幸硬盤容量越來越大的時(shí)候我們更多的應(yīng)該考慮的是文件應(yīng)該如何被存儲并且被有效的索引。 海量數(shù)據(jù)的 處理 眾所周知，對于一些相對小的站點(diǎn)來說，數(shù)據(jù)量并不是很大， select 和 update 就可以解決我們面對的問題，本身負(fù)載量不是很大，最多再加幾個(gè)索引就可以搞定。對于大型網(wǎng)站，每天的數(shù)據(jù)量可能就上百萬，如果一個(gè)設(shè)計(jì)不好的多對多關(guān)系，在前期是沒有任何問題的，但是隨著用戶的增長，數(shù)據(jù)量會是幾何級的增長的。常見的方案是對文 件按照日期和類型進(jìn)行存貯。 索引和更新是一對天生的冤家，問題 A， D， E 這些是我們在做架構(gòu)的時(shí)候不得不考慮的問題，并且也可能是花費(fèi)時(shí)間最多的問題。當(dāng)你站點(diǎn)流量不是很大的時(shí)候沒有人會在乎你，但是當(dāng)你流量上來之后，那么所謂的外掛，所謂的群發(fā)就會接踵而來 (從 qq 一開始的群發(fā)可見端倪 )。 數(shù)據(jù)共享的渠道以及 OPENAPI 趨勢 Openapi 已經(jīng)成為一個(gè)不可避免的趨勢，從 google， facebook， myspace 到 ，都在考慮這個(gè)問題，它可以更有效的留住用戶并激發(fā)用戶的更多的興趣以及讓更多的人幫助你做最有效的開發(fā)。第一，數(shù)據(jù)庫緩存和數(shù)據(jù)庫優(yōu)化，這個(gè)由 dba 完成（而且這個(gè)有非常大的潛力可挖，只是由于我們都是程序員而忽略了他而已）。我自己覺得門戶往往也就是當(dāng)天、熱門的資料點(diǎn)擊率較高，將其做緩存最多也不過 1~2G 的數(shù) 據(jù)量吧，舉個(gè)例子： ◎ 拿網(wǎng)易新聞來說 格式化一下，方便理解： /年 /月日 /新聞所屬分類 /新聞 可以把當(dāng)天發(fā)布的、熱門的、流攬量大的作個(gè)緩寸，用 hashtable（ key：年 月 日 分類 ID，value：新聞對象），靜態(tài)將其放到內(nèi)存（速度絕對快過硬盤尋址靜態(tài)頁面）。 集群 通常會使用 CDN 與 GSBL 與 DNS 負(fù)載均衡技術(shù)，每個(gè)地區(qū)一組前臺服務(wù)器群，例如：網(wǎng)易，百度使用了 DNS 負(fù)載均衡技術(shù)，每個(gè)頻道一組前臺服務(wù)器，一搜使用了 DNS 負(fù)載技術(shù)，所有頻道共用一組前臺服務(wù)器集群。 大型網(wǎng)站要用 oracle，數(shù)據(jù)方面操作盡量多用存儲過程，絕對提升性能；同時(shí)要讓 DBA 對數(shù)據(jù)庫進(jìn)行優(yōu)化，優(yōu)化后的數(shù)據(jù)庫與沒優(yōu)化的有天壤之別；同 時(shí)還可以擴(kuò)展分布式數(shù)據(jù)庫，以后這方面的研究會越來越多； 頁面 從開始就考慮使用虛擬存儲 /簇文件系統(tǒng)。 不能用 lucene 實(shí)現(xiàn)的可以用緩存，分布式緩存可以用 memcached，如果有錢的話用 10 來臺機(jī)器做緩存， 10G 的存儲量相信存什么都 夠了；如果沒錢的話可以在頁面緩存和數(shù)據(jù)緩存上下功夫，多用 OSCACHE 和 EHCACHE， SWARMCACHE 也可以，不過據(jù)說同步性不是很好； 可以使用 Memcache 進(jìn)行緩存，用大內(nèi)存把這些不變的數(shù)據(jù)全都緩存起來，而當(dāng)修改時(shí)就通知 cache 過期， memcache 是 LJ 開發(fā)的一款分布式緩存產(chǎn)品，很多大型網(wǎng)站在應(yīng)用，我們可以把 Cache Server 與 App Server 裝在一起。 HTML 靜態(tài)化 其實(shí) 大家都知道，效率最高、消耗最小的就是純靜態(tài)化的 html 頁面，所以我們盡可能使我們的網(wǎng)站上的頁面采用靜態(tài)頁面來實(shí)現(xiàn)，這個(gè)最簡單的方法其實(shí)也是最有效的方法。 上面提到的數(shù)據(jù)庫集群由于在架構(gòu)、成本、擴(kuò)張性方面都會受到所采用 DB 類型的限制，于是我們需要從應(yīng)用程序的角度來考慮改善系統(tǒng)架構(gòu)，庫表散列是常用并且最有效的解決方案。 網(wǎng)站程序開發(fā)方面的緩存， Linux 上提供的 Memory Cache 是常用的緩存接口，可以在 web開發(fā)中使用，比如用 Java 開發(fā)的時(shí)候就可以調(diào)用 MemoryCache 對一些數(shù)據(jù)進(jìn)行緩存和通訊共享，一些大型社區(qū)使用了這樣的架構(gòu)。 第四層交換功能就象是虛 IP，指向物理服務(wù)器。 軟件四層交換我們可以使用 Linux 上常用的 LVS 來解決， LVS 就是 Linux Virtual Server，他提供了基于心跳線 heartbeat 的 實(shí)時(shí)災(zāi)難應(yīng)對解決方案，提高系統(tǒng)的魯棒性，同時(shí)可供了靈活的虛擬 VIP 配置和管理功能，可以同時(shí)滿足多種應(yīng)用需求，這對于分布式的系統(tǒng)來說必不可少。 大型動態(tài)應(yīng)用系統(tǒng)又可分為幾個(gè)子系統(tǒng)： 1） Web 前端系統(tǒng) 2）負(fù)載均衡系統(tǒng) 3）數(shù)據(jù)庫集群系統(tǒng) 4）緩存系統(tǒng) 5）分布式存儲系統(tǒng) 6）分布式服務(wù)器管理系統(tǒng) 7）代碼分發(fā)系統(tǒng) Web 前端系統(tǒng) 結(jié)構(gòu)圖： 為了達(dá)到不同應(yīng)用的服務(wù)器共享、避免單點(diǎn)故障、集中管理、統(tǒng)一配置等目的，不以應(yīng)用劃分服務(wù)器，而是將所有服務(wù)器做統(tǒng)一使用，每臺服務(wù)器都可以對多個(gè)應(yīng)用提供服務(wù)，當(dāng)某些應(yīng)用訪問量升高時(shí)，通過增加服務(wù)器節(jié)點(diǎn)達(dá)到整個(gè)服務(wù)器集群的性能提高，同時(shí)使他應(yīng)用也會受益。一個(gè)主庫對應(yīng)多個(gè)從庫，主庫數(shù)據(jù)實(shí)時(shí)同步到從庫。使用正確的緩存系統(tǒng)可以達(dá)到實(shí)現(xiàn)以下目標(biāo)： 使用緩存系統(tǒng)可以提高訪問效率，提高服務(wù)器吞吐能力，改善用戶體驗(yàn)。） 分布式服務(wù)器管理系統(tǒng) 結(jié)構(gòu)圖： 隨著網(wǎng)站訪問流量的不斷增加，大多的網(wǎng)絡(luò)服務(wù)都是以負(fù)載均衡集群的方式對外提供服務(wù)，隨之集群規(guī)模的擴(kuò)大，原來基于單機(jī)的服務(wù)器管理模式已經(jīng)不能夠滿足我們的需求，新的需求必須能夠集中式的、分組的、批量的、自動化的對服務(wù)器進(jìn)行管理，能夠批量化的執(zhí)行計(jì)劃任務(wù)。 3) 我們需要實(shí)現(xiàn)源代碼管理和版本控制， SVN 可以實(shí)現(xiàn)該需求。 當(dāng)前的實(shí)際情況是，很多網(wǎng)站都是由開發(fā)人員 快速而廉價(jià)地創(chuàng)建，通常沒有任何 IT 人員或者經(jīng)理，只是由程序員來管理系統(tǒng)。這對 Java 程序來說是很嚴(yán)重的問題，在 PHP 中也會產(chǎn)生可延展性問題， 對于數(shù)據(jù)庫的負(fù)載尤其如此。但是， 如果復(fù)雜的頁面需要在每個(gè)頁面載入過程中對其進(jìn)行十次查找（這是經(jīng)常要做的），那就意味著每個(gè)頁面都要執(zhí)行10 次 SQL 查詢， 這會導(dǎo)致數(shù)據(jù)庫上很大的負(fù) 載。對于這類安 全，我們的焦點(diǎn)集中在三個(gè)安全領(lǐng)域：防火墻、運(yùn)行的用戶以及文件訪問權(quán)限。切記永遠(yuǎn)都不 要使用 Root 用戶運(yùn)行，因?yàn)檫@會讓任何闖入到 Apache 的用戶接管整個(gè)服務(wù)器。另外，每個(gè)雇員都應(yīng)該擁有自己的用戶 ID 和隨 機(jī)密碼。這有助于對系統(tǒng)進(jìn)行有效的權(quán)限管 理、備份、配置、監(jiān)控以及其他操作。在 Shell 腳本中，只需要使用 Logger 命令就可以實(shí)現(xiàn)日志的寫入。而影響數(shù)據(jù)庫性能的最大兩個(gè)問題是數(shù)據(jù)庫設(shè)計(jì)和 SQL 代碼質(zhì)量。我們見到過很多系統(tǒng)每秒會讀取 500,000 條數(shù)據(jù)， 這是出現(xiàn) SQL 問題的明顯預(yù)兆，但公司往往對其一無所知直到服務(wù)器開始崩潰。 而我們提供給客戶的最佳實(shí)踐文檔足足有 10 頁那么長。 使用類似 Memcached 之類的數(shù)據(jù)庫緩存 即便有了好的數(shù)據(jù)庫設(shè)計(jì)、 SQL 和讀寫分 離，大型的系統(tǒng)仍然需要更快的性能，特別是對會話狀態(tài)、好友列表以及 BBS 文字之類的東西。一個(gè) 5~10 臺服務(wù)器的生產(chǎn) 環(huán)境，可以很容易地在辦公室或者 IDC 中使用一臺服務(wù)器來復(fù)制，從而用于測試，而這臺服務(wù)器我們可以用于多個(gè)客戶的項(xiàng)目。本文試圖從可操作性和可靠性的角度討論最重要的幾點(diǎn)。遵 循這些規(guī)則會有 助于確保系統(tǒng)長久、良好地運(yùn)行。很多開發(fā)者都使用 SVN 或者類似的方法。但是要小心的是，不要 100%依賴于一臺 Memcache服務(wù)器來提高性能，因?yàn)槿? 果那臺服務(wù)器崩潰了，就會破壞整個(gè)系統(tǒng)的性能。 使用讀 /寫數(shù)據(jù)庫分離 隨著系統(tǒng)變得越來越龐大，特別是當(dāng)它們擁有 很差的 SQL 時(shí)，一臺數(shù)據(jù)庫服務(wù)器通常不足以處理負(fù)載。在主配置文件 中， INNODB 應(yīng)該被設(shè)置為默認(rèn)的數(shù)據(jù)庫引擎，并且系統(tǒng)應(yīng)該不時(shí)地進(jìn)行檢查，看是否意外創(chuàng)建了 MyISAM 的表。這樣的 SQL 代碼在開發(fā)環(huán)境中可能運(yùn)行很快，因?yàn)槠渲兄挥行?shù)據(jù)集和最小的負(fù)載。這樣出現(xiàn)問題的時(shí)候，查看主要的系統(tǒng)日志就可以很容易地看到發(fā)生了什么。這樣做的原因不僅僅是因?yàn)檫@些標(biāo)準(zhǔn)的路徑很重要，更應(yīng)該關(guān)注的是，恰當(dāng) 地配置服務(wù)器會將 /