基于 Java 的大容量交易 Web 应用程序

Question

我几乎没有处理大容量交易网站的经验，最近遇到了这个有趣的问题。我很想知道在高负载（每秒数千个请求）下，Java Web 应用程序中的瓶颈会出现在哪里。如果有人能给我一个高层次的方法来思考以下问题，那就太好了！

我想出的唯一方法是使用 memcached 缓存数据库查找，但我不知道如何计算每个请求将花费的时间量，因此系统每秒可能有多少请求可以应付。

问题： 互联网规模的应用程序必须设计为处理大量事务。描述一个系统设计，该系统必须平均每秒处理 30,000 个 HTTP 请求。 对于每个请求，系统必须使用通过 URL 查询字符串传入的关键字来查找包含 5000 万字的字典。每个响应都将包含一个包含单词定义的字符串（100 字节或更少）。

描述系统的主要组件，并注意哪些组件应该是 定制以及哪些组件可以利用第三方应用程序。包括每个组件的硬件估计。请注意，设计应以最低的硬件/软件许可成本实现最高性能。

记录估算的理由。

描述如果每个定义为 10 KB，设计将如何变化。

Answer 1

作为背景，您可能会注意到诸如specmarks 之类的基准。与您的方案相比，处理量要多得多，但您会看到 30,000 次请求/秒是一个相对较高的数字，但并不是非常高。

您可能还会发现Joines et al 很有用。 （免责声明：他们是同事。）

在您的情况下，我希望按成本降序排列：

1. 数据库检索
2. 网络活动读取和返回请求
3. 简单处理

您没有进行复杂的处理（例如图形渲染或火箭科学类型的数学）。所以首先猜测：如果你的字典是一个数据库，那么查询的成本将支配其他一切。传统上，当我们在 Web/App 服务器层遇到瓶颈时，我们会通过添加更多实例来扩展，但如果数据库是瓶颈，那就更成问题了。所以一个方向：30k tps 看起来可行的数据库引擎有什么性能？

您的第一个观察结果：缓存是一种常用的策略。在这里，您（可能）在整个字典中都有随机命中，因此缓存最近的回答本身可能无济于事，除非...您可以缓存整个内容吗？

50,000,000 * (100 + 开销) == ??

在 64 位操作系统上的 64 位 JVM 上可能适合吗？

如果不是（并且随着数据变得非常大，那么可能不会），那么我们需要扩展。因此，可以使用对高速缓存进行切片的策略。拥有（例如）4 台服务器，分别为 A-F、G-M、N-P、T-Z 提供服务（并且请注意，4 个单独的缓存或 4 个单独的数据库）。让调度员指导请求。

Answer 2

我要做的第一件事就是质疑数字。英语有大约 170,000 个常用词。添加所有其他通用语言，您将拥有不超过几百万。如果不是这种情况，您可以将最常见的单词缓存在快速缓存中，将不太常见的单词缓存在较慢的缓存中。即使每秒请求 30K，也需要大约 30 分钟才能获取每个 unqiue 字。

基本上，如果数字不是真实的，那么设计大型系统是没有意义的。

在 64 位 JVM 上，这很适合。 5000 万 *（100 + 开销）大约是 10 GB（开销可能很高，因为您需要拥有密钥和索引数据）一台 12 GB 的服务器成本约为 2,500 美元。

问题就像是请求的数量。您将需要拥有多台机器，但正如其他海报所暗示的那样，这些数字极不可能是真实的。我不认为这项服务会像 facebook 一样昂贵，但您可能需要数十到数百台服务器来支持这么多的请求。