mixi.jp：使用開源軟體搭建的可擴充套件SNS網站

　　首先進行垂直切分，按照表的內容將不同的表劃分到不同的資料庫中。然後是水平切分，根據使用者的ID將不同使用者的內容再劃分的不同的資料庫中，這是比較通常的做法，也很管用。劃分的關鍵還是在於應用中的實現，需要將操作封裝在在資料層，而儘量不影響業務層。當然完全不改變邏輯層也不可能，這時候最能檢驗以前的設計是否到位，如果以前設計的不錯，那建立連線的時候傳個表名，使用者ID進去差不多就解決問題了，而以前如果sql程式碼到處飛，或者資料層封裝的不太好的話那就累了。

　　這樣做了以後並不能從根本上解決問題，尤其是對於像mixi這種SNS網站，頁面上往往需要引用大量的使用者資訊，好友資訊，圖片，文章資訊，跨表，跨庫操作相當多。這個時候就需要發揮memcached的作用了，用大記憶體把這些不變的資料全都快取起來，而當修改時就通知cache過期，這樣應用層基本上就可以解決大部分問題了，只會有很小一部分請求穿透應用層，用到資料庫。Mixi的經驗是平均每個頁面的載入時間在0.02秒左右（當然根據頁面大小情況不盡相似），可以說明這種做法是行之有效的。Mixi一共在32臺機器上有快取伺服器，每個Cache Server 2G記憶體，這些Cache Server與App Server裝在一起。因為Cache Server對CPU消耗不大，而有了Cache Server的支援，App Server對記憶體要求也不是太高，所以可以和平共處，更有效的利用資源。

　　圖片的處理就顯得相對簡單的多了。對於mixi而言，影像主要有兩部分：一部分是經常要使用到的，像使用者頭像，群組的頭像等等，大概有100多GB，它們被Squid和CDN所快取，命中率相對比較高；另一部分是使用者上傳的大量照片，它們的個體訪問量相對而言比較小，命中率也比較低，使用Cache不划算，所以對於這些照片的策略是直接在使用者上傳的時候分發到到圖片儲存伺服器上，在使用者訪問的時候直接進行訪問，當然圖片的位置需要在資料庫中進行記錄，不然找不到放在哪臺伺服器上就鬱悶了。