# 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 秒。 这减少了与分区相关的问题。 * 您将常常不得不根据内容类型来制定策略。 例如，图片将与短文字帖子区别对待。 * 社交网站非常注重时间，因此按时间以及用户和类型对数据进行分区可能很有用。