[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)
