91.md

# Instagram 架构更新：Instagram 有何新功能？

> 原文： [http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html)

![](img/e7b70a6c02b1e7425849dd6d1af801f2.png)

对 Instagram 的迷恋仍在继续，幸运的是，我们有了一些新的信息流来满足人们的疯狂需求。 因此，请考虑对 [Instagram 架构 Facebook 的收购，以 10 亿美元的价格](http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html) 为基础，主要基于 [扩展 Instagram](http://www.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-Instagram) ，Instagram 联合创始人 Mike Krieger 为 AirBnB 技术演讲提供的幻灯片。 本文底部还列出了其他几种信息来源。

不幸的是，我们只有一个幻灯片，因此缺少演讲的结缔组织，但它仍然非常有趣，以开发人员出现后我们经常看到的相同的智慧演讲的精神 在战 significant 中花费大量时间后获得空气。

如果您希望深入了解技术细节并找到收购 Instagram 的十亿原因，您会感到失望的。 在所有用户和产品之间的关系投入的情感投入中，而不是在如何管理字节方面，可以发现这种魔力。

那么 Instagram 有什么新功能？

*   一些统计信息：
    *   Instagram 在不到两年的时间内就达到了 30+百万用户，然后在其 Android 应用程序发布 10 天后猛增至 4000 万用户。
    *   Android 发行后，他们在 12 小时内拥有 100 万新用户。
*   Instagram 的使命是交流和分享现实世界。
*   世界已经改变。 现在有 2 位后端工程师可以将系统扩展到 30+百万用户：
    *   最初是两个没有后端经验的人
    *   托管在洛杉矶的一台计算机上，功能不如 MacBook Pro
    *   第一天注册 25K，使机器融化，因此他们迁移到了亚马逊
    *   2 位工程师在 2010 年。
    *   2011 年有 3 名工程师
    *   5 位工程师，2012 年，后端 2.5。 这包括 iPhone 和 Android 开发。
    *   稀缺性引起关注。
*   您最初遇到的大多数扩展问题都不会很吸引人：
    *   缩放就像在以 100 mph 的速度行驶时更换汽车上的所有组件。
    *   缺少的 favicon.ico 在 Django 中引起了很多 404 错误
    *   memcached -t 4
    *   前叉/后叉
        *   不幸的是，我们没有有关问题所在的详细信息
*   Instagram 哲学：
    *   简单
    *   经过优化，可最大程度地减少操作负担
    *   可以检测所有内容
*   当用户上传带有可选标题和位置的照片时会发生什么？
    *   为用户同步写入媒体数据库。
    *   如果对异步处理进行了地理标记，则将图像发布到 Solr 进行索引。
    *   通过 Redis 中存储的列表传递给关注者。 对于跟随该用户的每个人，媒体 ID 都会被推送到列表中。 在渲染提要时，它们会获取少量 ID，并在内存缓存中查找它们。
*   扩展数据库：
    *   Django ORM 和 PostgreSQL
    *   选择 Postgres 是因为它具有 PostGIS（PostgreSQL 的空间数据库扩展）。
    *   将数据库移到了自己的计算机上，但是照片不断增长，EC2 中最大的计算机上的内存限制为 68GB
    *   下一个策略是垂直分区，将功能转移到自己的服务器上。 Django DB 路由器非常简单，例如，将照片映射到 photodb。
    *   然后，当照片数据库达到 60GB 并且无法再在一台计算机上运行该数据库时，他们开始使用分片。
    *   PostgreSQL 可以通过使用 memcached 进行轻度缓存来处理数万个请求。
    *   所有快照均来自从属服务器，从属服务器在拍摄快照之前已停止，然后 XFS 冻结所有驱动器，然后拍摄快照以确保其一致性。
    *   在 EBS 驱动器上使用 Software-RAID 可获得更好的写入吞吐量。 预写日志（WAL）与主数据库位于不同的 RAID 中。
*   使用了预拆分逻辑分片策略：
    *   基于用户 ID 的分片。
    *   分片的问题之一是，分片比机器大。 因此，他们制作了成千上万个逻辑分片，映射到更少的物理节点。
    *   保留逻辑碎片到物理的映射。
    *   当机器装满时，可以将逻辑碎片移动到新机器上以减轻压力。 优点是无需重新分配任何内容。 按间接级别保存。
    *   PostgreSQL 的 [模式](http://www.postgresql.org/docs/9.0/static/ddl-schemas.html) 功能非常有帮助，但是我无法从幻灯片中确切地看出来。
    *   Membase 使用类似[的方法](http://www.couchbase.com/docs/membase-manual-1.7/membase-architecture.html)。
*   如下图：
    *   V1：简单数据库表：（源 ID，目标 ID，状态）
    *   需要回答以下问题：我应该关注谁？ 谁跟着我？ 我会遵循 X 吗？ X 跟随我吗？
    *   随着数据库繁忙，他们开始在 Redis 中存储跟随图的并行版本。 这导致一致性问题，这需要引入缓存无效化和许多额外的逻辑。
*   Love Redis 的目标：
    *   将复杂的对象缓存到您想做的事中：GET，计数，子范围，成员资格测试
    *   快速插入和快速子集
    *   大小相对有界的数据结构
    *   当 Redis 实例超过 40k req / s 并开始成为瓶颈时，启动另一台计算机，即 SYNCing to master，并向其发送读取查询不到 20 分钟。
*   监视所有内容。
    *   提出类似问题：系统现在如何？ 这与历史趋势相比如何？
    *   [Statsd](http://github.com/etsy/statsd/) -一种网络守护程序，可将数据聚合并汇总为石墨
        *   具有两种统计信息：计数器和计时器。
        *   统计信息可以动态添加
        *   计数器存储着从每秒注册次数到点赞次数的所有内容
        *   计时提要的生成时间，关注用户所需的时间以及任何其他主要操作。
        *   实时允许立即评估系统和代码更改
        *   日志记录调用以较低的采样率插入整个 Web 应用程序，因此不会影响性能。
    *   [Dogslow](http://blog.bitbucket.org/2011/05/17/tracking-slow-requests-with-dogslow/) -监视正在运行的进程，如果发现任何花费超过 N 秒的时间，它将快照当前进程并将文件写入磁盘。
        *   找到的响应要花 1.5 秒钟以上的时间才能返回，响应通常卡在 memcached set（）和 get_many（）中。
        *   他们使用 Munin 看到 Redis 正在处理 50k req / s
*   node2dm-一个 node.js 服务器，用于向 Android 的 C2DM 服务传递推送通知
    *   由 Instagram 撰写，因为他们找不到其他东西。
    *   处理了超过 500 万个推送通知
    *   它是 [开源](http://github.com/Instagram/node2dm)
*   与出色的顾问团聚。 Instagram 从一个好的堆栈和糟糕的配置开始。 他们最终在两方面都做得很好。 现在，他们几乎没有停机时间，每小时部署几次，而综合测试仅需 5 分钟即可运行。 其中一些来自技能和先验知识，但大部分来自适应性和当顾问（例如，亚当·德安杰洛）提出更好的选择时愿意迅速转换的意愿。 （此摘要来自参加演讲的 [鲜寿](http://news.ycombinator.com/item?id=3832556) ）。
*   您无法经常使用的工程师解决方案，因为它们已损坏：
    *   进行广泛的单元和功能测试
    *   保持干燥-不要重复自己
    *   使用通知和信号拥抱松散耦合。
    *   用 Python 完成大部分工作，并在必要时使用 C 语言
    *   使用频繁的代码检查和拉取请求将事情留在共享的头脑中
*   可以动态添加的实时统计信息，使您无需等待接收新数据即可进行诊断和交火。
*   如果可能要考虑读取容量，则理想的是提前提起读取从属设备并使其轮换使用； 但是，如果出现任何新的读取问题，请提前了解如何轮换使用更多读取容量的选择。
*   通常，后端基础架构中的一个成为瓶颈。 弄清楚实际的实时应用服务器遇到的问题可以帮助解决这个问题。
*   使用您知道的技术/工具，然后首先尝试使其适应简单的解决方案。
*   对 Redis 等核心数据存储有多种补充。
*   尽量不要让两个工具完成相同的工作。
*   如果需要，知道在哪里卸载负载。 例如，显示较短的提要。
*   不要重新发明轮子。 例如，如果应用服务器快要死了，请不要编写其他监视系统。 HAProxy 已经执行了此操作，因此请使用它。
*   专注于让自己拥有更好的东西：快速，美观，照片共享。 使快速零件更快。 我们所有的请求都可以占用 50％的时间吗？
*   保持敏捷，提醒自己重要的事情。
*   用户不在乎您编写自己的数据库。
*   不要将自己的内存数据库作为主要数据库存储的解决方案。
*   遇到扩展挑战时，您别无选择。
*   不要过度优化或期望提前知道网站的规模
*   不要以为会有其他人加入并对此进行照顾。
*   对于社交创业公司来说，解决扩展方面的挑战很少（如果有的话）
*   仅将经过优化以简化操作的软件添加到堆栈中
*   玩得开心。
*   Instagram 在理解设计中的心理学力量而非技术方面取得了更多成功。
*   想法是可抛弃的：如果一个想法行不通，您很快就会转向另一个想法。
*   关键字是简单性。
*   时间很重要。 你自己做运气。
*   社交网络的真正社交部分：
    *   出席斯坦福大学，全球最大的风险投资家的注意力将转移到您身上。
    *   在竞争激烈的初创企业中，成功与您所认识的人和所认识的人同样重要。 谈话后，请务必花一些时间来认识您周围的人。
    *   您建立的社交关系与成功直接相关。 企业家有一些偶然性，但是造雨者是企业家需要见面的人，以便建立成功的联系。 （摘自尤因·马里昂·考夫曼基金会资深研究员特德·佐勒）。

## 相关文章

*   [Slidedeck](http://www.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-Instagram) -在 Airbnb 技术讲座上，Instagram 的 Mike Krieger 在扩展 Instagram 上
*   [如何扩展 10 亿美元的创业公司：Instagram 联合创始人的指南](http://techcrunch.com/2012/04/12/how-to-scale-a-1-billion-startup-a-guide-from-instagram-co-founder-mike-krieger/)
*   [在 HackerNews 上](http://news.ycombinator.com/item?id=3831865) ， [在 HackerNews 上](http://news.ycombinator.com/item?id=3804351)
*   [成为 Instagram 成功背后的老路](http://www.nytimes.com/2012/04/14/technology/instagram-founders-were-helped-by-bay-area-connections.html)
*   [Instagram 的用户数现在达到 4000 万，在过去 10 天内吸引了 1000 万新用户](http://techcrunch.com/2012/04/13/instagrams-user-count-now-at-40-million-saw-10-million-new-users-in-last-10-days/)
*   [在十二小时内使 Instagram 拥有超过一百万的新用户](http://instagram-engineering.tumblr.com/post/20541814340/keeping-instagram-up-with-over-a-million-new-users-in)

> 通过存储在 Redis 中的列表传递给关注者。 对于跟随该用户的每个人，媒体 ID 都会被推送到列表中。 在渲染提要时，它们会获取少量 ID，并在 memcached 中查找它们

我是 Web 技术的新手，很好奇：在服务器上已经设置 Redis 时使用 memcached 有什么意义？ 谢谢。

@Oleg：我认为 user_id 可能在存储的 redis 中，并且 memcache 将使整个用户记录+来自主数据存储的联接数据。

知道 Instagram 图片的磁盘平均大小是多少吗？