doc: 阅读reactor subscription文档
This commit is contained in:
@@ -292,4 +292,23 @@ prefetch的补充优化通常采用75%的启发规则,一旦操作符发现75%
|
||||
|
||||
有如下operators可以对请求的prefetch进行调整
|
||||
|
||||
##### limitRate
|
||||
#### limitRate
|
||||
除了`prefetch`之外,还可以通过`limitRate`或`limitRequest`来直接针对请求进行调节。
|
||||
|
||||
`limitRate(N)`将来自下游的请求进行拆分,当来自下游的请求被传播到上游时,其会被拆分为small batches。例如,如果下游调用`request(100)`,此时`limitRate(10)`将会将其拆分为10个`request(10)`再传播给上游。并且,在此基础上,limitRate还实现了prefetch中的补充优化。
|
||||
|
||||
除了`limitRate(N)`之外(当没有传递`lowTie`时,limit默认会取`N - N>>2`,即`ceil(N * 0.75)`),limtRate还存在`limitRate(highTie, lowTie)`的重载方法。
|
||||
|
||||
##### lowTie
|
||||
当lowTie取不同值时,其补充策略如下:
|
||||
- `lowTie<=0`:如果`lowTie`小于或等于0,则limit取值和`prefetch`值相同,仅当prefetch中所有元素都被下游处理完时,limtRate operator才会向上游请求数据
|
||||
- `lowTie>=prefetch`: 当lowTie大于或等于prefetch时,limit取值为`ceil(prefetch * 0.75)`,此时,补充策略和prefetch默认相同,当75%的数据被下游处理时,limitRte会重新向上游请求75%的数据
|
||||
- 若lowTie位于`(0, prefetch)`区间之间
|
||||
- 若prefetch的值为`Long.MAX_VALUE`,那么limit的值也为`Long.MAX_VALUE`
|
||||
- 若prefetch值不为`Long.MAX_VALUE`,那么limit的值为`lowTie`,即`lowTie`的值即为消费后重新拉取的限制值
|
||||
|
||||
#### limitRequest
|
||||
`limitRequest(N)`用于限制下游请求的总个数。例如,向`limitRequest(10)`发起两次request,一次请求3一次请求8,那么最后下游只会接收到10个元素。
|
||||
|
||||
> 一旦source发送的元素个数超过`N`时,`limitRequest`将会认为sequence已经完成,会向下游发送onComplete信号
|
||||
|
||||
|
||||
Reference in New Issue
Block a user