3个中国程序员 vs 3个美国程序员,差距太大了

日期: 2025-06-19 | 来源: 码农翻身 | 有0人参与评论 | 字体: 小中大
后端

Session：负载均衡会把请求转发给应用服务器

Instagram用Django作为后端服务，运行在 Amazon High-CPU Extra-Large 上，因为这三个程序员发现，后端服务是CPU密集型的。

用Gunicorn做WSGI Server。

应用运行在超过25台亚马逊虚拟机中，这些应用都是无状态的，可以在需要的时候进行扩展。

为了在多台机器上运行命令（例如部署代码），Instagram使用了Fabric，它有一个很好用的并行模式，部署只需要几秒钟。

数据存储

Session: 用户请求到达了应用服务器，接下来它需要获得这些数据：

1.最新的Photo IDs

2.这些Photo ID对应的实际照片

3.这些照片的用户数据

Database: PostgreSQL

Session: 应用服务器从PostgreSQL获取最新的Photo ID，这里保存着用户和照片的元数据。

大部分的数据，如用户，照片元数据，标签等都保存在PostgreSQL数据库中。

因为数据量不小，每秒钟有25个照片上传，并且有90个赞，Instagram对数据做了分片。

分片系统由数千个逻辑分片组成，这些分片在代码中被映射到少得多的物理分片，用这种办法，可以从少量的数据库开始，扩展到更多的数据库。

当扩展时，只需要把逻辑分片从一个数据库“指向”另外一个即可，无需挪动任何数据。

一个挑战是：Instagram如何解决Photo ID问题，因为需要能按时间排序，而无需获得有关照片的更多信息，理想情况下，ID应该是64位的。

后来的解决方案是这样的：

41位：记录毫秒时间

13位：逻辑分片ID

10位：自动增长的序列，模数1024，这意味着每毫秒，每个分片可以生成1024个ID

最终结果是个64为整数，可以被PostgreSQL排序，找到最新的照片。

照片的存储：S3 和Cloudfront

Session: 获取了Photo ID以后，应用服务器要获取真正的照片，快速发给用户

照片保存在Amazon S3中，存储了几个TB的数据，通过使用CDN（Amazon CloudFront ），照片可以快速分发给世界各地的用户（例如日本，是Instagram第二大受欢迎的国家）

缓存

Instagram 需要将大约 3 亿张照片(ID)和创建它们的用户ID的映射保存起来，以便知道查询那个分片。

他们选择了Redis后发现，为了保存这些映射，Redis需要21GB内存，这已经大于 Amazon EC2 上的 17GB 实例类型。

后来他们向Redis的核心开发人员Pieter Noordhuis求助，Pieter建议使用Redis Hash，最终通过巧妙的设计，这些映射仅需不到5G的内存。

对于其他缓存（如session），Instagram使用Memcached，当时有6个实例。
- 新闻来源于其它媒体，内容不代表本站立场！

在此页中阅读全文
分类：中国新闻

猜您喜欢