推薦：站長的樸實 站長的共鳴
不說話的站長 租一間房子，拉一條網線，借錢買一臺電腦，很多個人站長就這樣開始了自己的站長生涯。 站長是沒有早晨的，當早市上人潮洶涌的時候，他們才剛剛入睡，在夢中他們擁著QQ上那個遠方的女孩，假如這時候有人在他們旁邊，定會看到他們臉上燦爛的笑臉。 中午醒來

當互聯網吵吵嚷嚷的進入2.0時代，當互聯網的技術不再是那么高不可攀，當復制變成家常便飯，互聯網熱鬧起來了

Myspace火了，中國冒出更多的myspace

Youtube剛剛起來，中國的視頻網站就遍地開花

51拔地而起，中國出了無數的SNS

facebook則改變了中國站長的抄襲方式，不再學chianren了，校內火了

..........

當抄襲變成習慣，我想說的是，模擬，站長，你預備好了嗎？

假如你打算做垃圾站，或者賺點廣告費的網站，請不要點擊這篇文章，我從技術角度方面談談WEB2.0網站的模擬問題。

當投資和流量都不是問題的時候，我想說的是，您真的一帆風順嗎？

拿SNS網站來說，當匆匆上線的2.0，當一筆筆投資砸進去的時候，當流量上去的時候，您的困惑在什么地方？

我做過多個2.0公司的技術顧問，簡單的談談2.0公司碰到的問題(涉及隱私，我用A B C D代替)，這里就不再贅述大家眾所周知的頁面靜態化，緩存和代碼安全等問題了，有點技術的2.0公司的CTO都知道這些東西，我們談點發展之后的問題

A公司

A公司做的是SNS網站，程序是兩個毛頭小伙子做的，目標直指51，程序開發是一帆風順，功能也比51牛多了，推廣也是一帆風順（A公司有自己獨到的推廣方式。但是當ALEXA到2W的時候問題出來了，天天下午4點左右，網站速度慢的驚人，基本上打不開，公司三臺服務器CPU100%，讓人郁悶的是公司的網絡配置方式，居然是雙WEB的集群，而單獨一臺DB數據庫。整個瓶頸在數據庫，于是我建議做DB的集群，分析了一下數據結構，MD，典型的WEB程序員的作品，沒有一點數據庫設計規范，功能實現是可以，假如要擴展，不可能，集群基本上是不可能的，怎么辦？不能辦，于是，一個月的時間修改程序，數據結構基本上換了一遍 前期砸進去的幾十萬打了水飄，用戶走光了。

結論：WEB2.0前期設計的時候不應該只考慮功能，應該認真考慮一下底層和數據結構了。

B公司

B公司也是做的SNS網站，程序是3個人開發的，CEO是某名牌大學的經濟學碩士，有點知己網的味道，又有一些特色出來，說實話，公司的潛力不錯，CEO有很強的運作能力，感覺前景不錯。系統架構還行，但是---但是系統崩潰了，why?系統沒有考慮到用戶有個海量的說法，文件也有個海量的說法，用戶的相冊，圖片全部存貯在WEB服務器的一個分區上，每個用戶一個目錄，而打開性能監視器，磁盤的IO高的驚人，基本上無暇響應。眾所周知，文件系統也是一個數據庫，單獨大文件無所謂，要害是整個是300多個G的零碎文件，大量的讀寫操作，系統崩潰，數據丟失，文件系統的一個鏈斷了，用戶數據全部丟失！！！這是一個非常沉重的問題，系統整整停了一個月來做數據恢復（單獨文件很輕易，但是海量文件目前還沒有一個軟件能組織起來軟件架構）。解決方案：修改程序架構，做分布式文件存貯（程序修改用了8天，但是文件轉移卻又用去了將近一個月），20萬用戶損失殆盡。

結論：WEB2.0前期的設計應該有應付海量存貯的考慮，整個涉及了程序架構的修改，前期規劃不好的話基本上思路一條。

C公司

C公司是一個值得尊敬的公司，CEO技術出身，和比爾蓋茨一樣，大學未畢業出來做網絡，01到03年做短信狠賺了一筆，后來做的小項目也小有所成，說實話，我很佩服。公司做的是校友方面，但是更偏重myspace風格，注重個人主頁，推廣方面也下了大手筆。系統崩潰的原因其實很簡單，由于采用的是微軟的SqlServer，而微軟直接就告訴了我們，SQLSERVER不支持集群，他們的數據庫超負載，100%就沒有下去過，只能橫向增加配置，采用了4路4核CPU系統，但是系統還是崩潰了... 高互動注定了高負載。解決方案： 現從基本入手，解決掉幾個程序耗能大戶，對數據庫采用橫向切割，將用戶每10萬進行分組，同時對數據庫系統進行散列，將多個表垂直分割，同時進行文件分組 ，解決問題. 因為修改了數據結構，程序也基本上大動了一下。 好在系統沒有出大錯，損失不算很大，不過對用戶體驗造成了很壞的影響。

分享：什么是垂直搜索？
垂直搜索是針對某一個行業的專業搜索引擎，是搜索引擎的細分和延伸，是對網頁庫中的某類專門的信息進行一次整合，定向分字段抽取出需要的數據進行處理后再以某種形式返回給用戶。 垂直搜索引擎和普通的網頁搜索引擎的最大區別是對網頁信息進行了結構化信息抽取，也就是