# 每月將 Reddit 打造為 2.7 億頁面瀏覽量時汲取的 7 個教訓 > 原文： [http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building-reddit-to-270-million-page.html](http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building-reddit-to-270-million-page.html)  [社交新聞網站](http://en.wikipedia.org/wiki/Steve_Huffman) [Reddit](http://www.reddit.com/) 的共同創始人史蒂夫·霍夫曼做了出色的[演示文稿](http://vimeo.com/10506751)。（[幻燈片](http://www.slideshare.net/carsonified/steve-huffman-lessons-learned-while-at-redditcom)和[文字](http://carsonified.com/blog/dev/steve-huffman-on-lessons-learned-at-reddit/) ），學習他在將 Reddit 建立和發展到每月有 750 萬用戶，每月有 2.7 億頁面瀏覽以及 20 多個數據庫服務器的過程中吸取的教訓。 史蒂夫（Steve）說，很多課程確實很明顯，因此您可能在演示文稿中找不到很多全新的想法。 但是史蒂夫對他有一種真誠和真誠，這顯然是建立在經驗基礎上的，以至于您不禁要深思一下自己可能會做些什么。 如果史蒂夫不了解這些課程，我敢打賭其他人也不會。 有七個課程，每個課程都有自己的摘要部分：第一課：經常崩潰； 第二課：服務分離； 第 3 課：開放式架構； 第四課：保持無狀態； 第 5 課：內存緩存； 第 6 課：存儲冗余數據； 第 7 課：脫機工作。 到目前為止，其體系結構最令人驚訝的功能是在第六課中，其基本思想是：速度的關鍵是預先計算所有內容并將其緩存。 他們將預計算[旋鈕最多旋轉 11](http://en.wikipedia.org/wiki/Up_to_eleven) 。 聽起來您在 Reddit 上看到的幾乎所有內容都已被預先計算和緩存，無論它們需要創建多少版本。 例如，當有人提交鏈接時，他們會預先計算所有 15 種不同的排序順序（熱門，新，熱門，舊，本周等）以用于列表。 通常，開發人員會害怕走極端，浪費時間。 但是他們認為浪費前期總比拖延慢。 **浪費磁盤和內存比讓用戶等待**更好。 因此，如果您一直堅持下去，請轉到 11，這是一個很好的先例。 ## 第一課：經常崩潰 本課的實質是：**自動重新啟動失敗的癌性服務**。 在 colo 中運行自己的系統的不利之處在于您需要進行維護。 服務中斷后，您必須立即修復，即使在凌晨 2 點。 這是您生活中持續不斷的緊張感。 您必須隨身攜帶一臺計算機，并且您知道，任何時候只要有人打來電話，那都是您必須解決的另一場災難。 它毀了你的生活。 緩解此問題的一種方法是重新啟動過程，該過程已經死亡或變得癌變。 Reddit 使用[監督](http://cr.yp.to/daemontools/supervise.html)自動重啟應用程序。 特殊的監視程序會殺死使用過多內存，使用過多 CPU 或無響應的進程。 不必擔心，只需重新啟動即可啟動系統。 當然，您必須閱讀日志并找到根本原因，但是在那之前，它會使您保持理智。 ## 第 2 課：服務分離 本課的實質是：**將過程和數據分組在不同的盒子**上。 在一個盒子上做太多的工作會導致**在作業**之間進行大量上下文切換。 嘗試使每個數據庫服務器以相同的方式服務于相同類型的數據庫。 這意味著您的所有索引都將被緩存，并且不會被調入和調出。 保持所有內容盡可能相似。 不要使用 Python 線程。 他們很慢。 他們將所有內容放在單獨的多個流程中。 垃圾郵件，縮略圖等服務可查詢緩存。 它使您可以輕松地將它們放在不同的計算機上。 您已經解決了流程之間通信的問題。 一旦解決，它就可以保持體系結構整潔，并且易于擴展。 ## 第 3 課：開放式架構 本課程的本質是：**不必擔心模式**。 他們過去經常花費大量時間來擔心數據庫，以保持一切正常和正常。 **您不必擔心數據庫**。 當您變大時，架構更新將非常緩慢。 將一列添加到一千萬行需要鎖定，因此不起作用。 他們使用復制進行備份和擴展。 模式更新和維護復制是一件痛苦的事情。 他們將不得不重新啟動復制，并且可能一天沒有備份。 部署是一件痛苦的事情，因為您必須協調新軟件和新數據庫的升級方式。 相反，他們保留了事物表和數據表。 Reddit 中的所有內容都是事物：用戶，鏈接，評論，subreddit，獎項等。事物具有共同的屬性，例如上下投票，類型和創建日期。 數據表具有三列：事物 ID，鍵，值。 每個屬性都有一行。 標題，URL，作者，垃圾郵件票等都有一行。當他們添加新功能時，他們不必再擔心數據庫了。 他們不必為新事物添加新表，也不必擔心升級。 更易于開發，部署，維護。 代價是您不能使用很棒的關系功能。 數據庫中沒有聯接，您必須手動執行一致性。 沒有聯接意味著將數據分發到不同的機器真的很容易。 您不必擔心外鍵正在執行聯接或如何拆分數據。 工作得很好。 使用關系數據庫的煩惱已經成為過去。 ## 第 4 課：保持無狀態 目標是讓每個應用服務器處理每種類型的請求。 隨著他們的成長，他們擁有更多的計算機，因此他們不再依賴于應用內服務器緩存。 他們最初將狀態復制到每個應用程序服務器，這浪費了內存。 他們無法使用內存緩存，因為它們保留了大量的細粒度文件，這太慢了。 他們重寫使用內存緩存，并且不將任何狀態存儲在應用服務器中。 如果應用服務器發生故障，則很容易。 為了擴展，您可以添加更多應用服務器。 ## 第 5 課：內存緩存 本課的實質是：**內存緩存所有內容**。 它們將所有內容存儲在內存緩存中：1.數據庫數據 2.會話數據 3.呈現的頁面 4.記憶（記住以前計算的結果）內部功能 5.限制用戶操作，爬網程序的速率 6.存儲預先計算的列表/頁面 7.全局 鎖定。 他們現在在 Memcachedb 中存儲的數據比 Postgres 多。 就像記憶快取一樣，但是會儲存在磁碟上。 非常快。 所有查詢均由同一控件生成，并緩存在 memcached 中。 更改密碼鏈接和關聯狀態被緩存 20 分鐘左右。 驗證碼也一樣。 用于他們不想永久存儲的鏈接。 他們在其框架中內置了備忘錄。 計算結果也將被緩存：標準化頁面，列表，所有內容。 使用 memcache +到期日期對所有內容進行速率限制。 保護您的系統免受攻擊的好方法。 沒有速率限制子系統，單個惡意用戶可能會破壞系統。 不好。 因此，對于用戶和爬網程序，他們將很多內容保留在內存緩存中。 如果用戶在一秒鐘內再次出現，他們將被彈跳。 普通用戶的點擊速度不太快，因此他們希望引起注意。 Google 搜尋器會以您希望的速度打擊您，因此，當速度變慢時，只需提高限速器的速度，即可使系統安靜下來而不會傷害用戶。 Reddit 上的所有內容都是清單：首頁，方框中的評論頁。 所有這些都預先計算并轉儲到緩存中。 當您獲得列表時，它將從緩存中獲取。 每個鏈接和每個注釋可能都存儲在 100 個不同的版本中。 例如，具有 30 秒鐘舊 2 票的鏈接是單獨呈現和緩存的。 播放 30 秒后會再次呈現。 等等。 HTML 的每個小片段都來自緩存，因此不會浪費 CPU 渲染時間。 當事情變慢時，只需添加更多緩存即可。 當弄亂他們脆弱的不一致數據庫時，他們使用內存緩存作為全局鎖。 為他們工作甚至認為這不是最好的方法。 ## 第 6 課：存儲冗余數據 本課程的實質是：**速度的關鍵是預先計算所有內容并將其緩存**。 建立慢速網站的方法是擁有一個完全標準化的數據庫，按需收集所有內容，然后進行渲染。 它永遠需要每個單獨的請求。 因此，如果您有可能以幾種不同格式顯示的數據（例如首頁，收件箱或個人資料中的鏈接），請分別存儲所有這些表示形式。 因此，當有人來獲取數據時，該數據已經存在。 每個列表都有 15 個不同的排序順序（本周熱門，新，熱門，舊）。 當某人提交鏈接時，他們會重新計算該鏈接可能影響的所有可能的列表。 前期可能有點浪費，但前期浪費比緩慢要好。 浪費磁盤和內存比讓用戶等待更好。 ## 第 7 課：脫機工作 本課程的本質是：**在后端上進行最少的工作，并告訴用戶您已完成**。 如果您需要做某事，請在用戶不在等您時進行。 放入隊列中。 當用戶對可更新列表的 Reddit 進行投票時，該用戶的 Karma 以及許多其他內容。 因此，一經表決，數據庫便會更新以知道發生了表決，然后將作業放入隊列中，該作業知道需要更新的 20 件事。 當用戶回來時，一切都已經為他們預緩存了。 他們離線進行工作：1.預計算清單 2.提取縮略圖 3.檢測作弊。 4.刪除垃圾郵件 5.計算獎勵 6.更新搜索索引。 用戶正在等待您時，無需執行**這些操作。 例如，隨著 Reddit 變得越來越大，現在作弊的動機越來越高，因此當人們投票檢測作弊時，他們在后端花費了大量時間。 但是它們確實是在后臺運行的，因此不會降低用戶體驗。 演示文稿中的體系結構圖為：** 藍色箭頭表示當請求進入時發生的情況。假設某人提交了鏈接或投票，它將轉到高速緩存，主數據庫和作業隊列。 然后他們返回給用戶。 然后其余的事件會離線發生，這些由粉紅色箭頭表示。 諸如 Spam，Precomputer 和 Thumnailer 之類的服務從隊列中讀取，進行工作并根據需要更新數據庫。 關鍵技術是 RabbitMQ。 ## 相關文章 * [關于可擴展性的隊列相關文章](http://highscalability.com/blog/category/queue) * [](http://highscalability.com/blog/category/queue)**[Reddit 于 2010 年 5 月發布的“服務器狀態”報告](http://blog.reddit.com/2010/05/reddits-may-2010-state-of-servers.html)** 對我而言，最有趣的部分是數據庫中糟糕的 EAV 解決方案。 不帶模式和模式驗證的所有內容都作為字符串。 這通常會導致維護和效率方面的一些可怕問題，但這一次它可以正常工作。 可能是因為該模型非常簡單，在其他許多情況下卻無法正常工作 很棒的文章！ 絕對提供了一些非常新的性能思考方式。 “但是它們確實是在后臺運行的，因此不會降低用戶體驗” “但是他們活著” “現場直播” 好文章！ 很好讀 對于那些喜歡數學的人來說，每月 2.7 億的頁面瀏覽量就是每秒 100 個頁面瀏覽量。 絕對不會出現需要 20 臺數據庫服務器的情況。 請謹慎選擇您的建議。 互聯網上很少有網站像 Reddit 一樣頻繁出現故障或性能不佳。 我總覺得這些家伙在后臺做些聰明的事。 感謝您告訴我更多有關我最喜歡的社交書簽網站的信息！ 哦，我只是喜歡這種性能知識。 我們在設計架構以及隨后像 Reddit 一樣更新它們時也遇到了很多麻煩。 但是我必須同意 Simon 的觀點，Reddit 的解決方案在許多其他情況下都行不通。 我同意 Haugeland 先生的觀點，即必須擁有 20 臺數據庫服務器來處理負載似乎太過分了。 通過閱讀評論，我看來原始作者未能認識到真正的教訓。 這樣的設計通常是開發團隊不了解如何為底層數據庫進行設計和編碼的結果。 也許根據預期的使用情況和負載來選擇錯誤的基礎數據庫。 這個已經過期了。 reddit 遷移到 Cassandra。 http://www.reddit.com/r/programming/comments/bcqhi/reddits_now_running_on_cassandra/ 記憶快取不見了 哇！ 這是一項很好的工作！ 換句話說，運行可伸縮網站不該做什么。 我鍵入此內容時，Reddit 尚未再次打開。 我是 Reddit 的粉絲，我希望它會改變其基礎設施以提供更多可用性。 MySQL（尤其是 MyISAM）給 RDBMSes 起了一個不好的名字。 我有一個以 Poststars 為后盾的應用程序，該應用程序以“星型模式”組織，有一個主事件表，我們平均每秒對其進行 200 次 INSERT 插入，例如高峰時為 400 ish，有 24 列，其中大多數是外鍵 動態增長的查詢表，我們在同一秒內結合在一起執行了十二打 INSERT / SELECT。 這些查詢表之一具有超過 2.13 億行。 向該表中添加另一列是即時的，并為應用程序帶來了零延遲。 這是因為 Postgres 將列視為元數據。 在 MySQL 中嘗試這樣做確實會“自殺”，而且絕對不是一種選擇，因為 MySQL 需要重建整個表。 我不確定你們使用的是哪個版本的 Postgres，但是我發現鎖定聲明令人驚訝。 如果您熱衷于使用 MySQL，那么請盡一切可能不使用 MyISAM 的方法，嘗試將所有基于文本的索引和搜索推遲到 Sphinx 之類。 并盡可能保留盡可能多的表。 實際上，“對所有內容進行預先計算”實際上是擴展應用程序的第一條規則。 他們只是把它帶到了大多數人無法接受的地方。 很棒的帖子！ 我喜歡這種東西。 因此，您基本上將簡單的鍵值存儲入侵了 MySQL？ 為什么不使用 Cassandra，couchdb，東京暴君，redis？ 我想知道 Reddit 使用什么隊列解決方案，以及遷移到 Cassandra 后是否仍在使用它（我認為它仍然有用） 比較 Digg 和 Reddit 的加載時間，我想說 Digg 做得正確，而 Reddit 做錯了。 您是否真的復制了本文的編輯內容？ 它充滿了尷尬的寫作，就像您在演示過程中起草并發布時一樣，沒有進行編輯。 第 4 課幾乎是難以理解的。 達克，我同意第 4 課不是很好。 我要做的是總結發言者的發言，使其更簡短，更直接地適用。 有時我不知道該怎么做，所以我只保留原理圖版本。有幾條襯里我認為不值得在一個點上闡述，但我還是留了一點 如果您真的有興趣，可以決定觀看視頻。 哦，瞧，又一家沒有實際客戶的網絡創業公司，因此他們不必擔心數據完整性，而且顯然無力聘請知道數據庫工作原理的人來決定適當的 RDBMS 設計是否起作用 首先，他們的問題顯然不適合于關系模型。 現在他們有 40 臺服務器從事 2 臺服務器的工作，應該給我們留下深刻的印象嗎？ 伙計們，雇用 DBA 比重塑持久性存儲便宜得多。 開放模式部分使它看起來像是 NoSql 的理想候選者... chris h：只有確實要添加列時，Postgres 中的 no-locking 選項才可用。 如果要更改列的數據類型，或將列移到其他表，會發生什么？ ChronicDB 聲稱將實時模式更改應用于 Postgres。 @WayneB-digg 也不正確。 他們有 200 臺服務器，現在處理的流量少于 reddit。 @John Haugeland：我完全同意你的看法。 這是一篇有關開發團隊如何找到經驗不足的解決方法的文章。 這是一篇很有幫助的文章。 感謝您分享所有這些很棒的技巧。 希望他們能對您有所幫助！ Reddit 太慢了……我想他們有一些新的挑戰和教訓要學習，因為在大多數情況下它似乎無法使用。