我幾乎沒有處理大容量事務處理網站的經驗，並且最近遇到了這個有趣的問題。我很想知道Java Web應用程序中的瓶頸在高負載（每秒數千次請求）下會發生什麼。如果有人能夠給我一個高層次的思考下面的問題，那太棒了！基於Java的大容量事務Web應用程序
我唯一想到的是使用memcached來緩存數據庫查找，但我不知道如何計算每個請求將花費的時間量，因此係統每秒請求多少個請求可能能夠處理。
問題： 互聯網級應用程序的設計必須處理大量的事務。描述必須每秒平均處理30,000個HTTP請求的系統的設計。 對於每個請求，系統都必須使用通過URL查詢字符串傳遞的關鍵字來查找包含5000萬字的字典。每個響應將由一個包含單詞定義的字符串（100個字節或更少）組成。
描述系統的主要組件，並注意哪些組件應定製爲 ，哪些組件可以利用第三方應用程序。包括每個組件的硬件估計。請注意，設計應該包含最低硬件/軟件許可成本下的最高性能。
記錄估算的基本原理。
描述如果定義各爲10千字節，設計將如何改變。
作爲背景，你可能會注意到bechmarks如specmarks。與你的情況相比，有更多的處理，但你會看到你的30,000瑞克/秒是一個相對較高，但不是非常高的數字。
您可能還會發現Joines et al有用。 （免責聲明：他們是同事。）
在你的情況我希望在降低價格的順序：
你沒有做複雜的處理（例如圖形渲染或火箭科學類型的數學）。所以首先猜測：如果你的字典是一個數據庫，那麼做查詢的費用將主宰其他的一切。傳統上，當我們遇到Web/App服務器層的瓶頸時，我們會通過添加更多實例來擴展規模，但是如果數據庫是瓶頸問題，那更是一個問題。所以一個方向：數據庫引擎可以期望什麼樣的性能可以實現30k tps？
你的第一個觀察：緩存的東西是一個常用的stategy。在這裏，你可能會在整本字典中隨機點擊，因此緩存最近的內容可能不會有幫助，除非......你能緩存整個內容嗎？
50,000,000 *（100 + overhead）== ??
對於64位操作系統上的64位JVM，它可能適合？
如果沒有（並且數據變得非常大，那麼可能不會），那麼我們需要進行縮放。因此可以使用切片緩存的策略。 （例如）有4臺服務器，分別服務於A-F，G-M，N-P，T-Z（並且注意4個獨立的緩存或4個獨立的數據庫）。請調度員指導請求。
我會做的第一件事就是質疑數字。英語通常使用約170,000字。添加所有其他常用語言，你將不會超過幾百萬。如果不是這種情況，您可以將最常用的單詞緩存在快速緩存中，並將較不常用的單詞緩存在較慢的緩存中。即使每秒處理30K的請求，也需要大約30分鐘的時間來獲取每個單詞。
基本上，如果數字不是真實的，設計大型系統就沒有意義。
在64位JVM上很容易。 5千萬*（100 +開銷）約爲10 GB（開銷高，因爲您需要擁有密鑰並對數據進行索引）12 GB服務器的成本大約爲2,500美元。
問題就像是請求的數量。你將需要有多臺機器，但正如其他海報所說，這些數字不太可能是真實的。我不認爲這個服務和Facebook一樣貴，但是你可能需要數十到數百臺服務器來支持這麼多的請求。