小程序
传感搜
传感圈

Instagram 仅 3 名工程师,如何做到 1400 万用户? 原创

2023-10-30
关注

整理 | 云昭

策划 | 言征 

出品 | 51CTO技术栈(微信号:blog51cto)

2010 年 10 月 6 日,旧金山。当人们还沉浸在拥有更强大摄像头的 iPhone 4 的激动心情时,一款名为“ Instagram ” 的 iOS 照片分享应用出现在应用商店中。

当天就收获了 2.5 万首批用户,一周之后,下载量攀升到 10 万,从 2010 年 10 月到 2011 年 12 月,Instagram在短短一年多的时间里,用户数量从 0 增长到 1400 万。

而他的创始人, Kevin Systrom 这期间用了 3 名工程师就做到了这一点。这就让我们回到那个奇幻的时刻,从工程师的角度思考,一探他们是如何做到的。

简单来说,他们通过如下遵循 3 个关键指导原则并拥有可靠的技术堆栈来做到这一点:让事情变得非常简单、不要重新发明轮子、尽可能使用经过验证的可靠技术。

一、早期基础配置

早期 Instagram 的基础设施,是在 AWS 上运行的,使用 EC2 和 Ubuntu Linux。作为参考,EC2 是亚马逊的服务,允许开发人员租用虚拟计算机

为了让事情变得简单,并且由于我喜欢从工程师的角度思考用户,所以让我们回顾一下用户场景会话的生命周期。

二、前端

场景回顾:用户打开界面。

Instagram 最初于 2010 年作为 iOS 应用程序推出。由于 Swift 于 2014 年发布,我们可以假设 Instagram 是使用Objective-C 和 UIKit 等其他东西的组合编写的。

图片

三、负载均衡

场景回顾:打开应用程序后,获取主订阅源照片的请求会发送到后端,并在那里到达Instagram的负载均衡器。

Instagram 使用亚马逊的弹性负载均衡器。他们有 3 个 NGINX 实例,根据它们是否健康来换入和换出。

每个请求首先到达负载均衡器,然后再路由到实际的应用程序服务器

图片

四、后端

场景回顾:负载均衡器将请求发送到应用程序服务器,应用程序服务器保存正确处理请求的逻辑。

Instagram 的应用服务器使用Django ,用 Python 编写,Gunicorn作为他们的 WSGI 服务器。

回顾一下,WSGI(Web 服务器网关接口)将请求从 Web 服务器转发到 Web 应用程序。

Instagram 使用Fabric同时在多个实例上并行运行命令。这允许在几秒钟内部署代码。

它们运行在超过 25 台 Amazon High-CPU 超大型机器上。由于服务器本身是无状态的,当他们需要处理更多请求时,他们可以添加更多机器。

图片

五、通用数据存储

场景回顾:应用服务器发现请求需要主提要的数据。为此,我们假设它需要:

  • 最新的相关照片ID 
  • 与这些照片ID匹配的实际照片
  • 这些照片的用户数据。

1.数据库:Postgres

场景回顾: 应用服务器从Postgres获取最新的相关照片ID。

应用程序服务器将从PostgreSQL中提取数据,PostgreSQL 存储了 Instagram 的大部分数据,例如用户和照片元数据。

Postgres 和 Django 之间的连接使用Pgbouncer进行池化。

Instagram由于收到的数据量很大(每秒超过 25 张照片和 90 个赞)而对他们的数据进行了分片。他们使用代码将数千个“逻辑”分片映射到几个物理分片。

Instagram 面临并解决的一个有趣的挑战是生成可以按时间排序的 ID。他们生成的可按时间排序的 ID 如下所示:

  • 41 位时间(以毫秒为单位)(提供了 41 年的 ID 和自定义纪元)
  • 13位代表逻辑分片ID
  • 10 位表示自动递增序列,模数 1024。这意味着我们可以为每个分片、每毫秒生成 1024 个 ID

场景回顾:由于Postgres中的可按时间排序的ID,应用服务器已成功接收到最新的相关照片ID。

2.照片存储:S3 和 Cloudfront

场景回顾: 然后,应用服务器通过快速CDN链接获取与这些照片ID匹配的实际照片,以便为用户快速加载。

Amazon S3中存储了数 TB 的照片。这些照片已使用 Amazon CloudFront快速提供给用户。

3.缓存:Redis 和 Memcached

场景思考:为了从Postgres获取用户数据,应用服务器(Django)使用Redis将照片ID与用户ID进行匹配。

Instagram 使用 Redis 将大约 3 亿张照片存储到创建它们的用户 ID 的映射,以便知道在获取主提要、活动提要等照片时要查询哪个分片。所有 Redis 都存储在内存中减少延迟,并且它被分片到多台机器上。

通过一些巧妙的哈希处理,Instagram 能够在不到 5 GB 的空间中存储 3 亿个键映射。为了知道要查询哪个 Postgres 分片,需要此 photoID 到用户 ID 键值映射。

场景回顾:由于使用Memcached的高效缓存,从Postgres获取用户数据很快,因为最近的响应被缓存了。

对于一般缓存,Instagram 使用Memcached 。他们当时有 6 个 Memcached 实例。Memcached 在 Django 上分层相对简单。

有趣的是:两年后,即 2013 年,Facebook 发布了一篇具有里程碑意义的论文,介绍了他们如何扩展 Memcached 以帮助他们每秒处理数十亿个请求。

用户现在可以看到主页,里面有他关注的人的最新照片。

图片

4.主副本设置

Postgres 和 Redis 都在主副本设置中运行,并使用 Amazon EBS(弹性块存储)快照来频繁备份系统。

六、推送通知和异步任务

场景回顾:现在,假设用户关闭了应用程序,但随后收到朋友发布照片的推送通知。

此推送通知是使用pyapns发送的,与 Instagram 已经发送的其他十亿多条推送通知一起。Pyapns 是一个开源、通用的 Apple 推送通知服务 (APNS) 提供商。

场景回顾:用户非常喜欢这张照片!所以他决定在Twitter上分享。

在后端,任务被推送到Gearman中,这是一个任务队列,它将工作外包给更适合的机器。Instagram 有大约 200 个 Python 工作线程使用 Gearman 任务队列。

Gearman 用于执行多个异步任务,例如向所有用户的关注者推送活动(例如发布的新照片)(这称为扇出)。

图片

七、监控

场景回顾:Instagram应用程序因服务器出现错误而崩溃,并发送了错误响应。Instagram的三名工程师立即得到了提醒。

Instagram 使用Sentry (一款开源 Django 应用程序)来实时监控 Python 错误。

Munin用于绘制系统范围的指标并发出异常警报。Instagram 有一堆自定义 Munin 插件来跟踪应用程序级别的指标,例如每秒发布的照片。

Pingdom用于外部服务监控,PagerDuty用于处理事件和通知。

八、最终架构一览

图片

——后记——

Instagram发布的19个月,后活跃用户数量超过5000万,活跃用户数量达到1亿,2012年6月份达到1.3亿。同年10月25日,当时的Facebook以总值7.15亿美元收购Instagram,创始人Kevin从中获得了4亿美元的回报。

值得一提的是,于编程而言,Kevin是自学成才。管理学科出身的他,刚毕业时可谓是一张白纸,在社交旅游网站Nextstop营销部门工作时,凯文开始每晚抽时间自学编程。

Instagram 的成功带来的不仅仅创造了当代硅谷最伟大的成功故事之一,Kevin的自学成才的历程成为了激烈开发者们对于编程的热情。

参考链接:

https://instagram-engineering.com/what-powers-instagram-hundreds-of-instances-dozens-of-technologies-adf2e22da2ad

https://instagram-engineering.com/storing-hundreds-of-millions-of-simple-key-value-pairs-in-redis-1091ae80f74c

https://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram


您觉得本篇内容如何
评分

评论

您需要登录才可以回复|注册

提交评论

传感学人

这家伙很懒,什么描述也没留下

关注

点击进入下一篇

安捷伦Agilent DSO90804A示波器

提取码
复制提取码
点击跳转至百度网盘