MocoSpace 的架构学习

NetSeek

MocoSpace.com 是一家移动社交网站，有1200多万注册用户，每个月30亿的 PV ，是美国最大的移动社区。我们来看看 MocoSpace 是如何来架构他们的网站的。先来看看他们的统计数据，注意他们只有1个系统管理员，8个程序员，14台服务器（数据和原文来自 MOCOSPACE ARCHITECTURE ? 3 BILLION MOBILE PAGE VIEWS A MONTH）：
数据

    每月30亿 PV

1.     全美第4大流量的网站，继 MySpace, Facebook, Google 之后
   
2.     75% 手机 Web, 25% Web
   
3.     1200 万用户
   
4.     每月600万独立访问
   
5.     10万在线用户
   
6.     每月上传1200万照片
   
7.     每天接受和发送450万 email
   
8.     8个程序员，2个测试员，1个系统管理员

复制代码

平台和工具

    CentOS + Red Hat

    Resin application server, Java Servlets, JavaServer Pages, Comet

    PostgreSQL

    Memcached

    ActiveMQ’s job + message queue，Red Hat 集群做 HA

    Squid 静态内容缓存，曾试过 Varnish 但是 Varnish 不稳定

    JQuery + Ajax

    S3 用来存储用户照片和视频，现在用 Amazon S3 做外部存储是主流，EC2 用来做照片处理

    F5 BigIP 负载均衡，用 gzip 压缩所有页面

    Akamai CDN，每天 2TB 数据、2.5亿次请求。

    Nagios 用来警告，Zabbix 用来监测

    EMC SAN 用大量磁盘做 RAID 10 做需要高 IO 的数据库存储，用来替代高性能的 SSD，节省了大量成本

    PowerMTA 做邮件传送，用Barracuda 做 spam 和 firewall

    Subversion 做源代码控制，Hudson 做 continuous integration

    FFMPEG 用来做视频处理

    Selenium 用来自动测试浏览器

    5x Dell 1950, 2x dual core, 16G RAM（Web 服务器）

    5x Dell 6950/R905, 4x dual core, 32G RAM（Web 服务器）

    2x Sun Fire X4600 M2 Server, 8x quad core, 256G RAM（数据库服务器）

    2x Dell 6950, 4x dual core, 64G RAM（数据库服务器）

架构

他们的网站主要是面向手机应用的，所以他们遇到的一个大挑战是如何让他们的网站在几百种（从最新的 iPhone 到古董级的 Motorola Razrs）不同的手机设备上运行，屏幕大小、缺少相应的 Web 标准等都是问题。他们在几百种不同手机的数据上抽象出了一个表现层，只要用一套代码通过一个手机数据库（包括屏幕大小、允许的文件类型、允许打开的页面大小等）把处理好的页面发到对应的手机上。

他们也是通过 shard 数据库来分担负载的，以用户 key 作为 shard 的依据，通过查找一张全局表来找到用户所在的 shard，他们自己写了查询层，可以用来在不同的 shards 之间自由查询和关联数据。他们 offline 的时候检查数据的一致性，他们认为如果不是做银行系统的话，一致性不是那么重要，牺牲一点一致性来换回性能还是值得的。他们把大表划分成了小表，这样分散了锁表带来的问题。

他们使用多级缓存，从应用服务器里的缓存到分布式 memcached，当需要更新 memcached 的数据的时候，他们通过消息发送给每台应用服务器上的缓存，以做到数据一致。他们的服务器通过分布式消息队列来通讯，比如用户实时通过发消息告诉系统需要更新缓存等。

他们用专门的服务器来打造 social graph，并都放在内存里。

他们用 Kickstart 自动安装服务器，用 Puppet 来配置服务器，web 服务器、数据库服务器、cache 服务器等。
经验

1.   * 在增加服务器之前先确定现有的服务器硬件还能不能往上升级，可以挑选一些二手的 4U 服务器。
   
2.     * 理解瓶颈在那里？是 CPU 还是磁盘、网络 IO？数据库总是有磁盘 IO 问题。
   
3.     * 扩展 web 服务器很容易也很便宜，扩展数据库服务器就很麻烦了，找出数据库系统查询最多的、查询执行时间最长的，尽早跟踪和测试这些查询找出数据库性能瓶颈。他们使用 pgFouine log analyzer 和 PostgreSQL pg_stat_statements 工具来测量。
   
4.     * 不要让用户等待，尽量在后台处理。避免异步通讯，比如数据等待积累一定程度后再一次提交给数据库；S3 存储的延迟和错误都可能会很大，把失败的请求放在队列里，等队列积累到一定程度的时候再试，而不是失败一个试一个，减少开销。
   
5.     * 在设计阶段就考虑监测系统和性能，而不是到了部署的时候才开始监测。他们试过很多监测工具，Cacti, Ganglia, Hyperic, Zabbix, Nagios 等，最重要的是要找到自己用得顺手的工具。
   
6.     * 网站变大以后就要做好防黑客、防垃圾的准备。
   
7.     * 删除可能会开销很大，尽量软删除，而且用户删错了的话软删除容易恢复。
   
8.     * N+1 设计，永远不要少于两种方案。

复制代码

NetSeek

这次架构所讲解与我们平时所遇所关注的差不多“很主流”，都是工作中切实需要注意的一些东西，也没有提什么新概。
考虑你当前架构的瓶颈，选择你认为合适的工具和技术，一些做法非常值得学习！

守住每一天

老曹又出好东西了~~ 学习

coralzd

老曹分享啊！

zuopucuen

谢谢 分享 学习了