# MocoSpace Architecture-一个月有 30 亿个移动页面浏览量 > 原文： [http://highscalability.com/blog/2010/5/3/mocospace-architecture-3-billion-mobile-page-views-a-month.html](http://highscalability.com/blog/2010/5/3/mocospace-architecture-3-billion-mobile-page-views-a-month.html)  这是 [MocoSpace](http://www.mocospace.com/) 的联合创始人&首席技术官 Jamie Hall 的客座帖子，描述了他们的移动社交网络的体系结构。 这是一个及时的体系结构，因为它结合了多个热门趋势：它非常大，具有移动性和社交性。 他们认为对他们的系统特别酷的是：如何针对移动 Web 上的设备/浏览器碎片进行优化； 他们的多层，读/写，本地/分布式缓存系统； 选择 MySQL 之上的 PostgreSQL 作为可扩展的关系数据库。 MocoSpace 是一个移动社交网络，每月有 1200 万会员，页面浏览量达 30 亿，这使其成为美国流量最高的移动网站之一。 成员主要通过其手机 Web 浏览器访问该站点，从高端智能手机到低端设备以及 Web 都可以访问。 该网站上的活动包括自定义配置文件，聊天，即时消息，音乐，共享照片&，视频，游戏，电子贺卡和博客。 获利策略的重点是在移动和网站上投放广告，以及虚拟货币系统和少量高级功能升级。 ## 统计资料 1. 每月 30 亿页面浏览量 2. 仅次于 MySpace，Facebook 和 Google（http://www.groundtruth.com/mobile-is-mobile）的流量最大的 4 个移动网站 3. 75％的行动网路，25％的网路 4. 1200 万会员 5. 每月 600 万唯一身份访问者 6. 10 万个并发用户 7. 每月上传 1200 万张照片 8. 每天收到 200 万封电子邮件，垃圾邮件 90％，每天发送 250 万封 9. 8 位开发人员，2 位质量检查人员和 1 位系统管理员组成的团队 ## 平台 1. CentOS +红帽 2. 树脂应用服务器-Java Servlet，JavaServer Pages，Comet 3. PostgreSQL 的 4. 记忆快取 5. ActiveMQ 的工作+消息队列，在 Red Hat 集群中以实现高可用性 6. Squid-静态内容缓存，尝试使用 Varnish 但存在稳定性问题 7. jQuery + Ajax 8. S3 用于用户照片&视频存储（8 TB），EC2 用于照片处理 9. F5 BigIP 负载平衡器-粘性会话，所有页面上的 gzip 压缩 10. Akamai CDN-每天 2 TB，每天有 2.5 亿个请求 11. 监视-Nagios 发出警报，Zabbix 发出趋势 12. EMC SAN-通过 RAID（RAID 10）大量磁盘为数据库提供高 IO 性能，用高性能 Fusion-io 固态闪存 ioDrive 代替，成本效益更高 13. PowerMTA 用于邮件传递，梭子鱼垃圾邮件防火墙 14. Subversion 源代码控制，Hudson 进行持续集成 15. FFMPEG 用于移动到 Web 和 Web 到移动视频的转码 16. 用于浏览器测试用例自动化的硒 17. 网络层 1. 5 个 Dell 1950、2 个双核，16G RAM 2. 5 个 Dell 6950 / R905、4 个双核，32G RAM 18. 数据库层 1. 2 个 Sun Fire X4600 M2 服务器，8 个四核，256G RAM 2. 2 个 Dell 6950、4 个双核，64G RAM ## 建筑 1. 所有页面都是动态的，具有用户数据和自定义以及许多针对浏览器和设备的优化。 移动设备上的浏览器和设备碎片问题比 Web 上的问题要严重得多。 许多优化，基于浏览器功能的改编，对 CSS / JavaScript 的有限支持，屏幕尺寸等。移动 Web 流量通常通过网络代理（网关）提供，而对 Cookie 的支持较差，因此会话管理和用户标识成为一个挑战。 2. 一个巨大的挑战是处理移动 Web 上的设备/浏览器碎片-为各种设备功能进行优化（从带触摸屏的 iPhone 到 5 岁摩托罗拉 Razrs 的所有产品），屏幕尺寸，缺乏/不一致的 Web 标准合规性等。 我们将表示层抽象出来，以便我们可以从同一代码库向所有移动设备提供页面，并维护一个大型设备功能数据库（包含诸如屏幕尺寸，支持的文件类型，最大允许的页面尺寸等内容），用于 推动我们网页的生成。 该数据库包含数百种设备和移动浏览器类型的功能详细信息。 3. 根据用户密钥对数据库进行分片，并具有将用户映射到分片的主查询表。 我们滚动了自己的查询和聚合层，使我们可以跨碎片查询和联接数据，尽管这种方式并不经常使用。 通过分片，我们可以牺牲一些一致性，但是只要您不经营银行就可以。 我们分批离线进行数据一致性检查，目标是最终实现一致性。 大表被分成较小的子表，以提高访问效率，减少了为更新和操作维护活动而锁定表的时间。 用于热备份的日志传送。 4. 使用了多层缓存系统，数据在应用程序服务器中本地缓存，并通过 Memcached 分发。 进行更新时，我们不仅使缓存无效，然后在再次从数据库中读取后重新填充缓存，而是使用新数据更新 Memcached 并保存另一次数据库访问。 更新缓存时，无效指令会通过消息队列发送到每个应用程序服务器上的本地缓存。 5. 分布式消息队列用于分布式服务器通信，从用户之间实时发送消息到系统消息（例如本地缓存无效指令），应有尽有。 6. 专用服务器，用于完全在内存中构建和遍历社交图，用于生成好友推荐等。 7. 负载平衡器，用于在不影响性能/流量的情况下滚动部署网站的新版本。 8. 每 2 周发布一次。 较长的发布周期=指数复杂性，更难进行故障排除和回滚。 负责部署和管理生产系统的开发团队（由您构建，管理）。 9. Kickstart 用于自动从裸机构建服务器。 Puppet 用于将服务器配置为特定的个性，即 Web 服务器，数据库服务器，缓存服务器等，以及将更新的策略推送到正在运行的节点。 ## 得到教训 1. **让您的箱子流汗**。 只要响应时间可以接受，就不要担心系统负载过大。 我们将多达五个应用程序服务器实例包装在一个盒子中，每个实例在不同的端口上运行。 在扩展之前，请先扩展到高端商品硬件。 可以廉价购买二手或翻新的强大 4U 盒子。 2. **了解您的瓶颈在各个层次中的位置**。 您是否绑定了 CPU 或 IO（磁盘，网络）？ 数据库几乎总是受 IO（磁盘）约束。 一旦数据库无法容纳在 RAM 中，您就会碰壁。 3. **认真地配置数据库**。 专注于优化数据库。 扩展 Web 层既便宜又容易，而数据库层则又困难又昂贵。 通过执行时间和执行频率，了解系统上最重要的查询。 跟踪和基准化每个版本的主要查询，需要及早发现并解决数据库的性能问题。 我们使用 pgFouine 日志分析器和新的 PostgreSQL pg_stat_statements 实用程序实时生成概要分析快照。 4. **设计为禁用**。 能够配置和关闭即时发布的任何内容，而无需更改或部署代码。 负载和压力测试很重要，但没有什么比通过逐步分阶段推出的实时生产流量进行测试了。 5. **仅在绝对必要时才进行同步通信**。 当一个组件或服务发生故障时，不应关闭系统的其他部分。 在后台或作为单独的线程或进程来做您可以做的所有事情，不要让用户等待。 尽可能批量更新数据库。 任何在网络外部发出请求的系统都需要主动监控，超时设置以及故障处理/重试。 例如，我们发现 S3 延迟和故障率可能很高，因此我们将失败的呼叫排队，然后重试。 6. **考虑在设计期间进行监视，而不是在**之后进行监视。 每个组件都应产生性能，运行状况，吞吐量等数据。 当警报超过阈值时设置警报。 显示所有实例（而不是每个实例）的指标的综合图表对于一目了然地发现问题和趋势特别有帮助，应该每天进行检查-如果不能很好地理解正常的操作行为，则无法识别和应对不正常的情况。 t。 我们尝试了许多监视系统-仙人掌，神经节，Hyperic，Zabbix，Nagios，以及一些定制的解决方案。 无论您使用哪个最重要的东西，都要对它感到舒服，否则您将不会足够使用它。 使用模板等可以轻松监视新包装盒和服务，并在放置它们时迅速进行。 7. **分布式会话可能会产生很多开销**。 只要有可能就进入无状态状态，但是当您不考虑粘性会话时。 如果服务器发生故障，用户将丢失其状态，可能需要重新登录，但这很少见并且可以接受，具体取决于您需要执行的操作。 8. **监视并提防 Java** 中的全部/主要垃圾回收事件，该事件最多可以锁定整个 JVM 30 秒。 我们使用并发标记扫描（CMS）垃圾收集器，该垃圾收集器引入了一些额外的系统开销，但能够消除完整的垃圾收集。 9. 当站点足够大时，无论是站点内部还是外部，通过电子邮件等，它都会吸引垃圾邮件散布者和黑客，而 Captcha 和 IP 监视是不够的。 必须**积极投资于检测和围堵系统**，这是检测可疑用户行为并发出警报和/或尝试自动围堵的内部工具。 10. **尽可能软删除**。 将数据标记为以后删除，而不是立即删除。 删除的成本可能很高，因此要花几个小时才能排队，此外，如果有人犯了一个错误并删除了他们不应该拥有的东西，那么回滚很容易。 11. **N + 1 设计**。 不得少于两个。 我非常感谢 Jamie 花时间编写此体验报告。 这是对其他人学习的真正有用的贡献。 如果您想共享 fablous 系统的体系结构，请 [与联系我](../../contact/)，我们将开始。 ## 相关文章 * [移动社交网络 MocoSpace 现已拥有 1100 万会员](http://techcrunch.com/2010/03/17/mobile-social-network-mocospace-now-11-million-members-strong/ "Mobile Social Network MocoSpace Now 11 Million Members Strong") * [MocoSpace 的工作方式](http://computer.howstuffworks.com/internet/social-networking/networks/mocospace.htm) 我想知道 ActiveMQ 工作意味着什么？ 很棒的帖子。 这是我们真正了解战 the 的帖子。 保持良好的工作。 费利佩 我很好奇为什么 Sun Fire 支持数据库？ 关于第 7 课：粘性会议更好？ 通过将用户锁定到特定服务器，您是否限制了更有效地进行负载平衡的能力？ 你们有 10 台 Web 服务器。 粗略地说，如果您丢失一台服务器，则会损失 10％的容量，并且 10％的当前访问者将丢失会话。 使用无粘性设置，如果您丢失一台服务器，则只会丢失 10％的容量，但不会有用户丢失会话。 从负载平衡设置中删除服务器将更加容易。 您正在使用 F5 进行哪种负载均衡？ 愚蠢的循环赛吗？ 还是从每个服务器收集更具体的指标并基于此加载？ 您是将客户端连接一直传递到每​​个 Web 服务器，还是将 F5 用作反向代理？ 您在哪里进行 ffmpeg 编码？ 在那些列出的服务器上还是其他地方？ 你们为什么要选择 Zabbix 和 Nagios？ 为什么其他解决方案对您不起作用？ 您在地理上分布吗？ 如果您在某些方面使用 S3 和 EC2，为什么不将其余基础架构移至亚马逊或其他云呢？ 即使有所有缓存，你们还是需要 Fusion-io 吗？ 这真的是非常有用的帖子。 感谢您分享这一点。 是什么让他们选择了 PostgreSQL 而不是 MySQL？ 使用了什么标准？ 他们使用任何 Java 框架吗？ 最好的祝福 @Maxim R 1.我们不在地理上分布 2\. F5 是基于会话的负载平衡。 有许多 iRules 导致一些流量直接传递到 Web 服务器，从 F5 缓存提供服务，或从 Squid 缓存提供服务 3\. ffmpeg 编码在批处理服务器 上完成。4\. S3 和 EC2 相当 昂贵。 我们可以从戴尔购买一个全新的盒子，然后在几个月内拿回我们的钱，而不是几个大型实例。 由于我们不必处理“嘈杂的邻居” ，因此性能也更可预测。5。显然，使用分布式会话将为我们提供更大的灵活性，但是会带来较大的开销。 使用粘性会话是/有中间立场。 6.关于 Fusion-IO，所有页面都是动态创建的，因此我们需要很高的 I / O 吞吐量。 随着站点的增长，I / O 要求也随之提高。 您曾想过[哇，这些家伙看起来不错/专业]直到 `Development team responsible for deploying to and managing production systems "you built it, you manage it"` 部分。 如果我是你，我会在投资者会议上保密。