現(xiàn)在有太多的人都做了自己的門戶型網(wǎng)站建設(shè)，那么如何交自己的網(wǎng)站運(yùn)營好呢？這個(gè)需要我們不斷的努力和不斷的創(chuàng)新策劃。

不同類型網(wǎng)站建設(shè)開發(fā)語言不同，技術(shù)支持當(dāng)然也不同，再此，北京資海網(wǎng)站建設(shè)專員同大家分享門戶型網(wǎng)站建設(shè)的必備知識(shí)點(diǎn)供參考：

門戶型網(wǎng)站建設(shè)用存儲(chǔ)過程是比較難擴(kuò)展的，這種情形多發(fā)生于傳統(tǒng)C/S，特別是OA系統(tǒng)轉(zhuǎn)換過來的開發(fā)人員。低成本網(wǎng)站不是一兩臺(tái)小型機(jī)跑一個(gè)數(shù)據(jù)庫處理所有業(yè)務(wù)的模式，是機(jī)海作戰(zhàn)。方便水平擴(kuò)展比那點(diǎn)預(yù)分析時(shí)間和網(wǎng)絡(luò)傳輸流量要重要的多的多。

為了將來圖片走cdn做準(zhǔn)備，網(wǎng)站建設(shè)最好一開始就將圖片的域名分開，且不用主域名。很多網(wǎng)站都將cookie設(shè)置到了.domain.ltd，如果圖片也在這個(gè)域名下，很可能因?yàn)?/span>cookie而造成緩存失效，并且占多余流量，還可能因?yàn)闉g覽器并發(fā)線程限制造成訪問緩慢。

門戶網(wǎng)站建設(shè)除了結(jié)構(gòu)化數(shù)據(jù)，還要經(jīng)常存放其他的數(shù)據(jù)，像圖片之類的。這類數(shù)據(jù)數(shù)量繁多、訪問量大。典型的就是圖片，從用戶頭像到用戶上傳的照片，還要生成不 同的縮略圖尺寸。存儲(chǔ)的分布幾乎跟數(shù)據(jù)庫擴(kuò)展一樣艱難。不使用專業(yè)存儲(chǔ)的情況下，基本都是靠自己的NAS。這就涉及到結(jié)構(gòu)。拿圖片存儲(chǔ)舉例，圖片是非常容 易產(chǎn)生熱點(diǎn)的，有些圖片上傳后就不再有人看，有些可能每天被訪問數(shù)十萬次，而且大量小文件的異步備份也很耗費(fèi)時(shí)間。

幾乎所有操作最后都要落到數(shù)據(jù)庫身上，它又最難擴(kuò)展（存儲(chǔ)也挺難）。對于mysql，什么樣的表用myisam，什么樣的表用innodb，在開發(fā) 之前要確定。復(fù)制策略、分片策略，也要確定。表引擎方面，一般，更新不多、不需要事務(wù)的表可以用myisam，需要行鎖定、事務(wù)支持的，用innodb。 myisam的鎖表不一定是性能低下的根源，innodb也不一定全是行鎖，具體細(xì)節(jié)要多看相關(guān)的文檔，熟悉了引擎特性才能用的更好?，F(xiàn)代WEB應(yīng)用越來 越復(fù)雜了，我們設(shè)計(jì)表結(jié)構(gòu)時(shí)常常設(shè)計(jì)很多冗余，雖然不符合傳統(tǒng)范式，但為了速度考慮還是值得的，要求高的情況下甚至要杜絕聯(lián)合查詢。編程時(shí)得多注意數(shù)據(jù)一 致性。

門戶型網(wǎng)站制作在復(fù)制策略方面，多主多從結(jié)構(gòu)也最好一開始就設(shè)計(jì)好，代碼直接按照多主多從來編寫，用一些小技巧來避免復(fù)制延時(shí)問題，并且還要解決多數(shù)據(jù)庫數(shù)據(jù)是否一致，可以自己寫或者找現(xiàn)成的運(yùn)維工具。