Instagram的技术探索(2)

lang110

　　前一篇翻译了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万用户

• 创建初期
  

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

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