使用SpringWebFlux对响应应用分页是否会导致阻塞？

Question

下面的代码是否阻止调用，如果是，如何使其成为非阻塞？i、 e.使反应式Java流的使用变得无用？如何在不阻塞呼叫的情况下分页？

目前，我有一个webClient调用后端服务，该服务返回流量

控制器方法中的代码如下所示-

// getItems method was initially returning a Flux but my method was failing to paginate it so now that method returns a Mono<List<Item>>
// I would really like to see how I can make this work with Flux!
return webClient.getItems(...required params...)
           .map(r -> {
              // we get offset and limit from query params
              var paginatedItems = listPaginator.applyPagination(r, offset, limit)
              // assembleItemResponse method maps all values from backend service to new response required by client
              List<ItemResponse> itemResponseList = paginatedItems.stream()
                       .map(this::assembleItemResponse)
                       .collect(Collectors.toList());

              return ResponseEntity.ok()
                         .body(ItemListResponse.builder()
                                 .itemCount(r.size())
                                 .pagesize(itemResponseList.size())
                                 .listItems(itemResponseList)
                                 .build());
              });




Answer 1

使用SpringWebFlux对响应应用分页是否会导致阻塞？

分页本身没有任何阻塞，但实现这一点的正常Spring数据方法是使用分页和排序存储库查询数据层，仅获取该特定页面所需的结果（与查询数据层中所有可能的结果然后进行过滤相反，这可能会根据数据大小产生巨大的性能影响）不幸的是，这一方法正在受阻。到目前为止，PagingAndSortingRepository还没有对应的响应式存储库。

然而，这似乎不是你在这里要做的。这里有一个完整的示例可能会有所帮助，但它看起来像是一个项目列表，然后您将对整个列表应用一个listPaginator来减少它。如果是这样的话，那么它就没有必要被阻塞，所以它应该是安全的。但是，如果不知道applyPagination和assembleetemresponse方法的具体行为，就无法确定。如果这些方法是阻塞的，那么你在这里不安全，你需要考虑另一种方法（确切地说，什么方法需要一个更完整的例子）。如果这些方法是非阻塞的（它们只处理它们拥有的数据，不调用任何其他web/db服务等），那么您就可以了。

另外，你可以考虑看一下Blockhound，这样你就能确定你是否有任何阻塞电话。