了解 Instagram 背后的技术

刚被 Facebook 以 10 亿美金收购的著名手机照片分享应用 Instagram 最近吸引了无数人的眼球， Android 版本登陆 Google Play 不到一个月下载量就突破 1000 万，总用户数即将超过 5000 万。Instagram 联合创始人 Mike Krieger 说他们用了8 周时间打造了最初的Instagram ，但现在的系统肯定已经今非昔比。Instagram 技术团队曾发表过一篇文章，介绍了Instagram 背后的技术，日前Mike Krieger 在名为 Scaling Instagram 的演讲里，又介绍了更多细节，让人们能了解到 5 名技术人员是如何支撑起整个系统的。

一张照片上传的过程是这样的：

1. 采用同步的方式写入媒体数据库
2. 如果照片上有地理位置标签，则以异步的方式将照片提交给 Solr 进行索引
3. 将照片的 ID 加入每个关注者的列表里，该列表保存在 Redis 之中
4. 在显示 Feed 时，选取一小部分照片 ID，在 Memcached 里进行查询

在设计系统时，Instagram 的设计哲学是简单、为最小化运维负担进行优化并监控一切内容；其核心原则是保持简单，不要重复发明轮子，尽可能使用经过验证、稳定可靠的技术。

由于只有 5 名技术人员（其中仅 2.5 名后端工程师），精力有限，选择 Amazon 的云服务是个不错的选择。目前他们使用了超过 100 个 **EC2实例用于提供各种服务，运行的操作系统是 Ubuntu 11.04，之前的一些版本在高流量时表现不够稳定。在负载均衡方面，他们使用 Amazon 的Elastic Load Balancer实现负载均衡，后端运行了 3 个 Nginx 实例，SSL 只到 ELB 上为止，降低了 Nginx 上的 CPU 负载。DNS 和 CDN 分别由 Amazon 的Route 53和CloudFront提供，所有的照片都存放在S3** 上，目前已经有几 TB 的规模了。

用于处理请求的应用服务器运行于 **Amazon High-CPU Extra-Large Instance** 之上，由于他们的请求更多是 CPU 密集型的，因此这能更好地平衡 CPU 与内存。采用的开发框架是 Django ，WSGI 服务器是 Gunicorn ，通过 Fabric 在所有机器上进行并行部署，一次部署仅需几秒钟。

大多数数据都存放在 PostgreSQL 里，主分片集群运行于 12 个 **High-Memory Quadruple Extra-Large Instance（68.4GB 内存）上，另有 12 个位于不同可用区里的副本，通过 repmgr 以 Streaming Replication 的方式进行同步。由于Elastic Block Store** 的磁盘 IOPS 不高，因此需要将正在使用的数据都加载到内存里， vmtouch 能帮助管理内存中的数据。他们在 EBS 上使用 mdadm 实现了软件 Raid，以此提升写吞吐量；数据库的文件系统用的是 XFS，在从库获取快照时，会先冻结 RAID 阵列，保证快照的一致性。

应用程序在连接数据库时，由 Pgbouncer 建立连接池。目前，Instagram 的数据按照用户 ID 进行分片，某些分片可能会超出物理节点的容量上限，为此他们将数据分成了很多个逻辑分片，映射到少数几个物理节点之上；当一个节点被填满之后，可以将某些逻辑分片移到别的节点上，以缓解该节点的压力。随着数据量的增长，以后他们也会进行垂直分区，Django DB Router 能让一切轻松不少。

Instagram 也大量使用 Redis 来存放复杂的对象（对象的大小做了一定的限制），用于主 Feed、活动 Feed、会话系统及其他相关系统。因为要将Redis 的所有数据都放在内存里，此处同样也用了** High-Memory Quadruple Extra-Large Instance**，并对数据做了分片。当 Redis 实例的请求达到 4 万 / 秒后，它渐渐成为了瓶颈，于是 Redis 也做了主从复制，副本的数据会经常导出到磁盘上，通过 EBS 快照进行备份。

除了 Redis，他们还使用 Memcached 来做缓存，目前运行了 6 个实例，应用服务器通过 pylibmc 和 libmemcached 进行连接。虽然 Amazon 提供了 Elastic Cache 服务，但该服务的价格并不便宜，相比之下，还是运行自己的 Memcached 实例比较划算。异步任务队列使用的是 Gearman ，目前有大约 200 个工作进程来处理各种任务，比如把照片分享到 Twitter 和 Facebook，通知用户有新照片等等。 Pyapns 已经处理了十亿的推送通知，非常稳定，他们还自己开发了基于 Node.js 的 node2dm ，用于向 Android 设备发送推送通知。

监控方面，Instagram 使用 Munin 以图形化的方式呈现整个系统的运行状况，还通过 Python-Munin 定制了一些插件，用来显示业务数据；网络守护进程 Stated 可以实时收集数据并做汇总； Dogslow 会监控进程，一旦发现运行时间过长的进程，便会保存该进程的快照，以便后续分析，比如响应时间超过 1.5 秒的请求，通常都是卡在 Memcached 的 set() 和 get_many() 方法上。对于 Python 的错误，只要登上 Sentry 就能实时获取错误信息。

HighScalability 上还根据整理 Mike Krieger 的演讲整理了一些值得借鉴的经验，比如：

• 找那些你熟悉的技术和工具，在简单的使用场景里先做一些尝试
• 不要使用两个工具来处理同样的任务
• 事先准备降级方案，以便在需要时降低负载
• 不要过度优化，或者希望能事先知道站点要扩展，对于一个初创的社交站点而言，没什么扩展性问题是解决不了的
• 如果一个办法不行，赶快换下一个

如果您想进一步了解 Instagram 背后的技术细节，可以访问其技术团队的博客。