問題：
　　我在一家托管公司工作，我們總是為客戶推薦解決方案。最痛苦的事情就是內(nèi)容的上傳，這些內(nèi)容或者得放在集中的地方，或者需要一個管理節(jié)點將所有新文件推送到伺服器上。
　　我一般采用的解決方案就是下面這樣：
　　負載均衡器1x 裝有l(wèi)syncd，inotify和rsync的主服務(wù)器（Apache， mod_php），并通過這些應(yīng)用將增刪/修改的文件發(fā)送到從屬服務(wù)器上。1x 從屬服務(wù)器（Apache， mod_php），搭載有Apache proxypass，負責將POST請求發(fā)送給主服務(wù)器，以確保新上傳的文件是通過主服務(wù)器添加的，然后再分別同步到從屬服務(wù)器上。我們公司使用Percona和Redis服務(wù)器，分別負責提供數(shù)據(jù)庫與緩存服務(wù)。
　　我的問題是：
　　Wordpress的最佳方案怎么設(shè)計？你們用什么工具進行會話？Redis/Memcached怎樣在多臺服務(wù)器上執(zhí)行文件復(fù)制？性能方面有什么問題嗎？你們用的哪種數(shù)據(jù)庫，為什么？
　　回復(fù)1：Zm3tta：
　　我們托管了大約2000個WordPress實例，目前正在進行架構(gòu)升級，以獲得可擴展性與安全性的提升。應(yīng)用服務(wù)器的CPU利用率是主要的瓶頸，我們希望能在需要時，快速在資源池中部署新的應(yīng)用服務(wù)器。
　　我們使用Nginx Web服務(wù)器來處理靜態(tài)內(nèi)容請求、所有vhost路由、Redis緩存以及php請求的負載均衡。通過Nginx的iphash設(shè)置定向到多臺應(yīng)用服務(wù)器上，從而可以為Redis緩存設(shè)置最小規(guī)則，并以相對透明的方式來處理會話。
　　針對文件復(fù)制的問題：利用NFS4將各網(wǎng)站的doc-root安裝到應(yīng)用服務(wù)器上，這樣無論哪個節(jié)點的內(nèi)容有修改，都能立即發(fā)現(xiàn)。我們使用PHP-FPM數(shù)據(jù)池監(jiān)聽多臺應(yīng)用服務(wù)器，從而使得擴展應(yīng)用服務(wù)器層非常簡單與快速，可以按需求向多臺或幾臺服務(wù)器執(zhí)行資源請求的分發(fā)。并在最后設(shè)有獨立的數(shù)據(jù)庫服務(wù)器，針對未能緩存的內(nèi)容請求作出回應(yīng)。
　　雖然彼此的架構(gòu)差別很大，不過至少可以做些了解。
　　提問者回復(fù)：
　　問題在于……NFS仍是一個單點故障，如果不用GlusterFS之類的東西，怎么解決這個問題？
　　回復(fù)2：csmicfool
　　我們有個大型的WPMU網(wǎng)絡(luò)（3000多個網(wǎng)站），使用NFS掛載上傳目錄，無需擔心用rsync同步的問題，也無需設(shè)定“管理”或主/從服務(wù)器，所有虛擬器地位相同，從而使得按需擴展更合理。這種方式比我們原本的預(yù)期更為有效。
　　在NFS服務(wù)器上，我們使用rsync將上傳的內(nèi)容增量復(fù)制到另一個（用s3fs）裝有S3 bucket的文件夾中，因此存有離線留存和冗余副本。切記：不要在web服務(wù)器上使用s3fs來處理目錄。
　　想要節(jié)省開支，可以在管理頁面強制使用SSL，并且只開啟節(jié)點上的SSL，然后通過rsync或類似的方式來執(zhí)行從管理到其他網(wǎng)頁的分發(fā)。
　　提問者回復(fù)：
　　我們有很多客戶想要尋求更廉價的解決方案，因此我認為強制使用SSL的方案非常棒！
　　回復(fù)3：springer70
　　這里分享一則Joomla網(wǎng)站托管實例，事實上在wordpress上，原理是相同的。
　　我們使用Elastic Beanstalk托管到亞馬遜上，根據(jù)需求和流量執(zhí)行向上/向下的擴展都很簡單。一開始網(wǎng)站流量很低，公司進行大規(guī)模宣傳之后，流量猛增。因此使用彈性架構(gòu)就非常有用。
　　我們有一個負載均衡器，將流量引導(dǎo)到可用的前端服務(wù)器池中。在這些服務(wù)器上設(shè)有應(yīng)用作為zip文件的容器，在需要新服務(wù)器時，只要執(zhí)行部署，zip文件就會解壓并部署到新服務(wù)器上。這就代表著（你提到的）文件上傳很棘手。我們使用獨立的云存儲來管理媒體和上傳（亞馬遜s3），并使用插件將用戶的上傳內(nèi)容導(dǎo)入s3存儲中，而不是存在本地文件系統(tǒng)中。（有趣的是：媒體的這種通用存儲對于開發(fā)/staging/qa/生產(chǎn)環(huán)境來說尤其有用，因為它們?nèi)际褂猛粋€存儲文件系統(tǒng)）。
　　我們還有個中央單一數(shù)據(jù)庫，不保留實時冗余副本；一份故障轉(zhuǎn)移備份，最多5分鐘就能恢復(fù)生產(chǎn)環(huán)境。
　　這個解決方案不算便宜，我們有：
　　S3存儲的成本；EC2前端服務(wù)器（每次至少2臺，保留冗余副本）；2臺數(shù)據(jù)庫服務(wù)器；負載均衡器；開發(fā)與staging服務(wù)器，staging復(fù)制了生產(chǎn)環(huán)境；
　　我們在數(shù)據(jù)庫中管理會話，因此如有用戶從一個前端服務(wù)器換到另一個，會話就會被保留。還有備選方案，就是使用“粘滯會話（sticky sessions）”——強制用戶一直停留在同一臺前端服務(wù)器上。
　　我們的復(fù)制計劃非常簡單，因為沒有真正復(fù)制任何東西。前端服務(wù)器將zip文件保存在應(yīng)用中，因此也不包含“真正的”數(shù)據(jù)。所有數(shù)據(jù)都在S3或數(shù)據(jù)庫中。
　　結(jié)果性能很不錯，我們的前端服務(wù)器速度很快，由于存在一些前端緩存，數(shù)據(jù)庫（mysql）很少使用（相對而言）。我們使用的所有服務(wù)器都“很小”或“超級小”，因此無需性能特別強大。抱歉寫了一大堆東西。
　　回復(fù)4：applextrent
　　我們在WPdocker.com是使用SaaS平臺和云服務(wù)器管理器作為通用的容器管理方案。使用補丁管理來解決更新的問題。關(guān)于容器可以查看這里獲取更多詳情。
?