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

Question

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

我唯一想到的是使用 memcached 来缓存数据库查找，但我不知道如何计算每个请求将花费的时间量以及系统每秒可能有多少请求能够处理。

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

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

记录得出估算值的理由。

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

Answer 1

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

您还可以找到 Joines et al有用。 (免责声明:他们是同事。)

在您的场景中，我希望成本降序排列:

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

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

您的第一个观察结果:缓存内容是一种常用的策略。在这里，你(大概)在整个字典中有随机命中，因此缓存最近的答案本身可能没有帮助，除非......你能缓存整个东西吗？

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

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

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