# 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 秒。 这减少了与分区相关的问题。

    *   您将常常不得不根据内容类型来制定策略。 例如，图片将与短文字帖子区别对待。

    *   社交网站非常注重时间，因此按时间以及用户和类型对数据进行分区可能很有用。