哈嘍大家好，我是鹹魚 想必大家都聽說過 Instagram ，它是全球最受歡迎的社交媒體平臺之一，擁有數十億的活躍用戶 Instagram 誕生於 2010 年，上線一周就坐擁 10 萬註冊用戶，一年之內就擁有了 1400 萬用戶，可見擴張趨勢突飛猛進。 Instagram 誕生的時候只有 3 個工 ...
哈嘍大家好，我是鹹魚
想必大家都聽說過 Instagram ，它是全球最受歡迎的社交媒體平臺之一，擁有數十億的活躍用戶
Instagram 誕生於 2010 年，上線一周就坐擁 10 萬註冊用戶，一年之內就擁有了 1400 萬用戶，可見擴張趨勢突飛猛進。
Instagram 誕生的時候只有 3 個工程師，想必大家對【他們怎麼設計後端架構，使用了什麼技術來支持這麼多用戶】很感興趣吧，那麼今天我們就來瞭解一下 Instagram 是如何在只有 3 名工程師的情況下擴展到 1400 萬用戶
原文：https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million
從 2010 年 10 月到 2011 年 12 月，Instagram 的用戶在一年多的時間里從 0 增加到1400萬，關鍵是他們只有 3 個工程師
這聽起來是不是很不可思議。據 Instagram 工程師透露，他們通過遵循下麵 3 個關鍵原則並擁有可靠的技術棧來做到這一點：
- 讓事情變得非常簡單
- 不要重覆造輪子
- 儘可能使用經過驗證的可靠技術
技術棧
Instagram 早期的基礎設施運行在 AWS 上，使用 EC2 和 Ubuntu Linux
EC2 是 Amazon 的雲服務，它允許開發人員租用虛擬機
- 前端 APP
Instagram 最初在 2010 年作為 iOS 應用程式推出。由於 Swift 在 2014 年才發佈，那 Instagram 應該是使用 Objective-C 和 UIKit 等其他語言的組合來編寫的
- 負載均衡
Instagram 使用了 Amazon 的 Elastic 負載均衡器（Load Balancer）。他們有 3 個 Nginx 實例，Nginx 之間會進行健康檢查以此保證服務高可用
當用戶請求到來時，每個請求會先經過負載均衡器，然後才被轉發到後端實際伺服器
- 後端服務
Instagram 的應用程式伺服器使用了 Django 框架，它是由 Python 編寫的，而 Gunicorn 是它們的 WSGI 伺服器
WSGI （Web Server Gateway Interface）全稱 web 伺服器網關介面，它會將請求從 web 伺服器轉發到 web 應用程式
在批量管理和自動運維方面，Instagram 通過 Fabric 同時在多個實例上面並行運行命令，做到幾秒鐘內部署代碼
Fabric 是 Python 的一個模塊，基於 SSH 提供了豐富的交互介面，可以用來在本地或遠程機器上自動化的執行 Shel l命令，非常適合用來做應用的遠程部署及系統維護
這些實例在超過25台 Amazon High-CPU Extra-Large 機器上運行。由於伺服器本身是無狀態的，如果需要處理更多請求時，便可以添加更多的機器
- 一般數據存儲
Instagram 使用了 PostgreSQL 來存儲數據，應用程式伺服器將從 PostgreSQL 中提取數據，PostgreSQL 存儲了 Instagram 的大部分數據，例如用戶和照片元數據
PostgreSQL 和 Django 之間的連接通過 pgbouncer
pgbouncer 是一個 PostgreSQL 連接池
任何目標應用程式都可以像連接 PostgreSQL 伺服器一樣連接到 pgbouncer，並且 pgbouncer 將創建到實際伺服器的連接，或者重用其現有的連接
Instagram 對用戶的數據進行了分片，即使用代碼將幾千個“邏輯”碎片映射到幾個物理碎片，因為收到的數據量很大(每秒超過 25 張照片和 90 個贊)
但是在將數據寫入這組伺服器之前，Instagram 必須解決如何為資料庫中的每條數據分配ID(唯一標識符)的問題
下麵則是 Instagram 中每條數據 ID 包含的內容：
- 41 位表示時間（以毫秒為單位）
- 13 位表示邏輯分片 ID
- 10 位表示自動遞增序列，模數 1024。這意味著我們可以在每毫秒內為每個分片生成 1024 個id
Instagram 的數據分片和 ID 具體是怎麼解決的小伙伴們可以看這篇文章：
https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c
- 照片數據存儲
對於用戶的照片，Instagram 使用 Amazon S3 來存儲，並且使用 Amazon CloudFront 把照片快速提供給用戶
- 緩存
Instagram 使用 Redis 將大約 3 億張照片映射到創建它們的用戶 ID 進行存儲，所有 Redis 都存儲在記憶體中以減少延遲，併在多台機器上進行分片。
通過一些巧妙的散列，Instagram 能夠在不到 5 GB 的記憶體中存儲 3 億個鍵映射
對於常規緩存，Instagram 使用了 Memcached。他們當時有 6 個 Memcached 實例。Memcached 相對容易疊加在 Django 上
PostgreSQL 和 Redis 都使用了主從架構，並使用 Amazon EBS（彈性塊存儲）快照對系統進行頻繁備份
- 推送通知和非同步任務
Instagram 使用 pyapns 來實現，Pyapns 是一個開源的、通用的蘋果推送通知服務(APNS)提供商
在後端，任務被推送到 Gearman，這是一個任務隊列，將工作分配給更適合的機器。Instagram 有 大約 200 名 Python 工作者使用 Gearman 任務隊列
Gearman 常用於多個非同步任務，例如向用戶的所有關註者推送活動（發佈的新照片）
- 監控
Instagram 使用開源 Django 應用程式 Sentry 來實時監控 Python 錯誤
Munin 用於繪製系統範圍的指標併發出異常警報。Instagram 有一堆自定義的 Munin 插件來跟蹤應用程式級別的指標，例如每秒發佈的照片
Pingdom 用於外部服務監控，PagerDuty 用於處理事件和通知
