-
日期: 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个实例。- 新闻来源于其它媒体，内容不代表本站立场！
-
原文链接
原文链接:
目前还没有人发表评论, 大家都在期待您的高见