# Sify.com 體系結構-每秒 3900 個請求的門戶 > 原文： [http://highscalability.com/blog/2010/5/10/sifycom-architecture-a-portal-at-3900-requests-per-second.html](http://highscalability.com/blog/2010/5/10/sifycom-architecture-a-portal-at-3900-requests-per-second.html)  Sify.com 是印度領先的門戶網站之一。 Samachar.com 由同一家公司擁有，是印度頂級的內容匯總網站之一，主要針對來自世界各地的非居民印度人。 Sify 的建筑師 Ramki Subramanian 非常慷慨地描述了這兩個站點的通用后端。 他們的架構最值得注意的方面之一是 Sify 不使用傳統數據庫。 他們查詢 Solr，然后從分布式文件系統中檢索記錄。 多年以來，許多人爭相使用數據庫之上的文件系統。 文件系統可以用于鍵值查找，但不適用于查詢，使用 Solr 是解決該問題的好方法。 他們系統的另一個有趣的方面是使用 Drools 進行智能緩存無效化。 隨著我們在多個專業服務中復制越來越多的數據，如何使它們[同步](http://www.youtube.com/results?search_query=in+sync)成為一個難題。 規則引擎是一種聰明的方法。 ## **平臺/工具** * 的 Linux * [淺色](http://www.lighttpd.net/) * PHP5 * 記憶快取 * 阿帕奇·索爾（Apache Solr） * Apache ActiveMQ /駱駝 * GFS（群集文件系統） * 德語 * 雷迪斯 * 帶有 ActiveMQ 的子。 * 漆 * 流口水 ## 統計資料 * 每月約有 1.5 億次網頁瀏覽。 * 服務 3900 請求/秒。 * 后端在托管約 30 個 VM 的 4 個刀片上運行。 ## 建筑 * 該系統已完全虛擬化。 我們還使用了大多數 VM 功能，例如當一個刀片發生故障或需要重新分配負載時，我們在刀片之間移動 VM。 我們已經對虛擬機進行了模板化，因此我們可以在不到 20 分鐘的時間內配置系統。 它目前是手動的，但是在系統的下一版本中，我們計劃自動化整個供應，調試，退役，在 VM 周圍移動以及自動縮放。 * 沒有數據庫 * 100％無狀態 * RESTful 接口支持：XML，JSON，JS，RSS / Atom * 寫入和讀取具有不同的路徑。 * 通過 ActiveMQ / Camel 將寫入排隊，轉換并路由到其他 HTTP 服務。 它用作 ESB（企業服務總線）。 * 像搜索一樣的讀取操作是由 Web 服務器直接從 PHP 處理的。 * Solr 用作索引/搜索引擎。 如果有人要求提供密鑰的文件，則會直接將其送出存儲空間。 如果有人說“給我所有在 author = Todd 處的文件，”它將打到 Solr，然后存儲。 使用 Apache Solr 作為我們的搜索引擎來執行查詢，并且我們有相同的分布式設置。 * 所有文件都存儲在群集文件系統（GFS）中。 查詢打到 Solr，它返回我們想要的數據。 如果我們需要完整的數據，則在從搜索中獲取 ID 后，我們將訪問存儲。 這種方法使系統完全可以水平擴展，并且對數據庫的依賴性為零。 升級到最新版本后，對我們來說效果很好。 我們僅運行 2 個節點進行存儲，如果需要，我們可以再添加幾個節點。 * 輕巧的前端 GFS。 Lighty 對于提供靜態文件確實非常好。 對于我們擁有的文件類型（主要是小的 XML 和圖像），每秒可以隨意接收 8000 多個請求。 * 所有最新的 NoSQL 數據庫（如 CouchDB，MongoDB，Cassandra 等）都將替代我們的存儲層。 在搜索功能上，它們都不接近 Solr / Lucene。 就查詢而言，MongoDB 是最好的，但是``包含''之類的搜索需要使用正則表達式來完成，這對 500 萬個文檔來說是一場災難！ 我們相信，目前，基于分布式文件系統的方法比許多用于存儲的 NoSQL 數據庫系統更具可伸縮性。 ## 未來 * 用于事件分析（用戶點擊，實時圖表和趨勢）的 CouchDB 或 Hadoop 或 Cassandra。 * 使用 Drools 的智能緩存失效。 數據將通過隊列推送，而 Drools 引擎將確定哪些 URL 需要無效。 它將在我們的緩存引擎或 Akamai 中清除它們。 方法是這樣的。 查詢（URL）到達我們的后端后，我們將記錄該查詢。 然后，記錄的查詢將被解析并推送到 Drools 系統中。 如果該輸入尚不存在，則系統會將其輸入并動態創建規則到系統中。 那是 A 部分。然后，我們的 Content Ingestion 系統將繼續將進入 Drools 隊列的所有內容推送。 數據輸入后，我們將針對內容觸發所有規則。 對于每個匹配的規則，生成 URL，然后我們將針對這些 URL 向緩存服務器（Akamai 或 Varnish）發出刪除請求。 多數民眾贊成在 B 部分。B 部分并不像上面提到的那么簡單。 會有很多不同的情況。 例如，我們在查詢中支持“ NOW”，大于，小于，NOT 等，這確實會讓我們頭疼。 * 我們這樣做的主要原因主要有兩個，高速緩存命中率極高，并且幾乎可以立即更新最終用戶。 請記住，過去從未經歷過的兩個原因！ * 我認為它將很好并且可以擴展。 Drools 確實擅長解決此類問題。 同樣在分析中，我們發現查詢在許多天內都是恒定的。 例如，我們每天有將近 40,000 個不同的查詢，并且每天都會以幾乎相同的模式重復。 對于該查詢，只有數據會更改。 因此，我們可以設置多個實例并僅在不同系統中復制規則，這樣我們也可以水平擴展它。 * 同步讀取，但是更少的層，更少的 PHP 干預和套接字連接。 * 使用 Queue / ESB（Mule）進行分布式（寫入不同的分片）和異步寫入。 * 使用 Varnish 或 Akamai 進行大量緩存。 * 殺死 gron 并保持更接近實時的守護進程。 * 使用 Gearman 進行并行和后臺處理，以及用于自動縮放處理的自動附加處理功能。 * 使用 Kaazing 或 eJabberd 向最終用戶和內部系統實時分發內容。 * Redis 用于緩存內容摘要以確定重復項。 * 我們正在尋求使整個事情更易于管理，并從 app-admin 內部打開 VM 和進程。 我們研究了 Apache Zookeeper，研究了 VMWare 和 Xen 提供的 RESTful API，并與我們的系統進行了集成。 這將使我們能夠進行自動縮放。 * 我們擁有的最大優勢是數據中心的帶寬不受限制，因為我們自己就是 ISP。 我正在研究在系統中利用該優勢的方法，并了解如何構建可以并行快速處理大量內容的集群。 ## 得到教訓 * ActiveMQ 多次被證明是災難性的！ 套接字處理非常差。 從重啟開始，我們通常會在不到 5 分鐘的時間內達到 TCP 套接字限制。 盡管它聲稱已在 5.0 和 5.2 中進行了修復，但對我們而言并不起作用。 我們以多種方式嘗試使它的壽命更長，至少一天。 我們通過部署帶有新版本的舊庫來解決問題，并使它的使用時間更長。 畢竟，我們部署了兩個 MQ（消息隊列），以確保至少對內容進行編輯更新可以正常進行。 * 后來我們發現問題不僅在于此，而且使用主題也是一個問題。 僅對四個訂閱者使用 Topic 會使 MQ 在數小時內掛起。 在大量脫發后，我們取消了整個基于主題的方法，并將它們全部排入隊列。 數據進入主隊列后，我們將數據推入四個不同的隊列。 問題已解決。 當然，在 15 天左右的時間內，它將拋出一些異常或 OOME（內存不足錯誤），并迫使我們重新啟動。 我們只是與它共存。 在下一個版本中，我們將使用 Mule 來處理所有這些問題，并且也將集群同時進行。 我們還試圖找到一種方法來按消息順序擺脫依賴關系，這將使分發變得更容易。 * 索爾 * 重新啟動。 我們必須非常頻繁地重新啟動它。 尚不十分清楚原因，但是因為它具有冗余性，所以我們比 MQ 更好。 通過執行查詢，我們已達到自動重啟的程度，如果沒有響應或超時，我們將重啟 Solr。 * 復雜查詢。 對于復雜的查詢，查詢響應時間確實很差。 我們有大約 500 萬個文檔，并且很多查詢的確在不到一秒鐘的時間內返回，但是當我們有一個帶有幾個“ NOT”以及許多字段和條件的查詢時，它需要 100 秒鐘以上的時間。 我們通過將查詢拆分為更簡單的查詢并將結果合并到 PHP 空間中來解決此問題。 * 即時的。 我們遇到的另一個嚴重問題是 Solr 不能實時反映所做的更改。 大約需要 4 分鐘到 10 分鐘！ 考慮到我們所處的行業和競爭，遲到的新聞 10 分鐘使我們變得無關緊要。 看過 Zoie-Solr 插件，但我們的 ID 是字母數字，而 Zoie 不支持。 我們正在尋找自己在 Zoie 中修復的問題。 * GFS 鎖定問題。 對于我們來說，這曾經是一個非常嚴重的問題。 GFS 將鎖定整個群集，這將使我們的存儲完全不可訪問。 GFS 4.0 出現問題，我們升級到 5.0，從那時起似乎還不錯。 * Lighty 和 PHP 不太融洽。 性能方面都不錯，但是 Apache / PHP 更穩定。 由于 PHP_FCGI 進程掛起，Lighty 有時會胡思亂想，CPU 使用率達到 100％。 我非常感謝 Ramki 花時間寫關于他們的系統如何工作的信息。 希望您能從他們的經驗中學到一些有用的東西，這些對您自己的冒險有幫助。 如果您想共享您的優秀系統的架構，請同時向其付費和向后付費，請 [與聯系我](../../contact/)，我們將開始。 相當有趣的信息！ 謝謝分享！ 每秒 3900 個請求非常棒。 目標響應時間是多少？ 拉姆基 Lighty 曾經有內存泄漏。 Nginx 或 Cherokee 可能值得一看。 將 MogileFS 視為 GFS 的替代品-GFS 更像是 POSIX 文件系統的替代品，但是 MogileFS 可能“足夠”，并且應該具有更大的可擴展性。 Solr －也許您需要分片搜索引擎，但這可能比它值得的工作更多。 ;-)使用 ActiveMQ，您是否考慮過將一些較輕的排隊需求轉移到 Redis？ 它具有可用于某些類型排隊的原子構造，并且幾乎可以肯定會更快。 感謝如此出色的文章！ 杰米 精彩的帖子！ 很高興看到有人實際構建事物而不是遵循流行語。 這些“ NoSQL”文檔存儲為您直接的分布式文件系統添加的功能正是使搜索與數據保持同步的能力。 有趣的是，與“愚蠢”的文檔存儲（文件系統）相比，您實際上為此功能付出了高昂的代價。 在我看來，保持這種狀態的關鍵是在 Solr 搜索和數據之間出現延遲。 您愿意允許多少時間？ 考慮到這一點，對我來說，將 CouchDB 用作分布式文件系統似乎是個好主意。 我不敢相信它會比您使用的任何工具都要慢。 還有...繼續使用 Solr！ 僅在需要同步搜索時才退回到 CouchDB“視圖”。 這似乎與“ NoSQL”的智慧幾乎相反，但是從您的經驗來看，這似乎是一個很好的實用結論。 您是在 4 刀片系統上直接處理 3900 Request / second，還是還包括 Akamai 流量？ 您如何處理負載平衡？ > “后端在托管約 30 個 VM 的 4 個刀片上運行。” what kind of 'front-end' infrastructure do you have? What kind of VM are you running? VMWare? Xen? KVM? 聽起來好像他們正在將 HP Blade Matrix 與 VMware 一起使用。 “每月有 1.5 億頁面瀏覽量” “每秒可處理 3900 請求”。 算一下：3900 * 60 * 60 =每小時請求 14.000.000 每天 8 小時：每天 14.040.000 * 8 = 112.000.000 因此，其中一個 上面的值 Raghuraman：目標響應時間是多少？ 拉姆基：我們不需要在后端系統中執行超過數千個 rp，因為前端系統的許多部分速度都較慢。 畢竟，系統中的薄弱環節定義了最終的要求/秒！ 如果我們可以使前端數量相同，那就太好了！ 杰米： Lighty 曾經有內存泄漏。 Nginx 或 Cherokee 可能值得一看。 Ramki：到目前為止，Lighty 對我們的表現一直很好，盡管在某些情況下，lighty 會讓我們頭疼。 Nginx 是一個不錯的選擇，我們可以嘗試一下。 杰米（Jamie）：將 MogileFS 視為 GFS 的替代品-GFS 更像是 POSIX 文件系統的替代品，但 MogileFS 可能“足夠”并且應該具有更大的擴展性。 Ramki：該系統的第一個版本在 MogileFS 中運行，并很快成為我們的大問題。 給我，在數據庫中存儲文件的元信息是一場災難。 在短短幾周內，數據庫記錄就接近 150 萬。 查詢變得非常緩慢...但是我喜歡基于 WebDAV 的方法的想法，因此我們嘗試了不使用 MogileFS，但是我們的 LB 當時不支持 HTTP 1.1，因此我們取消了整個想法并將其移至文件系統。 杰米（Jamie）：索爾（Solr）-也許您需要分片搜索引擎，但這可能比它的價值還多。 ;-) 拉姆基：是的，我們已經記了這個。 杰米：使用 ActiveMQ，您是否考慮過將一些較輕的排隊需求轉移到 Redis？ 它具有可用于某些類型排隊的原子構造，并且幾乎可以肯定會更快。 Ramki：我們對 ActiveMQ 有點太深了。 它主要執行路由，服務抽象并為我們保證交付。 對于那些，我不會押注 Redis。 希望我回答了你的問題。 Tal：這些“ NoSQL”文檔存儲為您直接的分布式文件系統添加的功能正是使搜索與數據保持同步的能力。 有趣的是，與“愚蠢”的文檔存儲（文件系統）相比，您實際上為此功能付出了高昂的代價。 在我看來，保持這種狀態的關鍵是在 Solr 搜索和數據之間出現延遲。 您愿意允許多少時間？ Ramki：如文章中所述，DFS 用作鍵值存儲。 并且我們已經設置了 MQ 先寫入存儲然后再寫入 Solr。雖然將其推入 Q 使其異步，但數據的移動在 Q 內部是順序的。這樣一來，您將無法獲得返回任何不存在的內容的搜索 在存儲中。 同樣，假設存儲節點位于本地附近，則數據會立即反映出來。 希望我回答了你的問題。 Tal：考慮到這一點，對我來說，將 CouchDB 用作分布式文件系統似乎是個好主意。 我不敢相信它會比您使用的任何工具都要慢。 還有...繼續使用 Solr！ 僅在需要同步搜索時才退回到 CouchDB“視圖”。 Ramki：我們正在嘗試使用 CouchDB 進行分析。 在開發環境中，我們的速度僅為每秒 1000 請求。 有了存儲和輕松的設置，我們便可以輕松完成 8000+ reqs / s。 當然，1000 res / s 也是非常好的數字。 Tal：這似乎與“ NoSQL”的智慧幾乎相反，但是從您的經驗來看，這似乎是一個很好的實用結論。 Ramki：不確定是否與 NoSQL 相反。 原則上我們離它更近。 例如：沒有“ sql” :)，幾乎沒有架構。 我說這幾乎是因為 Solr 迫使我們擁有一些架構，分布式和鍵值之類的存儲。 Maxim：您是在 4 刀片系統上直接處理 3900 Request / second，還是還包括 Akamai 流量？ Ramki：這里沒有 Akamai。 它是我們所有的后端，不在 akamai 上。 一旦我們有了用于 URL 無效的緩存引擎和規則方法，我們將遠遠超過 3900 r / s。 我們的開發測試是 8500+ r / s 的清漆。 但是請記住，考慮到延遲，這些數字可能并不完全是我們將從外界得到的數字。 Maxim：您如何處理負載平衡？ 拉姆基：這現在可以通過一種彎腰/麻木的方式來解決：)。 我們的資源有限，但是我們需要“無 SPOF”，因此我們在同一個 LB 內針對不同層有點循環。 考慮到 H / W LB 的成本，我們可能不得不采用這種方法。 我們正在尋找 S / W LB 作為替代方案，但我們需要使用刀片來部署它們！ :) 塔爾：您擁有什么樣的“前端”基礎架構？ Ramki：我們也在這里遷移到基于 VM 的環境。 但是再過幾個月，我們將完全使用 VM，并在我們現在構建的系統之上運行。 舊系統將被淘汰。 希望我已經回答了問題。 請確保提出建議。 我希望得到社區的反饋。 -拉姆基 嗨， 我研究的一件事是每秒 3900 req。 您的每日網頁價值為 1544943（http://www.websiteoutlook.com/www.sify.com）。 因此，假設每位用戶 5 次瀏覽量將帶來每天 30 萬用戶或每小時 12500 位用戶或每分鐘 208 位用戶。 或大約每秒 3 個用戶訪問服務器。 所以我的問題是 3 個用戶每秒可以生成 3900 個請求嗎？ RB & GK：如前所述，整篇文章都是關于后端而不是前端。 正如您在我上面的評論中所看到的那樣，“如果我們能夠使前端數量大約相同，那將是非常棒的事情！” 后端不僅會受到前端的攻擊。 后端有許多直接 API 調用。 因此，以上計算并不能完全轉換為后端匹配。 也就是說，我們已經在開發前端，希望我們能達到接近后端的數字。 如果你們在同一方面確實有一些投入，那就太好了。 -ramki 工具的傳播非常有趣。 您對文件系統復制器有何建議？ 你是怎樣做的 ？ 我們在一個城市中擁有 Windows SAN 存儲。 我們想將添加和刪除的文件實時復制到另一個城市的另一個 Windows 框中。 僅當完全寫入文件時，才應復制文件。 杰米：“ Lighty 曾經有內存泄漏。” 過去……過去……一段時間以前……這有什么意義？ Apache 過去有一些問題，nginx 過去有一些問題。 軟件并不完美，并且會通過更新得到修復。 我運行了一堆 lightys，它們處理幾乎相同數量的靜態文件請求（8000 req / s）而不會費力。 以及 PHP 的一些 Hundret re / s 也沒有問題。 很多人將內存泄漏誤認為是 Lighty 緩沖來自后端（例如 PHP）的請求。 因此，如果您通過 Lighty 從 PHP 發送 10MB 數據，它將使用 10MB。 并且它將重新使用此內存以供以后的請求使用。 為什么這樣做？ 好吧，它有助于加快請求的速度，因為您只有數量有限的 PHP 后端，否則這些后端將被速度較慢的客戶端占用。 它可以更快地釋放 PHP“插槽”。 我會在任何時候減少使用 RAM 的情況。 要記住的唯一事情是不要通過 lighty 通過 PHP 發送大文件，這反而是一個壞主意，因為它還有其他一些原因（為此使用 X-sendfile 標頭或直接提供它們）。 因此，為了做出決定，而不是走“呃，但我聽說有人過去有問題..”，而不得不*立即*并針對您的用例來研究它的工作方式。 我想講的教訓是：使用現在（以及將來當然）可以最好地完成任務的工具。 我以前曾經在 PHP 中看到過 100％CPU 的情況，這很奇怪，在某些情況下更新 PHP 很有幫助。 不幸的是，PHP 的 FastCGI 接口不如 mod_php 穩定。 但是它工作得很好。 Ramki：感謝您分享您的架構和經驗教訓，我發現無數據庫方法特別有趣和令人耳目一新。 對 NoSQL 想法的深入了解可能不是更好的選擇。 榮譽 沒有， 我不確定 websiteoutlook 的統計信息，但對于我知道其審計數的幾個網站，它們顯得有些低（10 倍）。 無論如何，每月有 1.5 億次頁面瀏覽量（是網站外觀數字的 3 倍），平均每秒 57 次頁面瀏覽量。 3900 次/秒是每頁瀏覽 68 次（您的 3 個用戶（真正是 3.57 個用戶）x 5 頁/訪問 x 不足 3 的因素）。 頭版頁面有 80 個元素，即使緩存率很高，考慮到高峰期和一個前端請求也會導致多個后端請求，因此乘數似乎并不是很大的乘數。 廣泛的數字對我來說似乎很合理。 關于進行綜合瀏覽和請求計算的人員： 將網頁瀏覽量視為用戶的完整呈現頁面是很常見的，這反過來可能轉換為針對后端的 1 到 50 個請求，具體取決于呈現頁面所需的后端信息源的數量。 您無法對它們進行計算，因為您將對蘋果和梨進行計算。 每月觀看次數總計超過 30 天，而 3900 req / s 則是特定時刻的峰值 根據視圖的數量和使用情況的一些假設，您可以計算出大約并發用戶的平均數，該數量永遠不會接近峰值時的并發用戶數。 您正在運行哪個 GFS 版本的 GFS1 或 GFS2？ 您將在文件系統中存儲多少數據？ 我們曾經將許多數據存儲在 GFS（1）中，但是由于可伸縮性問題而遠離了它。 主要問題是鎖定，無法擴展文件系統而沒有停機時間以及對復制/冗余的不良/不存在的支持。 從那時起，我們的數據量已經增長到了驚人的水平。 1 PB。 我也很好奇您用于在以下位置存儲 GFS 數據的基本存儲硬件：iscsi，光纖，AoE？ 拉蒙 Mohan Radhakrishnan：您對文件系統復制器有何建議？ 你是怎樣做的 ？ 我們在一個城市中擁有 Windows SAN 存儲。 我們想將添加和刪除的文件實時復制到另一個城市的另一個 Windows 框中。 僅當完全寫入文件時，才應復制文件。 Ramki：我們已經嘗試解決這個問題已有相當長的時間了。 到目前為止，我們僅在一個數據中心上運行，并且 GFS 集群安裝在局域網中的 2-3 個節點上，因此其他節點可以立即看到每次寫入。 鑒于此，我們沒有復制問題。 但是，我們已經在尋找在大約 800 英里之外的印度兩個城市中部署應用程序的選項，我們希望使用主動-主動設置。 根據上下文，我們要求存儲提供商在兩個城市之間進行實時復制。 作為 ISP，我們的延遲相對較小（我認為），大約 40 毫秒。 即使有這種延遲，任何存儲提供商都無法做到近乎實時。 有一家公司說我們可以做到，并要求他們證明這一點。 他們部署了箱子，這是災難性的失敗！ 當然，這都是異步復制，同步復制是同時關閉兩個站點的最佳方法！ 玩笑！ :)同步鎖定源文件系統，同步到另一個站點，其他站點鎖定文件系統，寫入，確認到源，源站點釋放鎖定。 在這段時間內，編寫文件的客戶端正在等待……您猜對了。 總結： -如果您的延遲超過 5 毫秒且實時，則任何存儲提供商都無法做到這一點。 即使延遲對您來說較小，也請他們先進行證明。 -構建您自己的復制系統。 保持異步。 我們現在正在考慮做的是： 我們已經將內容推送到 MQ。 現在，內容也將被推送到其他城市的另一個隊列。 這樣，幾乎可以立即在兩個位置復制數據。 然后我們將接受可能會有的輕微延遲。 我認為延遲將少于 5 秒，這比存儲提供商建議的 10-15 分鐘復制更好。 無論如何，我們必須自己進行測試。 我們擁有的一大優勢是，甚至文件的刪除也是 XML 請求，因此也要經過 Q。 對于較大的二進制文件（視頻&圖像），我們采用略有不同的方法。 所有這些都寫入臨時目錄，并且守護程序將文件移動到適當的目錄。 我認為有 2 個城市時，這不會給我們帶來很多頭痛。 除了基于 ESB / MTOM 的方法外，別無其他想法，并通過隊列推送元數據。 Ramon：您正在運行哪個版本的 GFS 或 GFS2？ 您將在文件系統中存儲多少數據？ 我們曾經將許多數據存儲在 GFS（1）中，但是由于可伸縮性問題而遠離了它。 主要問題是鎖定，無法擴展文件系統而沒有停機時間以及對復制/冗余的不良/不存在的支持。 從那時起，我們的數據量已經增長到了驚人的水平。 1 PB。 Ramki：我們在 GFS1 上遇到了同樣的問題，我們現在在 GFS2 上。 但是，當我們必須在 VM 上運行節點時，仍然存在擴展問題。 支持的虛擬機數量不超過 2 個，添加集群的第 3 個節點有時會掛起。 也許這也是 GFS1 的問題，我們擔心被吊死。 您對此有一些了解嗎？ 當前數據大小約為 1.5 Tera。 我們尚未將舊內容遷移到新系統。 拉蒙：我也想知道您用來在 GFS 數據上存儲 iscsi，光纖，AoE 的底層存儲硬件嗎？ Ramki：iSCSI 希望答案。 -ramki 您還將向用戶提供電子郵件。 您是否還保留沒有數據庫的身份驗證記錄？ 另外，你們使用哪個郵件服務器？ 嗨 Ramki， 想知道你們是否看過 AWS（http://aws.amazon.com）？ 在它們上運行會簡化你們正在做的許多 VM 管理工作嗎？ 它們還提供了負載平衡和自動擴展解決方案（http://aws.amazon.com/autoscaling/）和隊列服務（http://aws.amazon.com/sqs/）。 嗨，杜沙爾， 我們查看了 AWS 的其他項目。 我們面臨的最大問題是延遲。 我們不能忍受這種延遲。 除此之外： -我們有自己的管道 -我們在各個城市都有自己的數據中心。 -我們已經在下文中介紹了許多內容。 因此，在我們的案例中，這實際上沒有任何意義。 -ramki