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