algorithm - 多头分页查询结果

Question

我们有一个用于对象之间关系建模的微服务。关系是在具有基数约束(如 1-1、1-N、N-N 等)的主要对象和次要对象之间定义的。微服务提供 API，如创建关系、查找关系、获取次要关系、获取主要关系等。

查询 API“Get secondaries”获取一个主要对象并返回所有相关的次要对象。由于相关的次要对象可能很大，因此对结果进行分页。

我们有另一个微服务，它很好地利用了这个关系微服务来处理关系。此消费服务接受类似的分页选项，如页面索引和编号，并将其传递给关系服务，并将从关系服务获得的页面结果返回给调用应用程序。到目前为止一切顺利。

我们最近发现消费微服务与关系微服务之间存在一些冲突，因为它必须多次调用“获取辅助对象”API，因为必须为多个主要对象获取辅助对象。

因此，我们考虑通过使其接受多个主要对象作为输入来使“获取次要对象”API 成为批量 API。但是后来我们陷入了分页的工作方式。API 会为每个主要对象返回相关的次要对象，但会像之前一样将次要对象限制为页面大小。
这对于第一次调用来说似乎很好，但我们不确定这对于后续调用会如何表现。如果次要对象的数量少于一个或多个主要对象的页面大小，那么后续调用的输入应该是什么。我需要再次传递那些主要对象吗？

这是我们寻求有关如何设计此批量 API 的建议的地方。欢迎任何意见。

Answer 1

基本上，您应该有一些方法来确保关系服务在收到分页请求时知道原始查询是什么。

关系服务处理此问题的一种简单且可维护的方法是通过以某种方式对请求的主要对象进行排序(即按 Id 字母顺序排序)来预处理请求，然后简单地遍历主要对象，添加次要对象到响应，直到响应已满。

客户端要做的最简单的事情就是始终使用相同的批处理请求，并只向请求添加索引号或页面 token 。

我会推荐一个页面标记，它提到最后看到的项目(例如，lastSeen=primaryId,secondaryId(您应该以某种方式对其进行混淆以避免泄漏抽象))。然后，该服务可以查看原始请求，并知道在何处继续遍历所有主要对象。

或者，您可以将足够的信息编码到一个页面标记中，以便您可以从原始请求中重建您需要的任何内容。这允许您对后续请求的查询进行一些调整。 (例如，如果客户端请求主要对象 A-Z，而您在第一个响应中返回次要对象 A1 - J5，那么您可以将请求修改为 J-Z ; 已经看过 J5，对其进行编码，这样你就不会泄露你的实现细节，并将它作为页面 token 返回给客户端。)然后，而不是用 原始请求 + 页码 < 进行响应，客户端只需使用页面 token 进行响应。

无论哪种方式，关系服务的客户都应该永远必须“弄清楚”下一页的请求应该是什么。分页应该只要求消费者递增一个数字或使用关系服务提供给它的页面标记进行响应。

另一个考虑因素是您正在使用的数据库。例如，在 DynamoDB 中，为查询获取第 100 个项目的方法如 select * from secondaries where primaryId='ABC' 要求您读取直到第 100 个项目的所有项目。如果你有一个 NoSQL 数据库，或者如果你认为你可能会在未来的某个时候迁移到 NoSQL 数据库，你可能会发现页面 token 使得维护你在结果集中的位置变得更加简单(与索引号)。

我找到了 this article对我自己学习分页很有帮助，我推荐阅读它。它主要处理 UI 的分页问题，​​但基本原理是相同的。

TLDR:不要让消费者做任何工作。消费者应使用添加的索引号或页面 token 重复原始请求，或者消费者应发送仅包含页面 token 的请求。