# 縮放 Pinterest-兩年內每月從 0 到十億的頁面瀏覽量 > 原文： [http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html)  Pinterest 一直處于指數增長曲線，每個月半翻倍。 兩年來，他們的瀏覽量已經從每月 0 增至 100 億，從 2 位創始人和一位工程師到 40 多位工程師，從一臺小型 MySQL 服務器到 180 個 Web 引擎，240 個 API 引擎，88 個 MySQL DB（cc2。 8xlarge），每個+ 1 個從屬，110 個 Redis 實例和 200 個 Memcache 實例。 驚人的增長。 那么 Pinterest 的故事是什么？ 告訴他們的故事，我們有我們的吟游詩人，Pinterest 的 [Yashwanth Nelapati](http://www.linkedin.com/in/yashh) 和 [Marty Weiner](http://pinterest.com/martaaay/) ，他在 [Scaling Pinterest](http://www.infoq.com/presentations/Pinterest) 演講中講述了 Pinterest 架構演變的戲劇性故事。 這是一年半前他們想要快速擴展并且有很多選擇的時候他們希望聽到的演講。 他們做出了許多錯誤的選擇。 這是一個很棒的話題。 它充滿了驚人的細節。 它也是非常實用，扎根的，并且包含幾乎任何人都可以采用的策略。 強烈推薦。 我在演講中最喜歡的兩個課程： 1. 當可以通過添加更多相同的東西來處理增長時，體系結構就做對了。 您希望能夠通過在問題上投入資金來擴展規模，這意味著您可以根據需要在問題上投入更多的資金。 如果您的架構能夠做到這一點，那么您就很聰明。 2. 當您將某些事情推到極限時，所有技術都會以自己的特殊方式失敗。 這導致他們在評估工具選擇時偏向于成熟的工具； 真的很好，很簡單； 眾所周知和喜歡 良好的支持； 始終表現出色； 盡可能無故障； 自由。 他們使用這些條件選擇了：MySQL，Solr，Memcache 和 Redis。 卡桑德拉（Cassandra）和蒙哥（Mongo）被撤職。 這兩個課程是相互關聯的。 遵循（2）中原理的工具可以通過添加更多框來擴展。 隨著負載的增加，成熟的產品應該會遇到更少的問題。 當您遇到問題時，至少會有一個社區來解決問題。 這是因為您的工具過于棘手又太挑剔，以至于撞到了很高的墻壁，無法攀爬。 在整個討論中，我認為這是最好的部分，在討論分片為什么比群集更好的過程中，您會看到通過增加資源，少量故障模式，成熟，簡單和良好的支持來實現增長的主題， 取得成果。 請注意，他們選擇的所有工具都是通過添加分片而不是通過集群來擴展的。 關于為什么他們更喜歡分片以及如何分片的討論確實很有趣，并且可能涵蓋了您以前從未考慮過的領域。 現在，讓我們看看 Pinterest 如何擴展： ## 基礎知識 * 引腳是一幅包含其他信息位的圖像，描述了對用戶重要的內容，并鏈接回其找到位置。 * Pinterest 是一個社交網絡。 您可以關注他人和董事會。 * 數據庫：他們的用戶擁有板，板具有引腳； 追蹤并保持關系； 認證信息。 ## 于 2010 年 3 月推出-尋找自我的時代 此時，您甚至都不知道要制造什么產品。 您有想法，因此可以快速迭代和更改。 因此，您最終遇到了許多奇怪的小 MySQL 查詢，這些查詢在現實生活中是永遠不會做的。 此早期日期的數字： * 2 位創始人 * 1 位工程師 * 機架空間 * 1 個小型網絡引擎 * 1 個小型 MySQL 數據庫 ## 2011 年 1 月 仍處于隱身模式，并且該產品正在根據用戶反饋發展。 數字： * Amazon EC2 + S3 + CloudFront * 1 個 NGinX，4 個 Web 引擎（用于冗余，而不是用于負載） * 1 個 MySQL DB + 1 個讀從站（以防主機崩潰） * 1 個任務隊列+ 2 個任務處理器 * 1 個 MongoDB（用于計數器） * 2 個工程師 ## 到 2011 年 9 月-實驗時代 他們瘋狂地奔跑著，他們每個月都翻一番。 瘋狂的增長。 * 當您快速成長時，每個晚上和每個星期都會崩潰。 * 此時，您閱讀了許多白皮書，說僅是一個盒子，您就完成了。 因此，他們開始增加很多技術。 他們都壞了。 * 結果，您最終得到了非常復雜的圖片： * Amazon EC2 + S3 + CloudFront * 2NGinX，16 個 Web 引擎+ 2 個 API 引擎 * 5 個功能明確的 MySQL DB + 9 個讀取從站 * 4 個 Cassandra 節點 * 15 個 Membase 節點（3 個獨立的群集） * 8 個 Memcache 節點 * 10 個 Redis 節點 * 3 個任務路由器+ 4 個任務處理器 * 4 個彈性搜索節點 * 3 個 Mongo 群集 * 3 個工程師 * 僅針對數據的 5 種主要數據庫技術。 * 增長如此之快，以至于 MySQL 變得炙手可熱，所有其他技術也被推向了極限。 * 當您將某些技術推向極限時，所有這些技術都會以自己的特殊方式失敗。 * 開始放棄技術并問自己自己真正想要成為什么。 對所有內容進行了大規模的重新架構。 ## 2012 年 1 月-成熟期 * 重新整理一切之后，系統現在看起來像： * 亞馬遜 EC2 + S3 + Akamai，ELB * 90 個 Web 引擎+ 50 個 API 引擎 * 66 個 MySQL DB（m1.xlarge）+每個從站 1 個 * 59 個 Redis 實例 * 51 個 Memcache 實例 * 1 個 Redis 任務管理器+ 25 個任務處理器 * 碎片 Solr * 6 位工程師 * 現在使用分片的 MySQL，Redis，Memcache 和 Solr。 而已。 優勢在于它是非常簡單和成熟的技術 * Web 流量一直以相同的速度增長，而 iPhone 流量開始上升。 ## 2012 年 10 月 12 日-回歸的時代 大約是一月份的四倍。 * The numbers now looks like: * 3 級，Akamai，Amazon EC2 + S3 + Edge Cast * 180 個 Web 引擎+ 240 個 API 引擎 * 88 個 MySQL DB（cc2.8xlarge）+每個 1 個從數據庫 * 110 個 Redis 實例 * 200 個 Memcache 實例 * 4 個 Redis 任務管理器+ 80 個任務處理器 * 碎片索爾 * 40 名工程師（并且正在不斷增長） * 請注意，該架構正在做正確的事情。 增長是通過添加更多相同的東西。 您希望能夠通過花錢解決問題來擴展規模。 您只需要在需要時就可以扔出更多盒子。 * 現在移至 SSD ## 為什么選擇 Amazon EC2 / S3？ * 相當不錯的可靠性。 數據中心也會崩潰。 多租戶會增加一些風險，但這還不錯。 * 良好的報告和支持。 他們的架構師非常好，他們知道問題 * 不錯的外圍設備，尤其是在您成長的時候。 您可以啟動 App Engine 并與他們的托管緩存，負載平衡，地圖縮減，托管數據庫以及您無需自己編寫的所有其他部分進行對話。 您可以引導亞馬遜的服務，然后在擁有工程師的情況下對其進行改進。 * 數秒內即可使用新實例。 云的力量。 特別是有了兩名工程師，您不必擔心容量規劃或等待兩周來獲取內存緩存的情況。 只需幾分鐘即可添加 10 個內存緩存。 * 缺點：選擇有限。 直到最近，您才能獲得 SSD，并且無法獲得大容量 RAM 配置。 * 優點：選擇有限。 您最終不會得到很多配置不同的盒子。 ## 為什么選擇 MySQL？ * 真的很成熟。 * 非常牢固。 對于他們來說，它永遠不會失敗，并且永遠不會丟失數據。 * 您可以租用它。 許多工程師都了解 MySQL。 * 對請求速率的響應時間線性增加。 當請求率達到峰值時，某些技術的響應也不會很好。 * 很好的軟件支持-XtraBackup，Innotop，Maatkit * 很棒的社區。 回答問題很容易。 * Percona 等公司提供了很好的支持。 * 免費-當您最初沒有任何資金時很重要。 ## 為什么使用 Memcache？ * 非常成熟。 * 真的很簡單。 這是一個哈希表，其中插入了一個套接字。 * 始終表現出色 * 眾所周知，很喜歡。 * 始終表現良好。 * 永不崩潰。 * 免費 ## 為什么要使用 Redis？ * 還不成熟，但確實非常好，非常簡單。 * 提供各種數據結構。 * 具有持久性和復制性，可以選擇實現它們的方式。 如果您想要 MySQL 樣式的持久性，可以擁有它。 如果您不需要持久性，可以擁有它。 或者，如果您想要 3 個小時的持久性，則可以擁有它。 * 您的家庭供稿位于 Redis 上，每 3 小時保存一次。 沒有 3 小時的復制。 他們僅每 3 小時備份一次。 * 如果將數據存儲在模具上的盒子中，則它們僅備份了幾個小時。 它并不完全可靠，但更簡單。 您不需要復雜的持久性和復制。 它的架構更簡單，更便宜。 * 眾所周知，很喜歡。 * Consistently good performance. * 少數故障模式。 您需要了解一些微妙的故障模式。 這就是成熟的源頭。只是學習它們并超越它。 * Free ## Solr * 很棒的起床型產品。 安裝它，幾分鐘后您將建立索引。 * 不能超過一個框。 （最新版本并非如此） * 嘗試了彈性搜索，但從規模上看，它遇到了很多小文檔和很多查詢的麻煩。 * 現在使用 Websolr。 但是他們有一個搜索小組，并且會自己動手。 ## 聚類與分片 * 在快速增長期間，他們意識到他們將需要平均分布數據以應對不斷增長的負載。 * 定義了一個討論該問題的頻譜，他們提出了“聚類”和“分片”之間的一系列選擇。 ### 群集-一切都是自動的： * 示例：Cassandra，MemBase，HBase * 判決：太可怕了，也許在將來，但是現在它太復雜了，故障模式太多了。 * 屬性： * 數據自動分發 * 數據可以移動 * 重新平衡以分配容量 * 節點相互通信。 大量的串擾，閑聊和談判。 * 優點： * 自動擴展您的數據存儲。 白皮書至少是這樣說的。 * 易于設置。 * 在空間上分布和放置數據。 您可以將數據中心放置在不同的區域，而數據庫則由它來處理。 * 高可用性 * 負載平衡 * 沒有單點故障 * 缺點（根據第一手經驗）： * 還很年輕。 * 從根本上講復雜。 整個節點必須對稱一致，這是生產中很難解決的問題。 * 較少的社區支持。 社區的產品線不同，因此每個陣營的支持都較少。 * 具有工作知識的工程師更少。 可能大多數工程師都沒有使用 Cassandra。 * 困難而令人恐懼的升級機制。 可能與它們都使用 API??并相互之間進行交談有關，所以您不希望它們混淆。 這導致復雜的升級路徑。 * 集群管理算法是 SPOF。 如果有錯誤，它將影響每個節點。 這使他們失望了 4 次。 * 群集管理器是在具有以下故障模式的所有節點上復制的復雜代碼： * 數據重新平衡中斷。 帶來一個新盒子，數據開始復制，然后被卡住。 你是做什么？ 沒有工具可以弄清楚發生了什么。 沒有社區可以幫助，所以他們陷入了困境。 他們回到了 MySQL。 * 所有節點上的數據損壞。 如果存在一個錯誤，該錯誤會在所有日志中將錯誤注入到寫入日志中，并且壓縮或其他機制停止了，該怎么辦？ 您的閱讀延遲會增加。 您所有的數據都被搞砸了，數據消失了。 * 無法輕松解決的不正確平衡。 很常見的。 您有 10 個節點，并且注意到所有節點都在一個節點上。 這是一個手動過程，但是它將負載重新分配回一個節點。 * 數據授權失敗。 群集方案非常聰明。 在一種情況下，他們帶來了新的中學。 大約 80％的輔助節點表示它是主要節點，而主要節點轉到輔助節點，您已經丟失了 20％的數據。 丟失 20％的數據比丟失所有數據更糟糕，因為您不知道丟失了什么。 ### 分片-一切都是手動的： * 裁決：獲勝者。 注意，我認為它們的分片架構與 [Flickr 架構](http://highscalability.com/blog/2007/11/13/flickr-architecture.html) 有很多共同點。 * Properties: * 擺脫所有您不喜歡的聚類屬性，即可進行分片。 * 手動分發的數據 * 數據不動。 盡管有些人這樣做，但他們從未移動數據，這使它們在頻譜上處于更高的位置。 * 拆分數據以分配負載。 * 節點彼此之間不認識。 一些主節點控制一切。 * Pros: * 可以拆分數據庫以增加容量。 * 在空間上分配和配置您的數據 * High availability * Load balancing * 放置數據的算法非常簡單。 主要原因。 有 SPOF，但只有半頁代碼，而不是非常復雜的 Cluster Manager。 在第一天之后，它會起作用或不起作用。 * ID 生成很簡單。 * 缺點： * 無法執行大多數加入。 * 失去了所有交易功能。 成功寫入另一個數據庫時，對一個數據庫的寫入可能會失敗。 * 必須將許多約束移到應用程序層。 * 模式更改需要更多計劃。 * 報表需要在所有分片上運行查詢，然后自己執行所有聚合。 * 聯接在應用程序層中執行。 * 您的應用程序必須容忍所有這些問題。 ### 什么時候分片？ * 如果您的項目將有幾 TB 的數據，則應盡快分片。 * 當 Pin 表達到 10 億行時，索引用完了內存，它們正在交換到磁盤。 * 他們選擇了最大的表并將其放在自己的數據庫中。 * 然后它們在單個數據庫上用完了空間。 * 然后他們不得不分片。 ### 轉換為分片 * 從凍結功能開始過渡過程。 * 然后，他們決定了如何分片。 想要執行最少數量的查詢并轉到最少數量的數據庫以呈現單個頁面。 * 刪除了所有 MySQL 連接。 由于可以將表加載到單獨的分區中，因此聯接將不起作用。 * 添加了大量的緩存。 基本上每個查詢都必須被緩存。 * 步驟如下： * 1 個 DB +外鍵+加入 * 1 個 DB +規范化+緩存 * 1 個 DB +讀取從站+緩存 * 幾個功能分區的 DB +讀取從站+緩存 * ID 分片的 DB +備份從屬+緩存 * 由于奴隸滯后，較早讀取的奴隸成為一個問題。 讀取將發送給從屬設備，而主設備尚未復制記錄，因此看起來好像丟失了記錄。 解決這個問題需要緩存。 * 他們具有后臺腳本，該腳本重復了數據庫過去的工作。 檢查完整性約束，參考。 * 用戶表未分片。 他們只是使用大型數據庫，并且對用戶名和電子郵件具有唯一性約束。 如果不是唯一的，則插入用戶將失敗。 然后，他們在分片數據庫中進行了大量寫操作。 ### 如何分割？ * 看了 Cassandra 的戒指模型。 看著 Membase。 并看著 Twitter 的 Gizzard。 * 確定：跨節點移動的數據最少，體系結構就更穩定。 * Cassandra 存在數據平衡和權限問題，因為節點不確定誰擁有數據的哪一部分。 他們決定應用程序應該決定數據應該去哪里，所以永遠不會有問題。 * 預測了他們未來五年的增長，并牢記這一容量計劃。 * 最初創建了許多虛擬分片。 8 臺物理服務器，每個服務器有 512 個 DB。 所有數據庫都有所有表。 * 為了獲得高可用性，它們始終在多主復制模式下運行。 每個主服務器都分配到一個不同的可用區。 發生故障時，切換到另一個主節點，并引入一個新的替換節點。 * 當數據庫上的負載增加時： * 查看代碼提交，以查看是否發生了新功能，緩存問題或其他問題。 * 如果只是增加負載，他們就會拆分數據庫，并告訴應用程序在新主機上查找數據。 * 在拆分數據庫之前，它們會啟動這些主服務器的從服務器。 然后，他們用新的數據庫分配交換應用程序代碼。 在過渡期間的幾分鐘內，寫入仍將寫入舊節點，并被復制到新節點。 然后在節點之間切割管道。 ### ID 結構 * 64 位： * 分片 ID：16 位 * 類型：10 位-引腳，板，用戶或任何其他對象類型 * 本地 ID-表中 ID 的其余位。 使用 MySQL 自動遞增。 * Twitter 使用映射表將 ID 映射到物理主機。 這需要查找。 由于 Pinterest 在 AWS 上并且 MySQL 查詢花費了大約 3 毫秒，因此他們決定這種額外級別的間接操作將不起作用。 他們將位置內置到 ID 中。 * 新用戶隨機分布在各個分片上。 * 用戶的所有數據（引腳，板等）都位于同一分片上。 巨大的優勢。 例如，呈現用戶個人資料不會進行多個交叉分片查詢。 它很快。 * 每個板都與用戶并置，因此可以從一個數據庫中呈現板。 * 足以容納 65536 個分片的分片 ID，但最初它們僅打開 4096，它們將水平擴展。 用戶數據庫用完后，他們將打開更多的分片，并允許新用戶訪問新的分片。 ### 查找 * 例如，如果他們有 50 個查詢，他們將拆分 ID 并并行運行所有查詢，因此等待時間是最長的等待時間。 * 每個應用程序都有一個配置文件，該文件將分片范圍映射到物理主機。 * “ sharddb001a”：：( 1，512） * “ sharddb001b” ：：（513，1024）-備份熱備機 * 如果要查找 ID 屬于 sharddb003a 的用戶： * 將 ID 分解為各個部分 * 在分片圖中執行查找 * 連接到分片，轉到類型的數據庫，然后使用本地 ID 查找合適的用戶并返回序列化的數據。 ### 對象和映射 * 所有數據都是對象（引腳，面板，用戶，注釋）或映射（用戶具有面板，引腳具有點贊）。 * 對于對象，本地 ID 映射到 MySQL Blob。 Blob 格式以 JSON 開頭，但現在已轉為序列化節儉。 * 對于映射，有一個映射表。 您可以要求用戶提供所有板。 這些 ID 包含時間戳記，因此您可以查看事件的順序。 * 有一個反向映射（多對多表），用于回答該類型的查詢，這給了我所有喜歡此引腳的用戶。 * 模式命名方案為 noun_verb_noun：user_likes_pins，pins_like_user。 * 查詢是主鍵或索引查找（無聯接）。 * 數據不會像集群一樣在數據庫中移動。 例如，一旦用戶登陸到分片 20，并且所有用戶數據都并置在一起，它將永遠不會移動。 64 位 ID 包含分片 ID，因此無法移動。 您可以將物理數據移動到另一個數據庫，但仍與同一分片關聯。 * 所有表都存在于所有分片上。 沒有特殊的分片，不計算用于檢測用戶名沖突的龐大用戶表。 * 無需更改架構，并且新索引需要新表。 * 由于鍵的值為 blob，因此您可以添加字段而不會破壞架構。 每個 Blob 上都有版本控制，因此應用程序將檢測版本號，并將記錄更改為新格式并寫回。 無需一次更改所有數據，將在讀取時進行升級。 * 巨大的勝利，因為更改桌子需要數小時或數天的鎖定。 如果要新索引，只需創建一個新表并開始填充它。 當您不再需要時，請將其放下。 （沒有提及這些更新如何確保交易安全）。 ### 呈現用戶個人資料頁面 * 從 URL 獲取用戶名。 轉到單個大型數據庫以查找用戶 ID。 * 獲取用戶 ID 并將其拆分為各個組成部分。 * 選擇分片并轉到該分片。 * 來自用戶的 SELECT 正文，其中 id = < local_user_id > * 從 user_has_boards 中選擇 board_id，其中 user_id = < user_id > * 從 ID 為 IN 的板子中選擇主體（< boards_ids >） * 從 board_has_pins 中選擇 pin_id，而 board_id = < board_id > * 從 ID 為 IN 的引腳（PIN_ID）中選擇主體 * 大多數調用是通過緩存（內存緩存或 Redis）提供的，因此實際上并沒有很多數據庫查詢。 ### 腳本編寫 * 遷移到分片式架構時，您有兩種不同的基礎結構，一種是舊的非分片系統，另一種是新的分片系統。 腳本是將舊內容轉移到新內容的所有代碼。 * 他們移動了 5 億個引腳和 16 億個追隨者行，等等 * 低估了項目的這一部分。 他們認為將數據放入碎片中需要 2 個月，而實際上需要 4-5 個月。 記住，這是在功能凍結期間。 * 應用程序必須始終寫入新舊基礎結構。 * 一旦確定所有數據都在新的基礎架構中，然后將您的讀取指向新的基礎架構，然后慢慢增加負載并測試后端。 * 建立了腳本農場。 動員更多的工人來更快地完成任務。 他們將執行諸如將這些表移至新基礎架構之類的任務。 * 竊取了 Pyres 副本，這是 Github Resque 隊列的 Python 接口，該隊列基于 Redis 構建。 支持優先級和重試。 太好了，他們用 Pyres 代替了 Celery 和 RabbitMQ。 * 該過程中有很多錯誤。 用戶發現錯誤，例如缺少板。 必須多次運行該過程，以確保沒有暫時性錯誤阻止數據正確移動。 ## 開發 * 最初嘗試為開發人員提供系統的一部分。 每個服務器都有自己的 MySQL 服務器等，但是事情變化如此之快，因此無法正常工作。 * 轉到 Facebook 的模式，每個人都可以訪問所有內容。 因此，您必須非常小心。 ## 未來方向 * 基于服務的體系結構。 * 隨著他們開始看到大量的數據庫負載，他們開始產生許多應用程序服務器和許多其他服務器。 所有這些服務器都連接到 MySQL 和內存緩存。 這意味著內存緩存上有 30K 連接，占用了數 GB 的 RAM，并導致內存緩存守護進程交換。 * 作為解決方法，它們正在遷移到服務體系結構。 例如，有一個追隨者服務，它將僅回答追隨者查詢。 這樣可以將訪問數據庫和緩存的計算機數量限制為 30，從而減少了連接數量。 * 幫助隔離功能。 幫助圍繞服務和支持這些服務組織團隊。 開發人員無法訪問其他服務，從而提高了安全性。 ## 獲得的經驗教訓 * 將失敗。 把事情簡單化。 * 保持樂趣。 有很多新人加入這個團隊。 如果您只是給他們一個龐大的復雜系統，那將不會很有趣。 保持架構簡單是一個巨大的勝利。 從第一周開始，新工程師就開始提供代碼。 * When you push something to the limit all these technologies fail in their own special way. * 當可以通過添加更多相同的東西來處理增長時，體系結構就做對了。 您希望能夠通過在問題上投入更多盒子來解決問題，從而根據需要擴展規模。 如果您的架構能夠做到這一點，那么您就很聰明。 * Cluster Management Algorithm is a SPOF. If there’s a bug it impacts every node. This took them down 4 times. * 要應對快速增長，您需要平均分配數據以應對不斷增長的負載。 * 跨節點移動的數據最少，體系結構就更穩定。 這就是為什么他們在群集上進行分片。 * 面向服務的體系結構規則。 它隔離功能，幫助減少連接，組織團隊，組織支持并提高安全性。 * 問自己，你真正想要成為什么。 即使您必須重新構建所有架構，也要刪除符合該愿景的技術。 * 不要害怕丟失一些數據。 它們將用戶數據保留在內存中并定期將其寫出。 丟失意味著僅丟失了幾個小時的數據，但是最終的系統卻變得更加簡單和強大，這才是重要的。 ## 相關文章 * [討論黑客新聞](https://news.ycombinator.com/item?id=5552504) * [Pinterest 體系結構更新-1800 萬訪問者，增長 10 倍，擁有 12 名員工，410 TB 數據](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html) * [用于處理 3 百萬以上用戶的 Pinterest 堆棧中的一個短項](http://highscalability.com/blog/2012/2/16/a-short-on-the-pinterest-stack-for-handling-3-million-users.html) * [Pinterest 通過自動關閉系統將費用從每小時 54 美元降低到 20 美元](http://highscalability.com/blog/2012/12/12/pinterest-cut-costs-from-54-to-20-per-hour-by-automatically.html) * [Instagram 體系結構更新：Instagram 有何新功能？](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html) * [Facebook 過去曾增長到 5 億用戶的 7 種擴展策略](http://highscalability.com/blog/2010/8/2/7-scaling-strategies-facebook-used-to-grow-to-500-million-us.html)和 [Facebook](http://highscalability.com/blog/2010/6/10/the-four-meta-secrets-of-scaling-at-facebook.html) 擴展的四個元秘密-我認為您會在他們的方法中找到一些相似之處。 一個小的更正，“ Web Solr”應實際讀取為“ Websolr”，如 http://websolr.com/ 非常感謝你的這篇文章。 簡單明了地指出了每個方面：） 沒有提及實際的 Web 應用程序使用什么編程語言和框架。 請告訴我他們沒有在 PHP 中執行此操作... Python ... Pinterest 一直被吹噓為 DJango 實現。 看到這里：http://www.quora.com/Pinterest/What-technologies-were-used-to-make-Pinterest 有人知道他們是否仍將 Nginx 用作應用服務器負載平衡器嗎？ 在“為什么要 Amazon EC2 / S3”部分下，提到了“ App Engine”。 這讓我感到困惑（因為 App Engine 是 Google，而不是 Amazon）。 有人可以澄清嗎？ 交換？ 刪除交換，交換比失敗誘餌更糟糕。 停機服務器比 ssssllllllooooooowwwww 服務器更好。 繞開 CDN 的原因是什么？ 有人知道他們如何存儲圖像嗎？ 在 mysql，磁盤還是其他地方？ 例如，URL“ http://media-cache-ec4.pinimg.com/736x/cf/d7/49/cfd74959947950dd0c3c1ef8ef2f1582.jpg”中的 imageid 可能包含一些信息？ 謝謝 很想知道更多有關 Mongo 為什么被刪除的信息，以支持在 MySQL 中存儲無模式的 Blob。 這僅僅是錯誤，性能低下的問題嗎？ 好像 Mongo 是為這種 BASE 體系結構設計的，如果它可以很好地運行，則無需在應用程序層手動管理索引的開銷。 小修正：在您喜歡的講座的 2 課中的第 1 課中，您說“您是建筑”而不是“您的建筑”。 非常有趣的閱讀。 誰能解釋： 對于對象，本地 ID 映射到 MySQL Blob。 Blob 格式以 JSON 開頭，但現在已轉為序列化節儉。 為什么本地 ID 映射到 mysql Blob？ 感謝您發布此信息。 看到架構的潮起潮落總是讓人著迷。 但是，我不同意本文的最后一點。 > 不要害怕丟失一些數據。 該陳述完全取決于所討論數據的使用。 在 Pinterest 的情況下，我可以看到它完全可以實現。 所涉及的數據沒有貨幣價值，如果丟失了任何人的生命都不會受到特別的影響。 但是，我認為區分不重要的數據丟失和重要的數據非常重要。 當您說“ Web Engine”時，您指的是什么？ 這是否意味著另一個克隆了主應用程序的云實例？ 你好 我很好奇，當一個用戶數據過大而又無法容納一個分片時，會發生什么？ 此致 拉希德 有人能粗略估計一下這些設置每個月要花費多少嗎？ 為什么同時使用 Memcache 和 Redis？ Redis 幾乎可以完成 Memcache 可以做的所有事情，還有其他用途。 即使在這些年之后，這篇文章也很有意義。 感謝您抽出寶貴的時間，并詳細說明了構建簡單的可伸縮 Web 平臺需要花費的一切！