原文轉自：http://www.example.net.cn/2006/06/mixijpsns.html
作者：于敦德 2006-6-27
mixi.jp：使用開(kāi)源軟件搭建的可擴展SNS網(wǎng)站
Mixi目前是日本排名第三的網(wǎng)站，全球排名42，主要提供SNS服務(wù)：日記，群組，站內消息，評論，相冊等等，是日本最大的SNS網(wǎng)站。Mixi從2003年12月份開(kāi)始開(kāi)發(fā)，由現在它的CTO - Batara Kesuma一個(gè)人焊，焊了四個(gè)月，在2004年2月份開(kāi)始上線(xiàn)運行。兩個(gè)月后就注冊了1w用戶(hù)，日訪(fǎng)問(wèn)量60wPV。在隨后的一年里，用戶(hù)增長(cháng)到了 21w，第二年，增長(cháng)到了200w。到今年四月份已經(jīng)增長(cháng)到370w注冊用戶(hù)，并且還在以每天1.5w人的注冊量增長(cháng)。這些用戶(hù)中70%是活躍用戶(hù)（活躍用戶(hù)：三天內至少登錄一次的用戶(hù)），平均每個(gè)用戶(hù)每周在線(xiàn)時(shí)間為將近3個(gè)半小時(shí)。
下面我們來(lái)看它的技術(shù)架構。Mixi采用開(kāi)源軟件作為架構的基礎：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等。到目前為止已經(jīng)有100多臺MySQL數據庫服務(wù)器，并且在以每月10多臺的速度增長(cháng)。Mixi的數據庫連接方式采用的是每次查詢(xún)都進(jìn)行連接，而不是持久連接。數據庫大多數是以InnoDB方式運行。Mixi解決擴展問(wèn)題主要依賴(lài)于對數據庫的切分。
首先進(jìn)行垂直切分，按照表的內容將不同的表劃分到不同的數據庫中。然后是水平切分，根據用戶(hù)的ID將不同用戶(hù)的內容再劃分的不同的數據庫中，這是比較通常的做法，也很管用。劃分的關(guān)鍵還是在于應用中的實(shí)現，需要將操作封裝在在數據層，而盡量不影響業(yè)務(wù)層。當然完全不改變邏輯層也不可能，這時(shí)候最能檢驗以前的設計是否到位，如果以前設計的不錯，那創(chuàng )建連接的時(shí)候傳個(gè)表名，用戶(hù)ID進(jìn)去差不多就解決問(wèn)題了，而以前如果sql代碼到處飛，或者數據層封裝的不太好的話(huà)那就累了。
這樣做了以后并不能從根本上解決問(wèn)題，尤其是對于像mixi這種SNS網(wǎng)站，頁(yè)面上往往需要引用大量的用戶(hù)信息，好友信息，圖片，文章信息，跨表，跨庫操作相當多。這個(gè)時(shí)候就需要發(fā)揮memcached的作用了，用大內存把這些不變的數據全都緩存起來(lái)，而當修改時(shí)就通知cache過(guò)期，這樣應用層基本上就可以解決大部分問(wèn)題了，只會(huì )有很小一部分請求穿透應用層，用到數據庫。Mixi的經(jīng)驗是平均每個(gè)頁(yè)面的加載時(shí)間在0.02秒左右（當然根據頁(yè)面大小情況不盡相似），可以說(shuō)明這種做法是行之有效的。Mixi一共在32臺機器上有緩存服務(wù)器，每個(gè)Cache Server 2G內存，這些Cache Server與App Server裝在一起。因為Cache Server對CPU消耗不大，而有了Cache Server的支援，App Server對內存要求也不是太高，所以可以和平共處，更有效的利用資源。
圖片的處理就顯得相對簡(jiǎn)單的多了。對于mixi而言，圖像主要有兩部分：一部分是經(jīng)常要使用到的，像用戶(hù)頭像，群組的頭像等等，大概有100多 GB，它們被Squid和CDN所緩存，命中率相對比較高；另一部分是用戶(hù)上傳的大量照片，它們的個(gè)體訪(fǎng)問(wèn)量相對而言比較小，命中率也比較低，使用 Cache不劃算，所以對于這些照片的策略是直接在用戶(hù)上傳的時(shí)候分發(fā)到到圖片存儲服務(wù)器上，在用戶(hù)訪(fǎng)問(wèn)的時(shí)候直接進(jìn)行訪(fǎng)問(wèn)，當然圖片的位置需要在數據庫中進(jìn)行記錄，不然找不到放在哪臺服務(wù)器上就郁悶了。
