java - 持久映射映射到队列以实现公平调度？

Question

我们的系统需要处理来自数千个客户的数十亿次查询，以获得数百万个资源。某些资源的查询频率会比其他资源高得多。每个客户将同时提交数百到数亿个查询。由于每个资源每分钟只能支持数千个查询，因此查询将被排队并异步确定其结果。

现在，问题是:每个客户端的查询对于每个资源都需要给予相同的优先级。也就是说，如果一个客户端针对特定资源提交了一百万个查询，然后另一个客户端紧接着提交了十几个查询，那么第二个客户端不必等待第一个客户端的查询在其查询之前得到处理。相反，应该首先处理一个客户端的第一个查询，然后处理另一个客户端的第一个查询，然后第一个客户端的第二个查询，依此类推，如此往复。 (以及针对两个以上客户端和多个资源的类似想法；而且，只要保留这个基本想法，它可以稍微不那么细化)。

如果它足够小，可以在内存中，我们只需要有一个从资源到从帐户到查询队列的映射，并按资源循环迭代帐户；但事实并非如此，所以我们需要一个基于磁盘的解决方案。我们还需要它具有健壮性、高可用性、事务性等。。我有什么选择？我正在使用 Java SE。

提前致谢!

Answer 1

我对 HBase 的了解比对 Cassandra 的了解要多得多。我的回复的某些方面是 HBase 特定的，我将这样标记它们。

假设您配置了足够的硬件，那么像 Cassandra 或 HBase 这样的 BigTable 实现将为您提供以下功能:

1. 能够以极高的速度存储和检索您的查询
2. 能够以极高的速率吸收删除(尽管使用 HBase 和 Cassandra，刷新磁盘写入可能会导致周期性延迟)

简单地说，我可以看到一个模式，您使用资源 id 作为行键和帐户 id 的组合，也许还使用时间戳作为列键，但是(特别是在 HBase 中)这可能会导致托管某些流行的服务器中出现热点资源(在 HBase 和 Cassandra 中，单个服务器负责一次托管任何给定行的主副本)。在 Cassandra 中，您可以通过使用异步写入(仅写入一个或两个节点，并允许八卦复制它们)来减少更新的开销，但这可能会导致旧记录的存在时间比您在网络流量低的情况下预期的时间要长得多。高的。在 HBase 中，写入始终一致，并且始终写入托管该行的 RegionServer，因此热点肯定是一个潜在问题。

您可以通过将行键设置为资源 ID 和帐户 ID 的组合来减少热点的影响，但随后您需要扫描所有行键以确定具有未完成的资源查询的帐户列表。

您可能没有考虑到的另一个潜在优势是直接从 HBase 或 Cassandra 数据节点运行查询的潜在能力，从而使您无需再次通过网络将查询发送到执行程序进程来实际运行该查询询问。您可能想查看 HBase Coprocessors或Cassandra Plugins做类似的事情。具体来说，我正在谈论改变这个工作流程:

                                 /-> Query -> Executor -> Resource -> Results -> \
Client -> Query -> Query Storage --> Query -> Executor -> Resource -> Results -> --> Client
                                 \-> Query -> Executor -> Resource -> Results -> /

变成这样的东西:

                                 /-> Query -> Resource -> Results -> \
Client -> Query -> Query Storage --> Query -> Resource -> Results -> --> Client
                                 \-> Query -> Resource -> Results -> /

但这在您的用例中可能没有意义。