Instagram的技术探索(2)

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

  • 相关统计

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

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

  • 创建初期

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

image

:)就是这两小子

注:

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码速度行驶的汽车更换所有部件;

image              image          image

 

  • 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那样)

              image    image    image

      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哲学,因此很多信息只能靠猜,同时因为自己对相关技术认识还比较欠缺,无法很好的将其中的内容贯穿起来,整个内容翻译下来有点支离破碎的感觉,欢迎高手拍砖指正。

posted @ 2012-05-28 08:59 红心李 阅读(...) 评论(...) 编辑 收藏