我几乎没有处理大量交易网站的经验，最近遇到了这个有趣的问题。我有兴趣知道Java Web应用程序中的瓶颈会在高负载（每秒数千个请求）下发生。如果有人能给我一个高级别的方法来思考以下问题，那就太棒了！
我唯一想到的是使用memcached来缓存数据库查找，但我不知道如何计算每个请求所花费的时间，因此系统可能会计算每秒的请求数能够处理。
问题： 必须设计Internet规模的应用程序来处理大量事务。描述一个系统的设计，该系统必须每秒平均处理30,000个HTTP请求。 对于每个请求，系统必须使用通过URL查询字符串传入的关键字查找5000万字的字典。每个响应都包含一个包含单词定义（100字节或更少）的字符串。
描述系统的主要组件，并注意应该是哪些组件 自定义构建以及哪些组件可以利用第三方应用程序。包括每个组件的硬件估计。请注意，设计应包括最低的硬件/软件许可成本。
记录提出估算的理由。
描述如果定义为每个10千字节，设计将如何变化。
答案 0 :(得分：2)
作为背景，您可能会注意到诸如specmarks之类的标记。与你的场景相比，处理的数量要多得多，但是你会发现你的30,000 req / sec是一个相对较高但不是非常高的数字。
您可能还会发现Joines et al有用。 （免责声明：他们是同事。）
在您的方案中，我预计会按成本的降序排列：
你没有进行复杂的处理（例如图形渲染或火箭科学类型数学）。所以首先猜测：如果你的字典是一个数据库，那么执行查询的成本将主导其他一切。传统上，当我们遇到Web / App服务器层的瓶颈时，我们通过添加更多实例进行扩展，但如果数据库是瓶颈，则更多的是问题。那么一个方向：您对数据库引擎的性能有多大可以达到30k tps？
您的第一个观察：缓存内容是一种常用的策略。在这里，您（大概）在整个字典中都有随机点击，因此缓存最近的asnwers本身可能无济于事，除非......你可以缓存整个字典吗？
50,000,000 *（100 +开销）== ??
在64位操作系统上的64位JVM上它可能适合吗？
如果没有（并且数据变得非常大，那么可能不是），那么我们需要扩展。因此，可以使用切片缓存的策略。拥有（例如）4台服务器，分别服务于A-F，G-M，N-P，T-Z（并注意，4个独立的缓存或4个独立的数据库）。让调度员指导请求。
答案 1 :(得分：1)
我要做的第一件事就是质疑数字。英语有大约170,000个常用词。添加所有其他常用语言，您将不会超过几百万。如果不是这种情况，您可以在快速缓存中缓存最常用的单词，在缓存较慢的缓存中缓存较不常见的单词。即使每秒30K请求，也需要大约30分钟来获得每个单词。
基本上，如果数字不是真实的话，设计大型系统是没有意义的。
在64位JVM上，这非常适合。 5000万*（100 +开销）大约10 GB（开销就像要高，因为你需要密钥和索引数据）12 GB服务器的成本约为2,500美元。
问题就像是请求的数量。您将需要拥有多台机器，但正如其他海报所暗示的那样，这些数字不太可能是真实的。我不认为这项服务会像facebook一样昂贵，但你可能需要几十到几百台服务器才能支持这么多请求。