Pinterest正經歷了指數級曲線般的增長，每隔一個半月翻翻。在這兩年里，Pinterest，從 每月PV量0增長到10億，從兩名成立者和一個工程師成長為四十個工程師，從一臺MySQL 服務器增長到180臺Web 服務器(Web Engine)，240臺接口服務器(API Engine), 88臺MySQL 數據庫 (cc2.8xlarge) ，并且每臺DB有一個備份服務器，110臺Redis 實例服務（Redis Instance），200臺 Memcache 實例服務（Memcache  Instance）。

令人嘆為觀止的增長。想一探Pinterest的傳奇嗎？我們請來了Pinterest的兩位創立者Yashwanth Nelapati 和 Marty Weiner，他們將以 Scaling Pinterest為題講述關于Pinterest架構的充滿戲劇化的傳奇故事。他們說如果能在一年半前飛速發展時能看到有人做類似題材的演講的話，他們就會有更多的選擇，以避免自己在這一年半里做出的很多錯誤的決定。

這是一個很不錯的演講，充滿了令人驚訝的細節。同時這個演講也是很務實的，歸根結底，它帶來了可讓大家選擇的策略。極度推薦！

這篇演講中有兩個我最為看重的經驗：

1.強大的架構在處理增長時通過簡單增加相同的東西(服務器)來應對，同時還能保證系統的正確性。當遇到某種（性能）問題時，你想通過砸錢來擴容指的是你可以簡單增加服務器(boxes)。如果你的架構能夠做到這一點，那它就如金子一般強大而珍貴！

2. 當某些（性能問題）快到極限時大多數技術都會以他們自己的方式失敗。這導致他們在審核工具時要考慮以下一些特性：成熟，好且簡單，有名氣且用的人多，良好的支持，持續的優異性能，很少失敗，開源。按照這樣的標準，他們選擇了：MySQL, Solr, Memcache, and Redis，放棄了Cassandra ，Mongo。

這兩點經驗是相互聯系的。遵循（2）中提到的標準的工具可以在擴容時簡單增加服務器(boxes).當負載增加了，成熟的產品更少會有問題。當你遇到問題時，你至少希望它的社區團隊能夠幫助解決。當你使用的工具過于技巧化和過于講究時，你會發現你遇到一堵無法逾越的墻。

在這段演講里，碎片化（sharding）優于集群(clusterting)的觀點是我認為最好的一部分。為了應對增長，通過增加資源，更少失敗的模式，成熟，簡單，良好的支持，最終圓滿完成。請注意他們選擇的工具以sharding的方式增長，而不是clustering。關于他們為什么選擇 sharding和他們如何做sharding是很有趣的事，這很可能觸及到你以前未考慮過的場景。

現在，讓我們看看Pinterest如何擴容：

基本概念

• Pins是一幅關于其他信息的集合的圖片，描述了為什么它對于用戶來說很重要，可以鏈回到他們發現它的地方。
• Pinterest是一個社交網絡。你可以追蹤人或者板報(boards).
• Database:它包含了擁有pins的板報（boards）和擁有板報（boards）的人 ，可以追蹤或重新建立（repin）聯系，還包含認證信息。

啟動于2010年三月–自我發現時期

此時此刻，你甚至不知道你在做的這個產品將要做什么。你有想法，迭代開發更新產品的頻率很高。最終因遇到一些在現實生活中永遠不會遇到的奇怪的簡短的MySQL查詢而結束。

早期的一些數字：

• 兩個創始人
• 一個工程師
• Rackspace托管服務器
• 一個小型web引擎
• 一個小型MySQL數據庫

2011年1月

扔在潛伏前進中，產品得到了一些用戶反饋。以下是數據：

• Amazon EC2 + S3 + CloudFront云服務
• 一臺NGinX，4臺Web 引擎（作冗余用，不是真正為了負載）
• 一臺MySQL數據庫+一臺讀備份服務器（防止主服務器宕機）
• 一個任務隊列+兩個任務處理
• 一臺MongoDB（為了計數）
• 兩個工程師

至2011年9月–試運行階段

每一個半月翻翻的瘋狂增長階段。

• 當高速發展時每個晚上每個星期都會有技術失敗的情況發生
• 這時，你閱讀大量白皮書，它會告訴你把這個增加進來就行了。當他們添加了大量技術時，毫無例外都失敗了。
• 最終你得到一個極為復雜的架構圖：
  • Amazon EC2 + S3 + CloudFront
  • 2NGinX, 16 Web Engines + 2 API Engines
  • 5 Functionally Sharged MySQL DB + 9 讀備份
  • 4 Cassandra 節點
  • 15 Membase 節點(分成三個單獨的集群)
  • 8 Memcache 節點
  • 10 Redis 節點
  • 3 任務路由（Task Routers）+ 4 Task Processors
  • 4 ElasticSearch 節點
  • 3 Mongo集群
  • 3名工程師
• 5種主要的數據庫技術只為了應付他們自己的數據
• 增長極快以至MySQL負載很高，而其他一些技術都快到達極限
• 當你把某些技術的應用推至極限時，他們又以自己的方式宣告失敗。
• 放棄一些技術并問它們到底能做什么。對每一件事情重新構架，海量工作量。

#p#

架構成熟 2012 1月

重新設計的系統架構如下：

• Amazon EC2 + S3 + Akamai, ELB
• 90 Web Engines + 50 API Engines
• 66 MySQL DBs (m1.xlarge) + 1 slave each
• 59 Redis Instances
• 51 Memcache Instances
• 1 Redis Task Manager + 25 Task Processors
• Sharded Solr
• 6 Engineers .使用Mysql，Redis，Memcache Solr，他們的優勢是簡單高效并且是成熟的技術。 隨著Web流量增加，Iphone的流量也隨之開始越來越大。
  穩定期 2012 10月 12 僅僅在一月份以后，大概就有4倍的流量增長。 系統架構數據如下： The numbers now looks like:

   

  • Amazon EC2 + S3 + Edge Cast,Akamai, Level 3
  • 180 Web Engines + 240 API Engines
  • 88 MySQL DBs (cc2.8xlarge) + 1 slave each
  • 110 Redis Instances
  • 200 Memcache Instances
  • 4 Redis Task Manager + 80 Task Processors
  • Sharded Solr
  • 40 Engineers (and growing)

  注意到，此時的架構應該是合理的，只是通過增加更多的服務器。你認為此時通過更多的投入來應對這么大的規模的流量，投入更多的硬件來解決這個問題， 下一步 遷移到SSDs

為什么是Amazon EC2/S3

• 相當的可靠。數據中心也會宕機， Multitenancy 加入了不少風險，但不是壞處。
• 良好的匯報和支持。他們確實有很不錯的架構師而且他們知道問題在哪里。
• 良好的額外服務支持（peripherals），特別是當你的應用處于增長時期。你可能在App Engine中轉暈，你不用親自去實現，只需要簡單和他們的服務打交道，例如maged cache，負載均衡，映射和化簡，數據庫和其他所有方面。Amazon的服務特別適合起步階段，之后你可以招聘工程師來優化程序。
• 分秒鐘獲得新的服務實例。這是云服務的威力。特別是當你只有兩名工程師，你不用擔心容量規劃或者為了10臺memcache服務器等上兩周。10臺memcache服務器幾分鐘內就能加完。
• 反對的理由：有限的選擇。直到最近你才能用SSD而且還沒高內存配置的方案。
• 贊成的理由：還是有限的選擇。你不需要面對一大堆配置迥異的服務器。

為什么是 MySQL？

• 非常成熟
• 非常耐用。從不宕機且不會丟失數據。
• 招聘方便，一大堆工程師懂MySQL.
• 反應時間和請求數量（requies rate，我認為是request rate參考下面）是線性增長的。有些數據庫技術的反應時間在請求飆升時不是很好。
• 很好的軟件支持– XtraBackup, Innotop, Maatkit
• 很好的社區，問的問題總能輕易獲取到答案
• 很好的廠商支持，譬如Percona
• 開源–這一點很重要，特別是你剛開始沒有很多資金支持時。

為什么選擇Memcache?

• 非常成熟
• 非常簡單。它就是一個socket的哈希表。
• 性能一直很好
• 很多人知道并喜歡
• 從不崩潰
• 免費

為什么選擇Redis?

• 還不成熟，但它是非常好并且相當簡單。
• 提供了各種的數據結構。
• 可以持久化和復制，并且可以選擇如何實現它們。你可以用MySQL風格持久化，或者你可以不要持久化，或者你只要3小時的持久化。
• Redis上的數據只保存3個小時，沒有3小時以上的復本。他們只保留3個小時的備份。
• 如果存儲數據的設備發生故障，而它們只是備份了幾個小時。這不是完全可靠的，但它很簡單。你并不需要復雜的持久化和復制。這是一個更簡單，更便宜的架構。
• 很多人知道并喜歡
• 性能一直很好
• 很少的一些故障。你需要了解一些小故障，學習并解決它們，使它越來越成熟。
• 免費

Solr

• 只需要幾分鐘的安裝時間，就可以投入使用
• 不能擴展到多于一臺的機器上（最新版本并非如此）
• 嘗試彈性搜索，但是以Pinterest的規模來說，可能會因為零碎文件和查詢太多而產生問題。
• 選擇使用Websolr，但是Pinterest擁有搜索團隊，將來可能會開發自己的版本。

集群vs.分片

• 在迅速擴展的過程中，Pinterest認識到每次負載的增加，都需要均勻的傳播他們的數據。
• 針對問題先確定解決方案的范圍，他們選擇的范圍是集群和分片之間的一系列解決方案。

集群 —— 所有事情都是自動化的

• 示例: Cassandra, MemBase, HBase
• 結論: 太可怕了，不是在現在，可能在將來，但現在太復雜了，有非常多的故障點
• 屬性:
  • 自動化數據分布
  • 可移動數據
  • 可重新進行分布均衡
  • 節點間可通訊，大量的握手、對話
• 有點:
  • 自動伸縮數據存儲，至少白皮書上是這么說的
  • 安裝簡單
  • 在空間中分布存儲你的數據，可在不同區域有數據中心
  • 高可用性
  • 負載均衡
  • 沒有單點故障
• 缺點 (來自用戶一手的體驗):
  • 還是相當年輕不成熟
  • 還是太復雜，一大堆節點必須對稱的協議,這是一個在生產環境中難以解決的問題。
  • 很少的社區支持，有一個沿著不同產品線的分裂社區會減少每個陣營的支持。
  • 很少工程師有相關的知識，可能是很多工程師都沒用過 Cassandra.
  • 復雜和和可怕的升級機制
  • 集群管理算法是一個 SPOF 單點故障，如果有個 bug 影響每個節點，這可能會宕機 4 次。
  • 集群管理器編碼復雜，有如下一些失敗的模式：
    • 數據重新均衡中斷：當一個新機器加入然后數據開始復制,它被卡住了。你做什么工作?沒有工具來找出到底發生了什么。沒有社會的幫助,所以他們被困。他們又回到了MySQL。
    • 所有節點的數據損壞. What if there’s a bug that sprays badness into the write log across all of them and compaction or some other mechanism stops? Your read latencies increase. All your data is screwed and the data is gone.
    • 均衡不當而且很難修復. 非常常見，如果你有10個節點，你會注意到所有節點都在一個節點上，有一個手工處理方式，但會將所有負載分布到一個單節點上
    • 權威數據失效. 集群方案是很智能的。In one case they bring in a new secondary. At about 80% the secondary says it’s primary and the primary goes to secondary and you’ve lost 20% of the data. Losing 20% of the data is worse than losing all of it because you don’t know what you’ve lost.

分片(sharding) – 全憑人手

• 裁決: 分片是贏家。我覺得他們分片的方案與Flicker非常相似。
• 特點:
  • 如果去掉集群方式下所有不好的特點，就得到了分片。
  • 人工對數據進行分布。
  • 不移動數據。
  • 通過切分數據來分擔負荷。
  • 節點不知道其它節點的存在。某些主節點控制一切。
• 優點:
  • 可以通過切分數據庫來擴大容量。
  • 在空間上分布數據。
  • 高可用。
  • 負載均衡。
  • 放置數據的算法十分簡單。這是最主要的原因。雖然存在單點(SPOF)，但只是很小的一段代碼，而不是復雜到爆的集群管理器。過了第一天就知道有沒有問題。
  • ID的生成很簡單。
• 缺點:
  • 無法執行大多數連接。
  • 沒有事務功能。可能會出現寫入某個數據庫失敗、而寫入其它庫成功的情況。
  • 許多約束只能轉移到應用層實現。
  • schema的修改需要更多的規劃。
  • 如果要出報表，必須在所有分片上分別執行查詢，然后自己把結果合起來。
  • 連接只能轉移到應用層實現。
  • 應用必須應付以上所有的問題。

#p#

何時選擇分片？

• 當有幾TB的數據時，應該盡快分片。
• 當Pin表行數達到幾十億，索引超出內存容量，被交換到磁盤時。
• 他們選出一個最大的表，放入單獨的數據庫。
• 單個數據庫耗盡了空間。
• 然后，只能分片。

分片的過渡

• 過渡從一個特性的凍結開始。

• 確認分片該達到什么樣的效果——希望盡少的執行查詢以及最少數量的數據庫去呈現一個頁面。

• 剔除所有的MySQL join，將要做join的表格加載到一個單獨的分片去做查詢。

• 添加大量的緩存，基本上每個查詢都需要被緩存。

• 這個步驟看起來像：

• 1 DB + Foreign Keys + Joins
• 1 DB + Denormalized + Cache
• 1 DB + Read Slaves + Cache
• Several functionally sharded DBs+Read Slaves+Cache
• ID sharded DBs + Backup slaves + cache

• 早期的只讀奴節點一直都存在問題，因為存在slave lag。讀任務分配給了奴節點，然而主節點并沒有做任何的備份記錄，這樣就像一條記錄丟失。之后Pinterest使用緩存解決了這個問題。

• Pinterest擁有后臺腳本，數據庫使用它來做備份。檢查完整性約束、引用。

• 用戶表并不進行分片。Pinterest只是使用了一個大型的數據庫，并在電子郵件和用戶名上做了相關的一致性約束。如果插入重復用戶，會返回失敗。然后他們對分片的數據庫做大量的寫操作。

如何進行分片?

• 可以參考Cassandra的ring模型、Membase以及Twitter的Gizzard。
• 堅信：節點間數據傳輸的越少，你的架構越穩定。
• Cassandra存在數據平衡和所有權問題，因為節點們不知道哪個節點保存了另一部分數據。Pinterest認為應用程序需要決定數據該分配到哪個節點，那么將永遠不會存在問題。
• 預計5年內的增長，并且對其進行預分片思考。
• 初期可以建立一些虛擬分片。8個物理服務器，每個512DB。所有的數據庫都裝滿表格。
• 為了高有效性，他們一直都運行著多主節點冗余模式。每個主節點都會分配給一個不同的可用性區域。在故障時，該主節點上的任務會分配給其它的主節點，并且重新部署一個主節點用以代替。
• 當數據庫上的負載加重時：

• 先著眼節點的任務交付速度，可以清楚是否有問題發生，比如：新特性，緩存等帶來的問題。
• 如果屬于單純的負載增加，Pinterest會分割數據庫，并告訴應用程序該在何處尋找新的節點。
• 在分割數據庫之前，Pinterest會給這些主節點加入一些奴節點。然后置換應用程序代碼以匹配新的數據庫，在過渡的幾分鐘之內，數據會同時寫入到新舊節點，過渡結束后將切斷節點之間的通道。

ID結構

• 一共64位

• 分片ID：16位
• Type：10位—— Board、User或者其它對象類型
• 本地ID——余下的位數用于表中ID，使用MySQL自動遞增。

• Twitter使用一個映射表來為物理主機映射ID，這將需要備份；鑒于Pinterest使用AWS和MySQL查詢，這個過程大約需要3毫秒。Pinterest并沒有讓這個額外的中間層參與工作，而是將位置信息構建在ID里。
• 用戶被隨機分配在分片中間。
• 每個用戶的所有數據（pin、board等）都存放在同一個分片中，這將帶來巨大的好處，避免了跨分片的查詢可以顯著的增加查詢速度。
• 每個board都與用戶并列，這樣board可以通過一個數據庫處理。
• 分片ID足夠65536個分片使用，但是開始Pinterest只使用了4096個，這允許他們輕易的進行橫向擴展。一旦用戶數據庫被填滿，他們只需要增加額外的分片，然后讓新用戶寫入新的分片就可以了。

查找

• 如果存在50個查找，舉個例子，他們將ID分割且并行的運行查詢，那么延時將達到最高。
• 每個應用程序都有一個配置文件，它將給物理主機映射一個分片范圍。

• “sharddb001a”: : (1, 512)
• “sharddb001b”: : (513, 1024)——主要備份主節點

• 如果你想查找一個ID坐落在sharddb003a上的用戶：

• 將ID進行分解
• 在分片映射中執行查找
• 連接分片，在數據庫中搜尋類型。并使用本地ID去尋找這個用戶，然后返回序列化數據。

對象和映射

• 所有數據都是對象（pin、board、user、comment）或者映射（用戶由baord，pin有like）。

• 針對對象，每個本地ID都映射成MySQL Blob。開始時Blob使用的是JSON格式，之后會給轉換成序列化的Thrift。

• 對于映射來說，這里有一個映射表。你可以為用戶讀取board，ID包含了是時間戳，這樣就可以體現事件的順序。

• 同樣還存在反向映射，多表對多表，用于查詢有哪些用戶喜歡某個pin這樣的操作。
• 模式的命名方案是：noun_verb_noun: user_likes_pins, pins_like_user。

• 只能使用主鍵或者是索引查找（沒有join）。

• 數據不會向集群中那樣跨數據的移動，舉個例子：如果某個用戶坐落在20分片上，所有他數據都會并列存儲，永遠不會移動。64位ID包含了分片ID，所以它不可能被移動。你可以移動物理數據到另一個數據庫，但是它仍然與相同分片關聯。

• 所有的表都存放在分片上，沒有特殊的分片，當然用于檢測用戶名沖突的巨型表除外。

• 不需要改變模式，一個新的索引需要一個新的表。

• 因為鍵對應的值是blob，所以你不需要破壞模式就可以添加字段。因為blob有不同的版本，所以應用程序將檢測它的版本號并且將新記錄轉換成相應的格式，然后寫入。所有的數據不需要立刻的做格式改變，可以在讀的時候進行更新。
• 巨大的勝利，因為改變表格需要在上面加幾個小時甚至是幾天的鎖。如果你需要一個新的索引，你只需要建立一張新的表格，并填入內容；在不需要的時候，丟棄就好。

#p#

呈現一個用戶文件界面

• 從URL中取得用戶名，然后到單獨的巨型數據庫中查詢用戶的ID。

• 獲取用戶ID，并進行拆分

• 選擇分片，并進入

• SELECT body from users WHERE id = <local_user_id>

• SELECT board_id FROM user_has_boards WHERE user_id=<user_id>

• SELECT body FROM boards WHERE id IN (<boards_ids>)

• SELECT pin_id FROM board_has_pins WHERE board_id=<board_id>

• SELECT body FROM pins WHERE id IN (pin_ids)

• 所有調用都在緩存中進行（Memcache或者Redis），所以在實踐中并沒有太多連接數據庫的后端操作。

腳本相關

• 當你過渡到一個分片架構，你擁有兩個不同的基礎設施——沒有進行分片的舊系統和進行分片的新系統。腳本成為了新舊系統之間數據傳輸的橋梁。

• 移動5億的pin、16億的follower行等。

• 不要輕視項目中的這一部分，Pinterest原認為只需要2個月就可以完成數據的安置，然而他們足足花了4至5個月時間，別忘了期間他們還凍結了一項特性。

• 應用程序必須同時對兩個系統插入數據。

• 一旦確認所有的數據都在新系統中就位，就可以適當的增加負載來測試新后端。

• 建立一個腳本農場，雇傭更多的工程師去加速任務的完成。讓他們做這些表格的轉移工作。

• 設計一個Pyres副本，一個到GitHub Resque隊列的Python的接口，這個隊列建立在Redis之上。支持優先級和重試，使用Pyres取代Celery和RabbitMQ更是讓他們受益良多。

• 處理中會產生大量的錯誤，用戶可能會發現類似丟失board的錯誤；必須重復的運行任務，以保證在數據的處理過程中不會出現暫時性的錯誤。

動態

• 最初試圖給開發者一個分片系統。每個開發者都能擁有自己的MySQL服務器，但事情發生了快速的變化，導致不能工作。變
• 去了Facebook的模式：每個人可以獲得一切。所以，你不得不非常謹慎

未來發展方向

• 基于服務的架構。
  • 當他們開始看到了很多的數據庫負載，便像產卵一樣，導致了很多的應用服務器和其他服務器堆在一起。所有這些服務器連接到MySQL和Memcache。這意味著有30K上的memcache連接了一對夫婦演出的RAM引起的memcache守護進程交換。
  • 作為一個修補程序，這些都是移動的服務架構。有一個跟隨服務，例如，將只回答跟隨查詢。此隔離的機器數目至30訪問數據庫和高速緩存，從而減少了連接。
  • 幫助隔離功能。幫助組織，解決和支持這些服務的團隊。幫助開發人員，為了安全開發人員不能訪問其他服務。

學到的知識

• 為了應對未來的問題，讓其保持簡單。

• 讓其變的有趣。只要應用程序還在使用，就會有很多的工程師加入，過于復雜的系統將會讓工作失去樂趣。讓架構保持簡單就是大的勝利，新的工程師從入職的第一周起就可以對項目有所貢獻。

• 當你把事物用至極限時，這些技術都會以各自不同的方式發生故障。

• 如果你的架構應對增長所帶來的問題時，只需要簡單的投入更多的主機，那么你的架構含金量十足。

• 集群管理算法本身就用于處理SPOF，如果存在漏洞的話可能就會影響到每個節點。

• 為了快速的增長，你需要為每次負載增加的數據進行均勻分配。

• 在節點間傳輸的數據越少，你的架構越穩定。這也是他們棄集群而選擇分片的原因

• 一個面向服務的架構規則。拆分功能，可以幫助減少連接、組織團隊、組織支持以及提升安全性。

• 搞明白自己究竟需要什么。為了匹配愿景，不要怕丟棄某些技術，甚至是整個系統的重構。

• 不要害怕丟失一點數據。將用戶數據放入內存，定期的進行持久化。失去的只是幾個小時的數據，但是換來的卻是更簡單、更強健的系統！

英文原文：http://blog.jobbole.com/38554/

譯文連接：http://www.oschina.net/translate/scaling-pinterest-from-0-to-10s-of-billions-of-page-views