# StackExchange 體系結構更新-平穩運行，Amazon 4x 更昂貴 > 原文： [http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html)  我們已經發表了幾篇關于 [StackOverlflow Architecture](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) 和 [Stack Overflow Architecture Update 的文章-每月瀏覽量為 9500 萬頁](http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html)。 是時候進行另一次更新了。 這次來自播客。 杰夫，喬爾（Jeff，Joel）和客人每星期大約坐在一起交談。 結果是[播客](http://blog.stackoverflow.com/category/podcasts/)。 在最近的[播客](http://blog.stackoverflow.com/2011/09/se-podcast-17/)中，他們討論了他們最近的一些體系結構問題，問題和更新。 自從我在休假前寫這篇文章以來，他們還發布了新的體系結構更新文章： [The Stack Exchange Architecture – 2011 Edition，Episode 1](http://blog.serverfault.com/post/the-stack-exchange-architecture-2011-edition-episode-1/) 。 我的總體印象是他們在一個舒適的地方，添加了新的網站，添加了新的功能，使房屋成為了家。 以他們的向上擴展架構而聞名，您可能會期望隨著他們的成長，他們會撞墻。 不是這樣 他們已經能夠通過增加更多的 CPU 和 RAM 來擴展單個服務器的功能。 在某些情況下已添加 SSD。 甚至他們的旗艦產品 StackOverflow 產品都在單個服務器上運行。 已經購買了新機器，但數量很少。 因此，StackOverflow 實驗表明，即使是規模較大的站點，也都應按比例放大策略。 沒錯，就像早期的 Facebook 一樣，他們的產品自然按照主題分開，但是摩爾定律和質量工程是您的朋友。 他們估計亞馬遜將花費他們四倍的錢。 這是 StackExchange 所做的： * 他們在俄勒岡州有一個機架，在紐約的 Peer1 有兩個籠子。 * 檢查電源并不會全部故障轉移到單個電源，如果實際發生故障，該電源將發生故障 * 新建了 10 臺服務器 約克。 9 個生產服務器。 1 個質量檢查服務器。 * 堆棧溢出具有大型服務器，SSD 和更多 RAM。 他們在某些計算機上添加了更多的處理器和更多的 RAM，以便可以運行 Lucene * Oregon 運行數據瀏覽器并進行聊天。 如果您無法到達紐約，您仍然可以聊天。 堆棧交換博客在俄勒岡運行，所有其他博客在紐約。 * 機架非常狹窄，尤其是具有大量用于冗余電源和網絡連接的電纜。 * 應該在 Peer1 處購買機架而不是籠子。 那會給更多的空間。 * 紐約的存在使他們更接近歐洲用戶。 * 保留俄勒岡州的位置，因為它很便宜，而且擁有另一個位置很方便。 * 考慮具有故障轉移模式，以便所有 NY 通信量都可以只讀模式故障轉移到俄勒岡州。 您不能提出新的問題，但是由于該站點的大部分價值都來自于閱讀，因此只讀站點具有價值。 * 他們具有以下只讀模式： * 當他們將 Stack Overflow 移至其自己的數據庫服務器時。 * 當他們從俄勒岡州移居到紐約時。 * 具有兩個站點都可以處理寫入的雙活體系結構太復雜了。 * 您不知道與主服務器的連接將關閉多長時間。 找出錯誤原因可能需要很長時間。 因此，在備份服務器上進入只讀模式是正確的事情。 如果您在備用服務器上進入讀寫模式，那么您將更不愿意返回主服務器，直到您確定它完全死了。 * 他們在代碼中寫入數據庫的每個地方都實現了只讀模式。 * 運行狀況儀表板提供了所有系統的總體狀態。 從 SQL 數據庫查詢。 將所有內容存儲在 SQL 中，使構建工具變得更加容易，并且可以針對當前的流量負載進行適當擴展。 * 三個圖形：CPU，內存，網絡。 * 運行大部分網絡的 10 臺服務器幾乎未加載。 一種是峰值 16％。 即使翻了一番，他們也被嚴重超支。 * 它們一次沒有被過度配置。 * 服務器已經重新配置了很多。 * 他們已將 CPU 添加到 Web 層。 他們達到了 60％的峰值，這令人不舒服。 * 在 Web 層中添加了 SSD，因此它們可以： * 提高 Lucene 索引速度。 * 加快啟動 Web 層時的啟動時間。 * 固態硬盤在生命周期中處于起步階段，要輕而易舉。 * SSD 不應使您的計算機運行得更快，因為您應該已經在 RAM 中運行了。 當數據庫太大而無法放入 RAM 時，則不適用。 希望您最活躍的數據可以放入 RAM。 * 使用商業 Orion 網絡監視器。 從本質上講，它是在為時間付費，因為它比 Nagios 更容易設置和使用。 * 將所有數據保留在 SQL Server 上。 * SQL 意味著很容易訪問和查詢。 * Web 日志也存儲在 SQL Server 中。 * 在 SQL Server 中擁有所有數據的長期趨勢。 * 買了一臺重型服務器，只是為了保存所有這些數據并能夠執行實時查詢。 2 個處理器，大量 RAM。 放入 13TB 的存儲空間，這是一年的日志文件。 每天有 20 個演出進入 SQL Server。 * 之所以提供幫助，是因為他們可以實時告知正在發生的事情。 當他們推出一項新功能時，他們可以知道使用了多少功能，從而告訴他們是否需要保留該功能。 他們可以通過簡單的查詢來完成此任務，而無需查看日志或訪問 Google Analytics（分析）。 * 他們每天創建 1 張表格來存儲統計信息。 * 他們都知道 SQL，因此可以相對輕松地提出要回答的問題。 * Redis 服務器 * 用作 10 個服務器之間的共享狀態緩存。 可以跨服務器平衡請求。 他們不想每次都訪問數據庫，因此它將進入緩存。 * 仍然是網絡熱議。 他們將處理粘性 IP，以便請求可以使用 Web 服務器上的內存中緩存。 這樣可以消除網絡命中的速度，該命中要快得多，可以直接在內存中使用它。 * 將所有內容都放入緩存時，會遇到網絡可伸縮性問題。 這不是一個無限快的管道。 * 網絡啟示錄 * [微爆](http://blog.serverfault.com/post/per-second-measurements-dont-cut-it/)出現問題。 在很短的時間內爆發高達千兆位的速度，這使隊列充滿了。 * 從未找到根本原因。 * 改變了網絡架構的方式。 所有網絡都集中路由。 Web 服務器和數據庫/ redis 服務器位于不同的網絡上，因此它們擺脫了兩側之間的路由器和防火墻。 * 他們更改了 NIC 配置。 他們聯手進行了故障轉移。 他們將配置更改為雙活模式，并通過 NIC 負載均衡請求。 他們希望不再使用單個網卡來防止微爆。 * 導致成本增加的原因是，如果它們從交換機運行了 10 條網絡線，因為您按端口付費。 * 令人驚訝的是，他們的流量混合了 40％的讀取和 60％的寫入。 * 他們的觀眾中有 60％是國際觀眾。 * StackExchange 大約有 45 個人。 * CDN 使您可以處理在多個區域中運行的國際用戶的 80％的方式。 * 擁有 CDN 服務器的大部分靜態資源。 * 兩個數據中心中的實時數據太難了。 需要足夠的 DBA 24x7 覆蓋，并在支持方面進行了大量代碼更改。 * 進入兩個數據中心可能需要一個客戶端引擎，例如 Facebook。 * 客戶與 10 臺服務器進行對話，并說您有什么需要幫助的。 * 客戶端合并數據并顯示一些結果。 * HTML 頁面是幾個 div。 每個 div 獨立出去都會獲取頁面的該部分。 頁面的每個部分可能來自不同的服務器，并且全部集中在客戶端。 * StackExchange 并不是高度定制的，用戶可以看到大致相同的站點，因此這并不是一個大贏家。 * 遷移到亞馬遜并不是一個好主意： * 無法相信亞馬遜的故障。 * 亞馬遜的[價格將比](http://meta.stackoverflow.com/questions/73969/what-would-stack-exchanges-yearly-expenses-be-if-it-were-to-be-using-a-third-par/73978#73978)高出 3 倍以上。 亞馬遜最初購買硬件后，每月需要花費 17,000 美元，而現在每月需要支付 4,000 美元。 * 亞馬遜擁有 2007 年的舊技術，因此要實現類似的性能，他們將需要比現在更多的服務器。 * 期望從每臺計算機獲得 5 年的服務。 較舊的計算機將投入使用或承擔較少的任務。 * 如果去了亞馬遜，他們是否需要另一個系統管理員？ 他們可能沒有想到。 亞馬遜存在許多無法追蹤的隨機網絡延遲問題。 對于高容量服裝，并非全都是玫瑰。 * 對于控制怪胎，這不是最好的模型。 他們想知道網絡中正在發生的一切。 他們不斷觀察性能，調整 NIC 配置等。無法控制所有內容并不適合他們的工作方式。 * 想要最好的硬件并關心每個小細節。 當您去亞馬遜時，您說的是我不在乎。 * 云是一個冗余的故事。 這就像買一千個漢堡包，而不關心 5 個腐爛的漢堡包。 那不是他們選擇的模型。 * 他們有一個重要的故事，尤其是在數據庫方面。 大鐵還沒死。 摩爾定律還沒有死。 您實際上不必花費太多時間來獲得功能更強大的服務器。 不斷前進。 * 他們真正擔心的唯一事情是，如果數據庫中的 RAM 用完了。 他們按主題有單獨的數據庫，但是 Stack Overflow 太大了，它裝滿了一臺機器，無法分片。 他們可以獲得一臺具有 256GB RAM 的服務器。 StackExchange 令人耳目一新。 他們有意識地嘗試通過在[他們的博客](http://blog.serverfault.com/)中發布??或在其[網站](http://serverfault.com/)之一上提問來公開問題。 也許您的組織可能想效仿他們的榜樣？ 這是一種建立意識和信任的好方法。 感謝您的出色總結-非常有趣。 AWS 上的成本計算不是最新的或完全正確的。 我已經對原始的 SO 問題發布了更新的細分：http://meta.stackoverflow.com/questions/73969/what-would-stack-exchanges-yearly-expenses-be-if-it-were-to-be- 使用三分之一 pa / 110201＃110201 因此，一旦 SO 工作集通過 256GB 而又不分割所有內容，則進一步擴展工作是一個有趣的思想實驗。 也許您要分解數據庫，但要按功能而不是按哈希-這里是全文索引，這里是詳細的表決/用戶/統計數據，此處顯示問題頁面所需的計數和文本。 或者，如果有很多鮮為人知的檔案數據，則可能在其他地方。 或者，也許您發現站點的一個或兩個方面比分片*一切*（投票，統計？）更容易分片，并且減輕了關系母權帶來的大量負載/ RAM 壓力。 Randall，我同意，當數據集太大時，分離數據（而不是分片）是一種更好/更容易的啟動方法。 Netflix 不久前就這樣做了，這就是為什么他們的網站會因服務故障而正常降級的原因。 例如，“評論”可能不會顯示在電影頁面上，但是您仍然可以流式傳輸。 看到此博客上的“無法相信亞馬遜的故障”，真是令人震驚。 首先，您是否真的要宣稱可以比 AWS 建立更多的冗余和更多的容錯能力？ 您了解如何在所有 AWS 數據中心之間進行分配嗎？ 其次，該聲明是不真實的，事實是您不能 100％信任任何系統。 你建立寬容。 您是否聲稱無法在 AWS 上建立容忍度？ 讓我們進行討論。 這是另一個更新： http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/