从零打造 Instagram

Instagram是全球最大的照片、视频分享社区，如果让我们自己设计一个Instagram这样的服务，应该怎么做呢？这篇文章解析了Instagram的功能和架构，从中我们可以看到设计一个内容分享服务所需要关注的部分。原文：Instagram System Architecture[1]

Instagram是一个免费的照片和视频分享社交网络，有很多人每天在上面分享故事，记录生活中的点点滴滴。

功能性需求

用户可以上传照片和视频
用户可以查看照片和视频
用户可以根据照片标题进行搜索
用户可以关注/取消关注其他用户
用户可以通过搜索栏搜索用户id
为关注的每个用户创建信息流
可以把照片存档
可以通过聊天窗口分享故事
可以拉黑/限制其他用户
可以在其他用户的帖子下面点赞和评论
用户可以发帖

非功能性需求

高可扩展性
高一致性
高可用性
高可靠性
用户数据应该是持久化的（任何上传的照片都不应该丢失）
生成信息流的最大延迟是150毫秒

接下来我们做一下系统容量估算。

假设注册用户 = 5亿
30%的活跃用户 = 1.5亿
注册名人人数 = 10k
读请求数 = 100 *上传(写)请求数
高峰时刻，假设平均流量 = X，目标处理上限是6X

活跃用户：

每周发帖3次，每个帖子包含1 MB的图片和文本
每个帖子至少收到10个赞和2-3条评论
关注100个用户，有50个粉丝
每天刷新2次信息流

名人：

每周发帖2次，每个帖子包含大于500K的图片和文本
每个帖子至少收到50K个赞和至少1K条评论
拥有500万粉丝
每天刷新2次信息流

每秒请求数（QPS）：

发帖

Create_post_avg = (150 Million + 10 K) * 2 / (72460*60) = 496/s
Create_post_peak = 496/s*6 = 3k/s

like_post_avg = (150 million10 +10K50K) * 2 / (72460*60) = 6.6 k/s
like_post_peak = 6.6 k/s*6 = 40 k/s

comment_post_avg = (150 million * 2 + 10K * 1K) = 1k/s
Comment_post_peak = 1k/s * 6 = 6k/s

关注信息流

get_follow_feed_avg = (150 million + 10K) * 2 / (246060) = 3.5k/s
get_follow_feed_peak = 3.5k/s * 6 = 21.8 k/s

数据量

64base([‘a-z’,‘A-Z’,‘0–9’,‘-’,‘_’])编码的user_id，需要5 bits ~ 1Byte
500 Million + 10K * 5 bits ~ 1 Byte = 1G user

容量估计：

每天上传的活跃用户 = 100万
每天上传的照片 = 500万张
每天每秒上传的照片 = 57张照片
平均照片大小 = 150 KB
每天存储开销 = 500万* 150KB = 716GB
数据保存10年，所需存储容量为716 GB * 365 * 10年 = 2553 TB ≈ 2.6 PB
日活跃用户查看 = 1000万
每小时的信息流产生量为1000万，即2800 RPS(每秒请求数)。
如果用户每天搜索一次，那就是每天1000万次搜索，也就是115个RPS。

系统组件设计

上传照片和视频 = 写操作
查看照片和视频 = 读操作
读写比 = 20:80
Web服务器可以同时支持1000个活动连接
200个连接会被写操作占用，写入(上传)会使连接长时间保持打开状态

因此，更好的方法是用2个数据库分别处理读写操作。此外，分离照片的读写请求可以帮助我们独立的扩展和优化每个过程。下图显示了读写的过程。

1. 信息流生成服务（News Feed Generation services）

为用户更新所关注的用户的最新帖子
每个用户的信息流都是独一无二的，组合非常复杂
为了生成新的信息流，系统必须获取这些照片的元数据(喜欢、评论、时间、位置等)，并将其传递给排名算法，以决定哪些照片应该根据元数据安排在信息流中
后端需要同时查询大量的表，然后使用预定义的参数对它们进行排序，这种方法将导致更高的延迟，需要大量的时间来生成新的信息流
因此，可以采用预生成的信息流。创建专门用于生成每个用户独有信息流的服务器，并将其结果存储在单独的信息流表中。当用户点击更新时，直接从数据库中读取信息流并显示给用户。

2. 提供信息流（Serving the News Feed）

推模式（Push） — 当用户上传了新的照片/视频，他/她的所有粉丝都会获得更新。如果用户关注了很多人或名人，服务器就必须非常频繁的向用户推送更新。
拉模式（Pull） — 用户主动刷新他们的信息流(向服务器发出一个拉取请求)。在用户刷新之前，新帖子是不可见的。
混合模式（Hybrid Approach） — 对拥有大量粉丝的名人用户应用拉模式，普通用户采用推模式。

3. 负载均衡（Load Balancing）

将流量分流到一组服务器中，从而提高网站或应用程序的响应和可用性
使用最小带宽法
该算法将选择流量最小的服务器(以每秒兆位(Mbps)计算)提供服务
部署在客户端和服务器或服务器和数据库之间

数据架构

数据库设计

1. 用户相关数据

User ID（主键）：唯一的用户ID，便于全局区分用户
Name：用户名
Email：用户邮件地址
Password：用户密码，用于用户登录
Create Date：用户注册时间

2. 照片相关数据（AWS S3）

photo id（主键）：10字节长度的唯一照片id，用于标识每一张照片
UserId：上传照片的用户id
Path：存放照片的对象存储路径/URL
Latitude & Longitude（纬度和经度）：存储这些信息来找到照片的位置
Date & time（日期和时间）：照片上传的日期和时间戳

3. 用户关注和粉丝相关数据

Following：该用户所关注的所有用户的UserId
Followers：关注该用户的所有用户的UserId

因此，我们需要两种不同的数据库：
1）关系型数据库（MySQL）
2）NoSQL数据库（Cassandra）

数据模型

典型查询：

获取用户X关注的所有用户——为用户X发送信息流
获取所有关注用户X的用户——将用户X的帖子推送到关注者的信息流中
获取所有活跃用户（为活跃用户提供缓存的关注者信息流）

接口/API

create_post(user_id, image, text, timestamp) -> success/failure
comment_post(user_id, post_id, comment, timestamp) -> success/failure
like_post(user_id, post_id, timestamp) -> success/failure
get_follow_feed(user_id, timestamp) -> list of newest posts from user follow list, ordered by time, limit 20
get_profile_feed(user_id, user2_id, timestamp) -> list of newest posts from user2, ordered by time, limit 20

系统架构

发帖

信息流

进一步细化

发帖

信息流

延伸阅读：

Instagram Engineering: https://medium.com/@InstagramEng

Instagram System Design: https://youtu.be/da7mdMz0g0g

Designing Instagram: https://www.educative.io/courses/grokking-the-system-design-interview/m2yDVZnQ8lG

Design Photo Sharing Platform – Instagram: https://techtakshila.com/system-design-interview/chapter-4/

Designing Instagram: https://www.codercrunch.com/design/634265/designing-instagram

Designing Instagram Architecture: https://nlogn.in/designing-instagram-architecture-system-design/

System Design Analysis of Instagram: https://towardsdatascience.com/system-design-analysis-of-instagram-51cd25093971