gRPC中的分页

Question

我正在使用gRPC对一个调用进行分页,并试图弄清楚它的选项/近似值.这是一个明智的问题吗？我可以用什么资源来做这件事？

Answer 1

谷歌自己为此编写了一份很好的设计文档： https://cloud.google.com/apis/design/design_patterns#list_pagination

• 在方法的请求消息中定义一个string字段。客户端使用该字段来请求列表结果的特定页面。page_tokenList
• 在方法的请求消息中定义一个int32字段。客户端使用此字段来指定服务器返回的最大结果数。服务器还可以进一步限制单个页面返回结果的最大数量。如果page_size为0，则服务器将决定返回结果的数量。page_sizeList
• 在方法的响应消息中定义一个string字段。该字段表示用于检索下一页结果的分页标记。如果该值为“”，则表示该请求没有进一步的结果。next_page_tokenList

关于用于部分响应的部分FieldMask也值得一读，因为这是常见的 api 设计模式

Answer 2

这个问题已经很老了，但我觉得答案中缺少一些东西。

虽然恕我直言更喜欢流式传输，但我有一些“传统”分页非常有用的情况。让我们想象一个user服务，它允许 CRUD 访问用户存储并具有一个ListUsers和一个SearchUsersrpc。在这里将结果分块到页面中要方便得多。

我个人使用谷歌的方法：https : //github.com/googleapis/googleapis/blob/master/google/cloud/resourcemanager/v2/folders.proto

Answer 3

分页与分块二进制有效负载非常相似。我在gRPC + Image Upload中的回复可能值得一读。

也就是说，分页可能有不同的权衡，因为它的吞吐量通常要低得多，而且有时使用单独的请求并不难。低吞吐量可能会阻止流量控制足够快地发挥作用。对于完全动态的结果（如搜索结果）使用单独的请求更困难，但对于更静态的数据（如资源的子项）可能不是什么大问题。

由于 gRPC 流控制可能会缓冲太多，因此一个额外的选择是使用流式传输但引入应用程序级流控制。使用应用程序级流控制，您可以在流上使用消息请求您想要多少响应，这并不难使用或实现。有人讨论过在 gRPC 中原生支持精确的基于消息的流控制（在这种情况下会产生类似的结果），但不清楚是否以及何时会发生这种情况。