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