大型web2.0互動網(wǎng)站設(shè)計方案

duzang123

分析mixi.jp and Yeejee.com：用開源搭建的可擴展大型SNS網(wǎng)站
總概關(guān)鍵點：

1，Mysql 切分，采用Innodb運行

2，動態(tài)Cache 服務器 –

美國Facebok.com,中國Yeejee.com,日本mixi.jp均采用開源分布式緩存服務器Memcache

3，圖片緩存和加速

Mixi目前是日本排名第三的網(wǎng)站，全球排名42，主要提供SNS服務：日記，群組，站內(nèi)消息，評論，相冊等等，是日本最大的SNS網(wǎng)站。Mixi從2003年12月份開始開發(fā)，由現(xiàn)在它的CTO - Batara Kesuma一個人焊，焊了四個月，在2004年2月份開始上線運行。兩個月后就注冊了1w用戶，日訪問量60wPV。在隨后的一年里，用戶增長到了21w，第二年，增長到了200w。到今年四月份已經(jīng)增長到370w注冊用戶，并且還在以每天1.5w人的注冊量增長。這些用戶中70%是活躍用戶（活躍用戶：三天內(nèi)至少登錄一次的用戶），平均每個用戶每周在線時間為將近3個半小時。

下面我們來看它的技術(shù)架構(gòu)。Mixi采用開源軟件作為架構(gòu)的基礎(chǔ)：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等。到目前為止已經(jīng)有100多臺MySQL數(shù)據(jù)庫服務器，并且在以每月10多臺的速度增長。Mixi的數(shù)據(jù)庫連接方式采用的是每次查詢都進行連接，而不是持久連接。數(shù)據(jù)庫大多數(shù)是以InnoDB方式運行。Mixi解決擴展問題主要依賴于對數(shù)據(jù)庫的切分。

首先進行垂直切分，按照表的內(nèi)容將不同的表劃分到不同的數(shù)據(jù)庫中。然后是水平切分，根據(jù)用戶的ID將不同用戶的內(nèi)容再劃分的不同的數(shù)據(jù)庫中，這是比較通常的做法，也很管用。劃分的關(guān)鍵還是在于應用中的實現(xiàn)，需要將操作封裝在在數(shù)據(jù)層，而盡量不影響業(yè)務層。當然完全不改變邏輯層也不可能，這時候最能檢驗以前的設(shè)計是否到位，如果以前設(shè)計的不錯，那創(chuàng)建連接的時候傳個表名，用戶ID進去差不多就解決問題了，而以前如果sql代碼到處飛，或者數(shù)據(jù)層封裝的不太好的話那就累了。

這樣做了以后并不能從根本上解決問題，尤其是對于像mixi這種SNS網(wǎng)站，頁面上往往需要引用大量的用戶信息，好友信息，圖片，文章信息，跨表，跨庫操作相當多。這個時候就需要發(fā)揮memcached的作用了，用大內(nèi)存把這些不變的數(shù)據(jù)全都緩存起來，而當修改時就通知cache過期，這樣應用層基本上就可以解決大部分問題了，只會有很小一部分請求穿透應用層，用到數(shù)據(jù)庫。Mixi的經(jīng)驗是平均每個頁面的加載時間在0.02秒左右（當然根據(jù)頁面大小情況不盡相似），可以說明這種做法是行之有效的。Mixi一共在32臺機器上有緩存服務器，每個Cache Server 2G內(nèi)存，這些Cache Server與App Server裝在一起。因為Cache Server對CPU消耗不大，而有了Cache Server的支援，App Server對內(nèi)存要求也不是太高，所以可以和平共處，更有效的利用資源。

圖片的處理就顯得相對簡單的多了。對于mixi而言，圖像主要有兩部分：一部分是經(jīng)常要使用到的，像用戶頭像，群組的頭像等等，大概有100多GB，它們被Squid和CDN所緩存，命中率相對比較高；另一部分是用戶上傳的大量照片，它們的個體訪問量相對而言比較小，命中率也比較低，使用Cache不劃算，所以對于這些照片的策略是直接在用戶上傳的時候分發(fā)到到圖片存儲服務器上，在用戶訪問的時候直接進行訪問，當然圖片的位置需要在數(shù)據(jù)庫中進行記錄，不然找不到放在哪臺服務器上就郁悶了。

國內(nèi)領(lǐng)先的SNS網(wǎng)站-采用類似的系統(tǒng)架構(gòu)，在下面的文章會進行分析對比。這是穩(wěn)定與典型的大型互動網(wǎng)站系統(tǒng)架構(gòu)，web2.0的創(chuàng)業(yè)者，在設(shè)計網(wǎng)站時，可以參考參考，少走彎路。

from: 網(wǎng)站架構(gòu)