我几乎没有处理大容量事务处理网站的经验，并且最近遇到了这个有趣的问题。我很想知道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一样贵，但是你可能需要数十到数百台服务器来支持这么多的请求。