# Instagram 架構更新：Instagram 有何新功能？ > 原文： [http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html)  對 Instagram 的迷戀仍在繼續，幸運的是，我們有了一些新的信息流來滿足人們的瘋狂需求。 因此，請考慮對 [Instagram 架構 Facebook 的收購，以 10 億美元的價格](http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html) 為基礎，主要基于 [擴展 Instagram](http://www.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-Instagram) ，Instagram 聯合創始人 Mike Krieger 為 AirBnB 技術演講提供的幻燈片。 本文底部還列出了其他幾種信息來源。 不幸的是，我們只有一個幻燈片，因此缺少演講的結締組織，但它仍然非常有趣，以開發人員出現后我們經常看到的相同的智慧演講的精神 在戰 significant 中花費大量時間后獲得空氣。 如果您希望深入了解技術細節并找到收購 Instagram 的十億原因，您會感到失望的。 在所有用戶和產品之間的關系投入的情感投入中，而不是在如何管理字節方面，可以發現這種魔力。 那么 Instagram 有什么新功能？ * 一些統計信息： * Instagram 在不到兩年的時間內就達到了 30+百萬用戶，然后在其 Android 應用程序發布 10 天后猛增至 4000 萬用戶。 * Android 發行后，他們在 12 小時內擁有 100 萬新用戶。 * Instagram 的使命是交流和分享現實世界。 * 世界已經改變。 現在有 2 位后端工程師可以將系統擴展到 30+百萬用戶： * 最初是兩個沒有后端經驗的人 * 托管在洛杉磯的一臺計算機上，功能不如 MacBook Pro * 第一天注冊 25K，使機器融化，因此他們遷移到了亞馬遜 * 2 位工程師在 2010 年。 * 2011 年有 3 名工程師 * 5 位工程師，2012 年，后端 2.5。 這包括 iPhone 和 Android 開發。 * 稀缺性引起關注。 * 您最初遇到的大多數擴展問題都不會很吸引人： * 縮放就像在以 100 mph 的速度行駛時更換汽車上的所有組件。 * 缺少的 favicon.ico 在 Django 中引起了很多 404 錯誤 * memcached -t 4 * 前叉/后叉 * 不幸的是，我們沒有有關問題所在的詳細信息 * Instagram 哲學： * 簡單 * 經過優化，可最大程度地減少操作負擔 * 可以檢測所有內容 * 當用戶上傳帶有可選標題和位置的照片時會發生什么？ * 為用戶同步寫入媒體數據庫。 * 如果對異步處理進行了地理標記，則將圖像發布到 Solr 進行索引。 * 通過 Redis 中存儲的列表傳遞給關注者。 對于跟隨該用戶的每個人，媒體 ID 都會被推送到列表中。 在渲染提要時，它們會獲取少量 ID，并在內存緩存中查找它們。 * 擴展數據庫： * Django ORM 和 PostgreSQL * 選擇 Postgres 是因為它具有 PostGIS（PostgreSQL 的空間數據庫擴展）。 * 將數據庫移到了自己的計算機上，但是照片不斷增長，EC2 中最大的計算機上的內存限制為 68GB * 下一個策略是垂直分區，將功能轉移到自己的服務器上。 Django DB 路由器非常簡單，例如，將照片映射到 photodb。 * 然后，當照片數據庫達到 60GB 并且無法再在一臺計算機上運行該數據庫時，他們開始使用分片。 * PostgreSQL 可以通過使用 memcached 進行輕度緩存來處理數萬個請求。 * 所有快照均來自從屬服務器，從屬服務器在拍攝快照之前已停止，然后 XFS 凍結所有驅動器，然后拍攝快照以確保其一致性。 * 在 EBS 驅動器上使用 Software-RAID 可獲得更好的寫入吞吐量。 預寫日志（WAL）與主數據庫位于不同的 RAID 中。 * 使用了預拆分邏輯分片策略： * 基于用戶 ID 的分片。 * 分片的問題之一是，分片比機器大。 因此，他們制作了成千上萬個邏輯分片，映射到更少的物理節點。 * 保留邏輯碎片到物理的映射。 * 當機器裝滿時，可以將邏輯碎片移動到新機器上以減輕壓力。 優點是無需重新分配任何內容。 按間接級別保存。 * PostgreSQL 的 [模式](http://www.postgresql.org/docs/9.0/static/ddl-schemas.html) 功能非常有幫助，但是我無法從幻燈片中確切地看出來。 * Membase 使用類似[的方法](http://www.couchbase.com/docs/membase-manual-1.7/membase-architecture.html)。 * 如下圖： * V1：簡單數據庫表：（源 ID，目標 ID，狀態） * 需要回答以下問題：我應該關注誰？ 誰跟著我？ 我會遵循 X 嗎？ X 跟隨我嗎？ * 隨著數據庫繁忙，他們開始在 Redis 中存儲跟隨圖的并行版本。 這導致一致性問題，這需要引入緩存無效化和許多額外的邏輯。 * Love Redis 的目標： * 將復雜的對象緩存到您想做的事中：GET，計數，子范圍，成員資格測試 * 快速插入和快速子集 * 大小相對有界的數據結構 * 當 Redis 實例超過 40k req / s 并開始成為瓶頸時，啟動另一臺計算機，即 SYNCing to master，并向其發送讀取查詢不到 20 分鐘。 * 監視所有內容。 * 提出類似問題：系統現在如何？ 這與歷史趨勢相比如何？ * [Statsd](http://github.com/etsy/statsd/) -一種網絡守護程序，可將數據聚合并匯總為石墨 * 具有兩種統計信息：計數器和計時器。 * 統計信息可以動態添加 * 計數器存儲著從每秒注冊次數到點贊次數的所有內容 * 計時提要的生成時間，關注用戶所需的時間以及任何其他主要操作。 * 實時允許立即評估系統和代碼更改 * 日志記錄調用以較低的采樣率插入整個 Web 應用程序，因此不會影響性能。 * [Dogslow](http://blog.bitbucket.org/2011/05/17/tracking-slow-requests-with-dogslow/) -監視正在運行的進程，如果發現任何花費超過 N 秒的時間，它將快照當前進程并將文件寫入磁盤。 * 找到的響應要花 1.5 秒鐘以上的時間才能返回，響應通常卡在 memcached set（）和 get_many（）中。 * 他們使用 Munin 看到 Redis 正在處理 50k req / s * node2dm-一個 node.js 服務器，用于向 Android 的 C2DM 服務傳遞推送通知 * 由 Instagram 撰寫，因為他們找不到其他東西。 * 處理了超過 500 萬個推送通知 * 它是 [開源](http://github.com/Instagram/node2dm) * 與出色的顧問團聚。 Instagram 從一個好的堆棧和糟糕的配置開始。 他們最終在兩方面都做得很好。 現在，他們幾乎沒有停機時間，每小時部署幾次，而綜合測試僅需 5 分鐘即可運行。 其中一些來自技能和先驗知識，但大部分來自適應性和當顧問（例如，亞當·德安杰洛）提出更好的選擇時愿意迅速轉換的意愿。 （此摘要來自參加演講的 [鮮壽](http://news.ycombinator.com/item?id=3832556) ）。 * 您無法經常使用的工程師解決方案，因為它們已損壞： * 進行廣泛的單元和功能測試 * 保持干燥-不要重復自己 * 使用通知和信號擁抱松散耦合。 * 用 Python 完成大部分工作，并在必要時使用 C 語言 * 使用頻繁的代碼檢查和拉取請求將事情留在共享的頭腦中 * 可以動態添加的實時統計信息，使您無需等待接收新數據即可進行診斷和交火。 * 如果可能要考慮讀取容量，則理想的是提前提起讀取從屬設備并使其輪換使用； 但是，如果出現任何新的讀取問題，請提前了解如何輪換使用更多讀取容量的選擇。 * 通常，后端基礎架構中的一個成為瓶頸。 弄清楚實際的實時應用服務器遇到的問題可以幫助解決這個問題。 * 使用您知道的技術/工具，然后首先嘗試使其適應簡單的解決方案。 * 對 Redis 等核心數據存儲有多種補充。 * 盡量不要讓兩個工具完成相同的工作。 * 如果需要，知道在哪里卸載負載。 例如，顯示較短的提要。 * 不要重新發明輪子。 例如，如果應用服務器快要死了，請不要編寫其他監視系統。 HAProxy 已經執行了此操作，因此請使用它。 * 專注于讓自己擁有更好的東西：快速，美觀，照片共享。 使快速零件更快。 我們所有的請求都可以占用 50％的時間嗎？ * 保持敏捷，提醒自己重要的事情。 * 用戶不在乎您編寫自己的數據庫。 * 不要將自己的內存數據庫作為主要數據庫存儲的解決方案。 * 遇到擴展挑戰時，您別無選擇。 * 不要過度優化或期望提前知道網站的規模 * 不要以為會有其他人加入并對此進行照顧。 * 對于社交創業公司來說，解決擴展方面的挑戰很少（如果有的話） * 僅將經過優化以簡化操作的軟件添加到堆棧中 * 玩得開心。 * Instagram 在理解設計中的心理學力量而非技術方面取得了更多成功。 * 想法是可拋棄的：如果一個想法行不通，您很快就會轉向另一個想法。 * 關鍵字是簡單性。 * 時間很重要。 你自己做運氣。 * 社交網絡的真正社交部分： * 出席斯坦福大學，全球最大的風險投資家的注意力將轉移到您身上。 * 在競爭激烈的初創企業中，成功與您所認識的人和所認識的人同樣重要。 談話后，請務必花一些時間來認識您周圍的人。 * 您建立的社交關系與成功直接相關。 企業家有一些偶然性，但是造雨者是企業家需要見面的人，以便建立成功的聯系。 （摘自尤因·馬里昂·考夫曼基金會資深研究員特德·佐勒）。 ## 相關文章 * [Slidedeck](http://www.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-Instagram) -在 Airbnb 技術講座上，Instagram 的 Mike Krieger 在擴展 Instagram 上 * [如何擴展 10 億美元的創業公司：Instagram 聯合創始人的指南](http://techcrunch.com/2012/04/12/how-to-scale-a-1-billion-startup-a-guide-from-instagram-co-founder-mike-krieger/) * [在 HackerNews 上](http://news.ycombinator.com/item?id=3831865) ， [在 HackerNews 上](http://news.ycombinator.com/item?id=3804351) * [成為 Instagram 成功背后的老路](http://www.nytimes.com/2012/04/14/technology/instagram-founders-were-helped-by-bay-area-connections.html) * [Instagram 的用戶數現在達到 4000 萬，在過去 10 天內吸引了 1000 萬新用戶](http://techcrunch.com/2012/04/13/instagrams-user-count-now-at-40-million-saw-10-million-new-users-in-last-10-days/) * [在十二小時內使 Instagram 擁有超過一百萬的新用戶](http://instagram-engineering.tumblr.com/post/20541814340/keeping-instagram-up-with-over-a-million-new-users-in) > 通過存儲在 Redis 中的列表傳遞給關注者。 對于跟隨該用戶的每個人，媒體 ID 都會被推送到列表中。 在渲染提要時，它們會獲取少量 ID，并在 memcached 中查找它們 我是 Web 技術的新手，很好奇：在服務器上已經設置 Redis 時使用 memcached 有什么意義？ 謝謝。 @Oleg：我認為 user_id 可能在存儲的 redis 中，并且 memcache 將使整個用戶記錄+來自主數據存儲的聯接數據。 知道 Instagram 圖片的磁盤平均大小是多少嗎？