# mixi.jp 體系結構 > 原文： [http://highscalability.com/blog/2007/7/10/mixijp-architecture.html](http://highscalability.com/blog/2007/7/10/mixijp-architecture.html) Mixi 是日本快速發展的社交網站。 他們提供的服務包括：日記，社區，消息，評論和相冊。 與 LiveJournal 有很多共同之處，他們還開發了許多相同的方法。 他們撰寫有關如何擴展系統的文章很容易成為目前最好的之一。 網站：http：//mixi.jp ## 信息來源 * [mixi.jp](http://www.scribd.com/doc/2684187/mixi-jp-scaling-out-with-open-source) -使用開源 ## 平臺 進行橫向擴展* 的 Linux* 阿帕奇* 的 MySQL* 佩爾* 記憶快取* 烏賊* Shard ## 里面有什么？ * 他們在兩年內增長到大約 400 萬用戶，每天增加 15,000 多新用戶。* Alexa 排名第 35 位，日本排名第 3 位。* 超過 100 臺 MySQL 服務器* 每月添加 10 臺以上的服務器* 使用非持久連接。* 日記流量為 85％的讀取和 15％的寫入。* 消息流量是 75％的讀取和 25％的寫入。* 遇到復制性能問題，因此他們不得不拆分數據庫。* 考慮按用戶垂直拆分或按表類型水平拆分。* 最終按表類型和用戶進行分區。 因此，一組用戶的所有消息都將分配給特定的數據庫。 分區鍵用于確定應在其中存儲數據庫數據。* 為了進行緩存，他們使用具有 39 臺機器 x 2 GB 內存的 memcached。* 存儲超過 8 TB 的圖像，每天添加約 23 GB。* MySQL 僅用于存儲有關圖像的元數據，而不用于存儲圖像本身。* 圖像要么經常訪問，要么很少訪問。* 使用 Squid 將經常訪問的圖像緩存在多臺計算機上。* 很少訪問的圖像從文件系統提供。 緩存它們沒有任何好處。 ## 得到教訓 * 使用動態分區時，很難選擇密鑰和算法來存儲數據。 * 對數據進行分區后，就無法再進行聯接，并且必須打開與不同數據庫的大量連接才能將數據合并回去。 * 分區時很難添加新主機并重新排列數據。 例如，假設您的分區算法在主機 1 上存儲了用戶 1-N 的所有消息。現在，假設主機 1 負擔過重，并且您想在更多主機上重新劃分用戶。 這很難做到。 * 通過使用分布式內存緩存，它們很少訪問數據庫，平均頁面加載時間約為.02 秒。 這減少了與分區相關的問題。 * 您將常常不得不根據內容類型來制定策略。 例如，圖片將與短文字帖子區別對待。 * 社交網站非常注重時間，因此按時間以及用戶和類型對數據進行分區可能很有用。