移动社交社区MocoSpace的架构

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

数据

每月30亿 PV
全美第4大流量的网站，继 MySpace, Facebook, Google 之后
75% 手机 Web, 25% Web
1200 万用户
每月600万独立访问
10万在线用户
每月上传1200万照片
每天接受和发送450万 email
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 服务器等。

经验

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