我想要擴展基於LAMP的電子商務門戶。最近我們看到了巨大的交通浪涌。如何提升電子商務門戶的可擴展性？
會有什麼措施（請註明按順序）在擴大它：
我應該考慮移動到Amazon EC2的或類似的？切換服務器可能會出現什麼問題？
我們是否需要重新設計數據庫？我讀過，Facebook從MySql切換到Cassandra。如果切換到Cassandra，需要更改哪些代碼？ Cassandra會比MySql更好嗎？
可能性Hadoop，甚至不確定？
任何其他的事情，需要考慮？
找到這個post有幫助。這blog也有不錯的文章。我想知道的是我在擴展這個應用時應該考慮的步驟清單。
首先，我會建議確保服務器提供的每個資源都設置適當的緩存控制標頭。我們的目標是確保真正動態的內容每次都得到全新的服務，並且儘可能從其他人的緩存中獲取任何穩定或靜態的內容。爲什麼要向每個AOL客戶提供產品圖像，然後才能將其交付給第一個客戶，並讓AOL將其交付給所有其他客戶？
如果您當前在同一個框上運行Web服務器和dbms，則可以查看將dbms移動到專用數據庫服務器上。
完成上述操作後，您需要開始測量細節。什麼資源會首先達到其容量？
例如，如果Web服務器是在或接近容量，而數據庫服務器大多位於怠速運轉，這是沒有意義的切換數據庫或實現複製等
如果Web服務器坐在而DBMS大多閒置不斷查看切換到負載平衡Web服務器集羣是沒有意義的。
首先照顧簡單的事情。
如果dbms可能是瓶頸，請確保您的數據庫具有正確的索引，以便在查找期間獲得快速訪問時間，並且不會浪費更新過程中不必要的時間。確保dbms從表本身登錄到不同的物理介質。確保應用程序不會發出任何浪費的查詢等。確保您不會對您的交易數據庫運行任何昂貴的分析查詢。
如果網絡服務器可能是瓶頸，那麼可以查看它在哪裏花費大部分時間，並通過更改應用程序或實施新的緩存策略等方式來減少工作量。確保您沒有做任何事情可以防止你從一臺服務器轉移到多臺具有負載平衡器的服務器。
如果您已經注意到了上述情況，那麼您將更好地準備遷移到多個Web服務器或數據庫服務器。您將更好地瞭解決定是使用複製來縮放數據庫還是切換到完全不同的數據模型等。
非常好，*專業*回答bbadour！ – GrandmasterB 2010-09-01 18:39:17
您能否解釋一下 - 「確保您沒有做任何事情阻止您使用負載均衡器從單個服務器移動到多個服務器」？ – understack 2010-09-05 05:06:56
@understack：一般來說，檢查你的應用程序是否是有狀態的，以及如果你持有狀態信息的話。 – bbadour 2010-09-06 02:29:23
找出問題發生在哪裏（或者如果你現在沒有他們，可能會發生）。在評估任何解決方案時，瞭解您最大的資源使用情況非常重要。堅持讓您獲得最大改善的解決方案。
考慮： - 高於所需的帶寬使用x用戶是您想要解決的問題，無論遷移到ec2。它會花費你的錢，無論哪種方式，所以它值得一試這樣的事情：http://developer.yahoo.com/yslow/ - 不要投資於更改數據庫，如果這不是問題。如果這真的是問題，那麼先查找一下，即使你遇到了數據庫問題，它也可能是一個代碼問題，即每次請求會觸發數據庫很多次。 - 除非我們談論v。大數字，否則不應該有很高的CPU使用率問題，如果您確實知道它們在哪裏發生/優化是值得的，那麼特定的代碼會對整體資源使用率產生重大影響。 - 確認上述內容合理後，您可能會在緩存方面取得重大進展。帶寬（確保瀏覽器/代理可以在緩存中發揮作用），本地資源使用（避免重新處理/重新檢索同一信息）。
我並不是說你應該全力以赴，只是爲了確保你在幾個月的其他地方不會得到同樣的問題。也足以找出你最大的收益在哪裏，如果你能從任何縮放選項中獲得足夠的價值。這也可以讓你回來並提出有關具體問題的問題，以及這些縮放選項與這些問題的關係。
你應該通過選擇一個靈活的框架來做好準備，並確保事情會一路走下去。在某些情況下，很難預測用戶的行爲。
如果您最近看到流量爆炸，請分析哪些是最慢的頁面。
您可以遷移到雲，但EC2並不是性能最好的一個。再次確定沒有其他優化可以做。
數據庫可能會重新設計，但我懷疑它的全部。再次看到問題點。
Hadoop和Cassandra都非常漂亮，但它們可能會矯枉過正。
1）首先 - 衡量每秒鐘多少次請求可以爲您訪問次數最多的頁面提供服務。對於平均硬件上編寫良好的PHP站點，它必須在每秒200-400個請求範圍內。如果你不在那裏 - 你必須通過減少數據庫請求數來優化代碼，使用PHP加速器緩存memcached/shared memory中很少更改的數據。如果您每秒鐘處理10-20個請求，則需要擺脫笨重的框架。
2）其次 - 如果您仍在Apache2上，則必須切換到lighthttpd或nginx + apache2。就我個人而言，我喜歡第二種選擇。
3）然後你將所有的靜態數據移動到單獨的服務器或CDN。確保它至少有24小時與「過期」標題一起提供。
4）只有在所有這些事情，你可能會開始考慮去EC2/Hadoop的，建立多個服務器和均衡負載（Nginx的也將幫助你在那裏）
後步驟1-3，你應該能夠每天輕鬆提供10'000'000點擊次數。
如果你只需要1.5-3倍，我會選擇單一更強大的服務器（8-16核心，大量RAM用於緩存&數據庫）。
隨着第4步和多臺服務器，您每天要花費0.1-1億次點擊（但對於明顯更大的硬件&支持費用）。
我認爲現在考慮Cassandra/Hadoop類型的東西還爲時過早，早期優化是所有惡意的根源，如果您的網站成爲流行的oneday，所有的東西都會隨之而來。 – tszming 2010-08-12 17:04:11
我建議你分享一些你所指的交通類型，包括峯值和正常情況。 – eglasius 2010-08-26 15:45:43
IIRC Hadoop用於離線數據處理，因此如果不進行一些細緻的工作，它可能不會被使用。 OTOH我知道有一個網站可以做這種工作。 – BCS 2010-09-01 13:46:25