Instagram的技术探索（转）

add by zhj: 略有修改

原文：http://www.cnblogs.com/xiekeli/archive/2012/05/28/2520770.html

前一篇翻译了Instagram blog上的一篇文章《What Powers Instagram: Hundreds of Instances, Dozens of Technologies》，让我们对Instagram 的大致技术路线有了一个大体的了解。我觉得Instagram 的工程师能够在Instagram blog上将自己使用的技术和工具进行分享，真是难能可贵。同时，在网上看到了一份Mike Krieger在“AirBnB Tech Talk 2012”上演讲的PPT，见"Instagram创始人：Instagram是如何扩展的.pdf"，感觉受益匪浅，有必要整理学习。

• 相关统计

用户规模：30+ million users in less than 2 years（不到2年时间，3000多万用户，注：在他们发布android版本后的10天已经突破4000万了）

在发布android版本的12个小时里，他们就新增了100万用户

• 创建初期

两个联合创始人没有任何后端的实战经验（这也太…）

：）就是这两小子

注：

Mike Kriegerr：之前是一个颇为低调的工程师和用户体验设计师，他在一家名叫Meebo的创业公司工作了1年半。analytics & python @ meebo（在Meebo做分析，使用python ）；

Kevin Systrom： 毕业后在Google的收购部门工作了一年，今年28岁，随后去到了一家从事旅行业务的创业公司Nextstop，没有计算机学位，没有接受过正式培训， 但他下班后坚持自学编程，在这家创业公司被Facebook以人才收购的方式收购后，Systrom又去早期的Twitter实习了一段时间。

最初存储采用CouchDB（Apache CouchDB 是一个面向文档的数据库管理系统）

最初只有一台服务器（在洛杉矶），比一台比MacBook Pro强不到哪里去。

上线第一天有25000注册用户。

上线初期的问题（总是些微不足道的问题）：

1、favicon.ico ：因为忘记favicon.ico图标文件，在Django上引起大量404错误；

2、ulimit -n ，设置Linux内核可以同时打开的文件描述符的最大值，例如size为4092。

3、memcached -t 4，设置用于处理请求的线程数.

4、prefork/postfork 线程的预加载还是后加载问题，类似于线程池吧？

• 技术迁徙

let’s move to EC2，系统扩展就像对100码速度行驶的汽车更换所有部件；

                       

• Instagram 的哲学

保持简单
为了最小的运营负担而优化程序
利用一切能用到的工具

• 一、数据库扩展

早期使用django ORM+postgresql，因为PostGIS，选择了postgresql。（PostGIS在对象关系型数据库PostgreSQL上增加了存储管理空间数据的能力，相当于Oracle的spatial部分）并且数据库部署在独立服务器上。

因为EC2机器的最大内存为68G，随着照片存储量的增加，进行垂直分区（vertical partitioning）；

使用django db routers，做垂直分区变得很容易；如下：照片则映射到photodb

def db_for_read(self, model):
  if app_label == 'photos':
    return 'photodb'

当照片存储量大于60G的时候，采用水平分区（也就是所谓的“分片”sharding）

sharding带来的问题：

1、数据的检索，hard to know what your primary access patterns will be w/out any usage in most cases, user ID

2、当有分片变得太大的时候怎么办？

基于范围的分片策略（就像MongoDB那样）

       

3、性能有下降趋势，尤其在EC2上，原因：disk IO，解决方法：预先切分（pre-split），即预先切分上千个逻辑切片，将它们映射到较少的物理分区节点中去。

关于相关内容，更详细的可以参看这里；

• 二、选择合适工具

进行缓存/反规范化数据设计

用户上传图片时：

1、用户上传带有标题信息和地理位置信息（可选）的照片；

2、同步写到这个用户对应的数据库（分片）中；

3、进行队列化处理

a、如果带有地理位置信息，通过异步的POST请求，将这个图片的信息送到Solr（Instagram 用于geo-search API的全文检索服务器）。

b、跟随者的信息分发（follower delivery），即告诉我的follower ，我发布了新的照片。如何来实现的呢？每个用户都有一个follower 列表，新照片上传时会把照片ID发送给列表中的每一个用户，用Redis 来处理这一业务简直太棒了，快速插入，快速子集化（rapid subsets，什么意思？是指获取部分数据吗）

c、when time to render a feed,we take small # of IDs, go look up info in memcached（当需要生成feed的时候，我们通过ID+#的格式，直接在memcached中查找信息）

Redis适合什么样的场景：

1、数据结构相对有限；

2、对频繁GET的地方，对复杂对象进行缓存；

不要将自己绑定在非得以内存数据库为主要存储策略的方案上（don’t tie yourself to a solution where your in-memory DB is your main data store

关于Follow图谱

第一版：简单的数据库表格（source id, target id, status)
需要来回答如下查询：我关注谁？谁关注我？我是否关注某人？某人是否关注我？

当数据库的压力变大时，instagram开始在Redis中并发存储关注图谱，但这也带来了内容一致性（consistency）的问题。

不一致性一度带来缓存失效问题。

PostGIS结合轻量的memcached缓存，可以支撑上万的请求量。

需要注意点：

1、核心数据存储部分有一个万能的组件支撑，就像：Redis；

2、千万不要试想用两种工具去做同一个工作；

• 三、保持敏捷

2010年： 2位工程师

2011年： 3 位工程师

2012年： 5 位工程师

制胜法宝：

1、广泛的单元测试和功能测试

2、坚持DRY（Don’t Repeat Yourself）原则

3、使用通知/信号机制实现解耦

4、我们大部分工作使用Python来完成，只有逼不得已的时候，才会用C

5、频繁的代码复查，尽量保持“智慧共享”。（frequent code reviews, pull requests to keep things in the ‘shared brain’）

6、广泛的系统监控

• 四、往android平台扩展

12小时增加100万新用户

伟大的工具可以使读取更具扩展性，例如：redis: slaveof <host> <port>（SLAVEOF 命令用于在 Redis 运行时动态地修改复制(replication)功能的行为）

更短的迭代周期

不要重复发明轮子，例如想开发一个系统监控的守护进程，完全没有必要，HAProxy完全能胜任这一工作。

周围要有强大的技术顾问；

技术团队保持开放的氛围；

give back; e.g. node2dm（我理解的意思是：回报开源世界，例如：node2dm，一个出自instagram的node.js服务器，用来向安卓C2DM服务提交推送请求）

关注优化，如何是我们的系统速度快上一倍？

staying nimble = remind yourself of what’s important（保持敏捷 = 时刻提醒自己，什么才是你最重要的）

前所未有的时代，两个后端工程师能够支撑3000万用户规模的系统，关键字是： simplicity（简单）

cleanest solution with the fewest moving parts as possible（使用最少部件，最干净的解决方案）

don’t over-optimize or expect to know ahead of time how site will scale（不要过度的优化，除非你提前知道自己的系统将如何扩展）

don’t think “someone else will join & take care of this”

因为这个PPT本身也传承了instagram的simplicity哲学，因此很多信息只能靠猜，同时因为自己对相关技术认识还比较欠缺，无法很好的将其中的内容贯穿起来，整个内容翻译下来有点支离破碎的感觉，欢迎高手拍砖指正。