Instagram 架构分析笔记(转)

原文:http://dbanotes.net/?s=Instagram+%E6%9E%B6%E6%9E%84%E5%88%86%E6%9E%90%E7%AC%94%E8%AE%B0

作者:冯大辉

Instagram 团队上个月才迎来第 7 名员工,是的,7个人的团队。作为 iPhone 上最火爆的图片类工具,instagram 用户数量已经超过 1400 万,图片数量超过 1.5 亿张。不得不说,这真他妈是个业界奇迹。

几天前,只有三个人的 Instagram 工程师团队发布了一篇文章:What Powers Instagram: Hundreds of Instances, Dozens of Technologies,披露了 Instagram 架构的一些信息,足够勾起大多数人的好奇心。读罢做点笔记,各种线索还是有一定参考价值的。能打开原文的建议直接读原文。

Instagram 开发团队奉行的三个核心原则:

  • Keep it very simple (极简主义)
  • Don’t re-invent the wheel (不重复发明轮子)
  • Go with proven and solid technologies when you can(能用就用靠谱的技术)

OS/主机

操作系统的选择,在Amazon EC2上跑 Ubuntu Linux 11.04 (Natty Narwhal) ,这个版本经过验证在 EC2 上够稳定。因为只有三名工程师,只有三名工程师,所以自己部署机器到 IDC 是不靠谱的事情。幸好有亚马逊。

负载均衡

此前曾用过两台 Nginx 做 DNS 轮询承载前端请求,这样做会有副作用,现在已经迁移到Amazon的ELB(Elastic Load Balancer),起了三个 Nginx 实例,在 ELB 层停掉了 SSL , 以缓解 CPU 压力。DNS 服务使用 Amazon Route53 服务。

应用服务器

启用了 25 个 Django 实例,运行在 High-CPU Extra-Large 类型的服务器实例上,之所以用 High-CPU Extra-Large 实例是因为应用请求是 CPU 密集型而非 IO 密集型。

使用 Gunicorn 作为 WSGI 服务器。过去曾用过 Apache 下的 mod_wsgi 模块,不过发现 Gunicorn 更容易配置并且节省 CPU 资源。使用 Fabric 加速部署。

数据存储

用户信息、图片元数据、标签等大部分数据存储在 PostgreSQL 中。主要的 Shard 数据库集群有 12个节点。

实践中发现 Amazon 的网络磁盘系统单位时间内寻道能力不行,所以有必要将数据尽量放到内存中。创建了软 RAID 以提升 IO 能力,使用的 Mdadm 工具进行 RAID 管理。

管理内存中的数据,vmtouch 这个小工具值得推荐。

PostgreSQL 设置为 Master-Replica 方式,流复制模式。利用 EBS 的快照进行数据库备份。使用 XFS 文件系统,以便和快照服务充分配合。 使用 repmgr 这个小工具做 PostgreSQL 复制管理器器。

连接池管理,用了 PgbouncerChristophe Pettus 的文章包含了不少 PostgreSQL 数据库的信息。

TB 级别的海量图片存储在 Amazon S3 上,CDN 采用的也是 Amazon 的服务,CloudFront。

Instagram 也是 Redis 的重度用户,Feed 以及 Session 信息都用 Redis 处理,Redis 也是以 Master-Replica 方式部署。在 Replica 节点上进行数据备份。

使用了 Apache Solr 承担 Geo-search API 的工作,Solr 简单的 JSON 接口也不错。

缓存使用了 6 个 Memcached 实例,库使用 pylibmc 和 libmemcached。亚马逊也提供缓存服务-Elastic Cache service ,Instagram 也有尝试,不过不便宜。

任务队列/发布通知

队列服务使用 Gearman ,通知系统则使用pyapns 来实现。

监控

前面提及的服务器实例数量加起来,的确有100多个,有效的监控是相当有必要的。使用 Munin 作为主要监控工具 , 也写了不少定制插件,外部监控用 Pingdom 的服务。通知服务使用 PagerDuty

对于 Python 的错误报告,使用 Disqus 团队开源的 Sentry 来处理。

几个感想

0)轻装上阵说起来容易,做起来非常难。这也是 Instagram 团队目前最令人着迷的地方;

1)Python 社区已经足够成熟,各个环节上都已经有不错的解决方案了。

2)如果要问我最大的一个感慨,我要说:Amazon 真是一家伟大的公司,甚至比 Google 还伟大

Instagram 架构分析笔记(转)

时间: 2024-08-09 02:05:21

Instagram 架构分析笔记(转)的相关文章

【转载】Instagram架构分析笔记

原文地址:http://chengxu.org/p/401.html Instagram 架构分析笔记 全部 技术博客 Instagram团队上个月才迎来第 7 名员工,是的,7个人的团队.作为 iPhone 上最火爆的图片类工具,instagram 用户数量已经超过 1400 万,图片数量超过 1.5 亿张.不得不说,这真他妈是个业界奇迹. 几天前,只有三个人的 Instagram 工程师团队发布了一篇文章:What Powers Instagram: Hundreds of Instance

instagram架构分析_转

转自:http://www.eit.name/blog/read.php?504 Instagram 团队上个月才迎来第 7 名员工,是的,7个人的团队.作为 iPhone 上最火爆的图片类工具,instagram 用户数量已经超过 1400 万,图片数量超过 1.5 亿张.不得不说,这真他妈是个业界奇迹. 几天前,只有三个人的 Instagram 工程师团队发布了一篇文章:What Powers Instagram: Hundreds of Instances, Dozens of Techn

zeromq源码分析笔记之线程间收发命令(2)

在zeromq源码分析笔记之架构说到了zmq的整体架构,可以看到线程间通信包括两类,一类是用于收发命令,告知对象该调用什么方法去做什么事情,命令的结构由command_t结构体确定:另一类是socket_base_t实例与session的消息通信,消息的结构由msg_t确定.命令的发送与存储是通过mailbox_t实现的,消息的发送和存储是通过pipe_t实现的,这两个结构都会详细说到,今天先说一下线程间的收发命令. zeromq的线程可分为两类,一类是io线程,像reaper_t.io_thr

Yarn之ResourceManager详细分析笔记(一)待续

一.概述     本文将介绍ResourceManager在Yarn中的功能作用,从更细的粒度分析RM内部组成的各个组件功能和他们相互的交互方式. 二.ResourceManager的交互协议与基本职能 1.ResourceManager交互协议 在整个Yarn框架中主要涉及到7个协议,分别是ApplicationClientProtocol.MRClientProtocol.ContainerManagementProtocol.ApplicationMasterProtocol.Resour

漫谈架构读书笔记

漫谈架构阅读笔记 阅读了漫谈架构这本书后,感受颇深.在此书中,文章书写简单易读,并没有过多的专业词汇,其中还不乏举出了许多生动有趣的例子给人以印象深刻,我认为,此书写的确实不错,值得阅读. 首先关于什么是架构?结合文章和最近所学我认为架构就是软件的框架,软件在设计好的框架中生产运行发展与维护,联系文章世间万物皆有框架,从最早的木头到桌子椅子,做成这一事物所依赖的标准原则便是架构.人的出行时做火车还是汽车还是飞机取决于要去的地方与所需的其他要求,每个交通工具有自己的特点,其相互运行却互不打扰,是架

二、OpenStack入门 之 架构分析

OpenStack入门 之 架构分析 写在前面 学习目标: 了解 OpenStack 各组件的逻辑关系: 了解 OpenStack 的各组件的通信和部署关系: 了解 OpenStack 的工作流程: 接下来我会掌握: OpenStack 组件间的逻辑关系: OpenStack 的API: OpenStack 组件间的通信关系: OpenStack 中几种不同的存储: OpenStack 工作流程: OpenStack 的部署架构: OpenStack 各组件之间的关系有:逻辑关系,通信关系,部署

秒杀系统架构分析与实战

0 系列目录 秒杀系统架构 秒杀系统架构分析与实战 1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要面对的技术挑战有: 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,

Linux内核架构读书笔记 - 2.5.3 处理优先级

1 优先级的内核表示 内核使用 0 - 139 表示内部优先级,值越低,优先级越高.0 -99 实时进程使用 nice 值 [-20,19]映射到范围100 - 139,如下图 内核定义了一系列宏来辅助优先级之间的转换 sched.h 1 /* 2 * Priority of a process goes from 0..MAX_PRIO-1, valid RT 3 * priority is 0..MAX_RT_PRIO-1, and SCHED_NORMAL/SCHED_BATCH 4 *

Linux内核架构读书笔记 - 2.5.2 数据结构

调度系统各个组建关系如下 激活调度器两种方法:进程睡眠或其他原因放弃CPU,周期性检测 上述两个组件统称为通用调度器或核心调度器. 调度器用于判断接下来运行那个进程,内核支持不同的调度策略( 完全公平调度 实时调度 无事可做的空闲调度进程) 调度器被调用时候 需要执行体系相关的进程上下文切换 每个进程属于某个调度器类,各个调度器负责管理所属进程,通用调度器不涉及进程管理,都由调度器来 下面分别讲述: task_struct 成员 sched.h 1 struct task_struct { 2