# 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)  对 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 图片的磁盘平均大小是多少吗？