有没有办法查看Spring RSocket中的REQUEST_N交换

问题描述

我正在使用RSocket的Spring支持，特别是请求流模型。即：

@MessageMapping("stream")
Flux<SubscriptionMessage> stream(final SubscriptionMessage request,@AuthenticationPrincipal UserDetails user) {
    //....
}

如果我正确理解RSocket，则Flux响应将作为一系列 根据request（n）约定的有效负载消息。例如。一次n个有效载荷消息。在每个系列的消息之后，客户端都会使用REQUEST_N消息将其归功于服务器以发送其他集合，这为缓解背压奠定了基础。

在Java库的API（基于io.rsocket.RSocket的org.springframework.messaging.rsocket）中，有什么方法可以在请求到达时处理/访问REQUEST_N消息，或者设置其值N通过策略明确地确定N（并查看请求者已传递给服务器的值）？

原因/原因：我正在Kafka上实现一个rsocket外观，并试图为订阅提供一种请求流机制，以支持在消息被消耗时自动进行偏移提交。 对于请求流约定，我认为请求者偶尔进行REQUEST_N交互 成为可以提高主题的提交偏移量的理想点，因为它是通过 请求者意味着已收到响应者发送的先前的有效载荷消息。

我看到的唯一其他选择是使用请求通道模型，以便请求者可以发送 和初始订阅请求，并开始接收数据，还发送 周期消息，以专门控制同一通道上的提交偏移量。无论如何，我正在考虑提供这一点， 但是想知道是否有一种方法可以将逻辑注入到流的周期性request（n）循环中。

解决方法

反应堆的默认值过去是无限的或取消的。您可以使用诸如take或limitRate之类的内置运算符来自定义请求的行为。

https://github.com/making/rsc/blob/50d0c3dc43c60d3b3fe42e5586df49adb016a9cb/src/main/java/am/ik/rsocket/InteractionModel.java#L41-L52

或者实现自己的运算符，或者使用定制的订阅/订阅逻辑来精确地控制它。这涉及更多，因此请首先尝试一下，并举例说明您要做什么。

查看类似于https://projectreactor.io/docs/core/release/reference/#_on_backpressure_and_ways_to_reshape_requests的文档