[Architecture]Instagram

# 设计哲学

    简单、为最小化运维负担进行优化并监控一切内容；

# 核心原则

    保持简单，不要重复发明轮子，尽可能使用经过验证、稳定可靠的技术

# Instagram的workflow

    - 采用同步的方式写入媒体数据库

    - 如果照片上有地理位置标签，则以异步的方式将照片提交给 Solr 进行索引

    - 将照片的 ID 加入每个关注者的列表里，该列表保存在 Redis 之中

    - 在显示 Feed 时，选取一小部分照片 ID，在 Memcached 里进行查询

#  General

    - Extensive Unit-tests and functional tests

    - Keep it DRY

    - Loose coupling using nifications/signals

    - Do most of our work in Python, drop to C when necessary

    - Frequent code reviews, pull requests to keep things in "shared brain"

    - Extensive monitoring

# Architecture

    - Amazon Web Service

    - AWS EC2：Ubuntu 11.04

    - Load Balance: Amazon Elastic Load Balancer;

      后端运行3 个 Nginx 实例，SSL 只到 ELB 上为止，降低了 Nginx 上的 CPU 负载。

    - DNS/CDN: Amazon Route 53 / CloudFront

    - Pictore Storage: AWS S3

    - DB: PostgreSQL

# Application Server

    - AWS EC2： Amazon High-CPU Extra-Large Instance

    - Web Framework： Django

    - WSGI 服务器： Gunicorn

    - 并行部署： Fabric

# Redis & Memcached

     大量使用 Redis 来存放复杂的对象（对象的大小做了一定的限制），用于主 Feed、活动 Feed、会话系统及其他相关系统。因为要将 Redis 的所有数据都放在内存里，此处同样也用了High-Memory Quadruple Extra-Large Instance，并对数据做了分片。当 Redis 实例的请求达到 4 万/秒后，它渐渐成为了瓶颈，于是 Redis 也做了主从复制，副本的数据会经常导出到磁盘上，通过 EBS 快照进行备份。

    除了 Redis，他们还使用 Memcached 来做缓存，目前运行了 6 个实例，应用服务器通过 pylibmc 和 libmemcached 进行连接。虽然 Amazon 提供了 Elastic Cache 服务，但该服务的价格并不便宜，相比之下，还是运行自己的 Memcached 实例比较划算.

# Task Queue

    异步任务队列使用的是 Gearman，目前有大约 200 个工作进程来处理各种任务，比如把照片分享到 Twitter 和 Facebook，通知用户有新照片等等。

# 推送通知

    Pyapns 已经处理了十亿的推送通知，非常稳定，他们还自己开发了基于 Node.js 的 node2dm，用于向 Android 设备发送推送通知;

# Monitoring

    - Munin 与 Python-Munin 图形化方式显示系统状态；

    - 网络守护进程 Stated 可以实时收集数据并做汇总

    - Dogslow 会监控进程，一旦发现运行时间过长的进程，便会保存该进程的快照，以便后续分析；比如响应时间超过1.5秒的请求，通常都是卡在 Memcached 的 set ()和 get_many ()方法上。

    - 对于 Python 的错误，只要登上 Sentry 就能实时获取错误信息

# References

[Instagram Engineering] (http://instagram-engineering.tumblr.com/rss)

[了解Instagram背后的技术] (http://www.cnblogs.com/piaoger/admin/EditPosts.aspx?postid=2520969)