試談百萬(wàn)級(jí)訪問網(wǎng)站前期的技術(shù)準(zhǔn)備(編輯修改稿)
2025-08-10 02:12 本頁(yè)面
【文章內(nèi)容簡(jiǎn)介】 能用的更好?，F(xiàn)代WEB應(yīng)用越來(lái) 越復(fù)雜了，我們?cè)O(shè)計(jì)表結(jié)構(gòu)時(shí)常常設(shè)計(jì)很多冗余，雖然不符合傳統(tǒng)范式，但為了速度考慮還是值得的，要求高的情況下甚至要杜絕聯(lián)合查詢。編程時(shí)得多注意數(shù)據(jù)一 致性。復(fù)制策略方面，多主多從結(jié)構(gòu)也最好一開始就設(shè)計(jì)好，代碼直接按照多主多從來(lái)編寫，用一些小技巧來(lái)避免復(fù)制延時(shí)問題，并且還要解決多數(shù)據(jù)庫(kù)數(shù)據(jù)是否一致，可以自己寫或者找現(xiàn)成的運(yùn)維工具。分片策略?？倳?huì)有那么幾個(gè)表數(shù)據(jù)量超大，這時(shí)分片必不可免。分片有很多策略，從簡(jiǎn)單的分區(qū)到根據(jù)熱度自動(dòng)調(diào)整，依照具體業(yè)務(wù)選擇一個(gè)適合自己的。避免自增ID作為主鍵，不利于分片。用存儲(chǔ)過程是比較難擴(kuò)展的，這種情形多發(fā)生于傳統(tǒng)C/S，特別是OA系統(tǒng)轉(zhuǎn)換過來(lái)的開發(fā)人員。低成本網(wǎng)站不是一兩臺(tái)小型機(jī)跑一個(gè)數(shù)據(jù)庫(kù)處理所有業(yè)務(wù)的模式，是機(jī)海作戰(zhàn)。方便水平擴(kuò)展比那點(diǎn)預(yù)分析時(shí)間和網(wǎng)絡(luò)傳輸流量要重要的多的多。NoSQL。這只是一個(gè)概念。實(shí)際應(yīng)用中，網(wǎng)站有著越來(lái)越多的密集寫操作、上億的簡(jiǎn)單關(guān)系數(shù)據(jù)讀取、熱備等，這都不是傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)所擅長(zhǎng)的，于是 就產(chǎn)生了很多非關(guān)系型數(shù)據(jù)庫(kù)，比如Redis/TCamp。TT/MongoDB/Memcachedb等，在測(cè)試中，這些幾乎都達(dá)到了每秒至少一萬(wàn)次 的寫操作，內(nèi)存型的甚至5萬(wàn)以上。例如MongoDB，幾句配置就可以組建一個(gè)復(fù)制+自動(dòng)分片+failover的環(huán)境，文檔化的存儲(chǔ)也簡(jiǎn)化了傳統(tǒng)設(shè)計(jì)庫(kù) 結(jié)構(gòu)再開發(fā)的模式。很多業(yè)務(wù)是可以用這類數(shù)據(jù)庫(kù)來(lái)替代mysql的。八、緩存。數(shù)據(jù)庫(kù)很脆弱，一定要有緩存在前面擋著，其實(shí)我們優(yōu)化速度，幾乎就是優(yōu)化緩存，能用緩存的地方，就不要再跑到后端數(shù)據(jù)庫(kù)那折騰。緩存有持久化緩存、 內(nèi)存緩存，生成靜態(tài)頁(yè)面是最容易理解的持久化緩存了，還有很多比如varnish的分塊緩存、前面提到的memcachedb等，內(nèi)存緩 存，memcached首當(dāng)其沖。緩存更新可用被動(dòng)更新和主動(dòng)更新。被動(dòng)更新的好處是設(shè)計(jì)簡(jiǎn)單，緩存空了就自動(dòng)去數(shù)據(jù)庫(kù)取數(shù)據(jù)再把緩存填上，但容易引發(fā)雪 崩效應(yīng)，一旦緩存大面積失效，數(shù)據(jù)庫(kù)的壓力直線上升很可能掛掉。主動(dòng)緩存可避免這點(diǎn)但是可能引發(fā)程序取不到數(shù)據(jù)的問題。這兩者之間如何配合，程序設(shè)計(jì)要多 動(dòng)腦筋。九、隊(duì)列。用戶一個(gè)操作很可能引發(fā)一系列資源和功能的調(diào)動(dòng)，這些調(diào)動(dòng)如果同時(shí)發(fā)生，壓力無(wú)法控制，用戶體驗(yàn)也不好，可以把這樣一些操作放入隊(duì)列，由另幾個(gè)模塊 去異步執(zhí)行，例如發(fā)送郵件，發(fā)送手機(jī)短信。開源隊(duì)列服務(wù)器很多，性能要求不高用數(shù)據(jù)庫(kù)當(dāng)做隊(duì)列也可以，只要保證程序讀寫隊(duì)列的接口不變，底層隊(duì)列服務(wù)可隨 時(shí)更換就可以，類似Zend Framework里的Zend_Queue類。十、文件存儲(chǔ)。除了結(jié)構(gòu)化數(shù)據(jù)，我們經(jīng)常要存放其他的數(shù)據(jù)，像圖片之類的。這類數(shù)據(jù)數(shù)量繁多、訪問量大。典型的就是圖片，從用戶頭像到用戶上傳的照片，還要生成不 同的縮略圖尺寸。存儲(chǔ)的分布幾乎跟數(shù)據(jù)庫(kù)擴(kuò)展一樣艱難。不使用專業(yè)存儲(chǔ)的情況下，基本都是靠自己的NAS。這就涉及到結(jié)構(gòu)。拿圖片存儲(chǔ)舉例，圖片是非常容 易產(chǎn)生熱點(diǎn)的，有些圖片上傳后就不再有人看，有些可能每天被訪問數(shù)十萬(wàn)次，而且大量小文件的異步備份也很耗費(fèi)時(shí)間。為了將來(lái)圖片走cdn做準(zhǔn)備，一開始最好就將圖片的域名分開，且不用主域名。，如果圖片也在這個(gè)域名下，很可能因?yàn)閏ookie而造成緩存失效，并且占多余流量，還可能因?yàn)闉g覽器并發(fā)線程限制造成訪問緩慢。如果用普通的文件系統(tǒng)存儲(chǔ)圖片，有一個(gè)簡(jiǎn)單的方法。計(jì)算文件的hash值，比如md5，以結(jié)果第一位作為第一級(jí)目錄，這樣第一級(jí)有16個(gè)目錄。從0 到F，可以把這個(gè)字母作為域名，（客戶端dns壓力會(huì)增大），還可以擴(kuò)展到最多16個(gè)NAS集群 上。第二級(jí)可用年月例如，201011，第三級(jí)用日，第四級(jí)可選，根據(jù)上傳量，比如am/pm，甚至小時(shí)。最終的目錄結(jié)構(gòu)可能會(huì)是 e/201008/25/am/。rsync備份時(shí)可以用腳本只同步某年某日某時(shí)的文件，避免計(jì) 算大量文件帶來(lái)的開銷。當(dāng)然最好是能用專門的分布式文件系統(tǒng)或更專業(yè)點(diǎn)的存儲(chǔ)解決方案。
外語(yǔ)相關(guān)推薦
鄂ICP備17016276號(hào)-1