背压（backpressure）在reactor-netty中的具体表现是什么？

backpressure的基本含义还是很好理解的。从reactor的角度看，就是订阅者给提供者的一个“反馈”，我需要多少你就给我多少，而不是你给我多少我消费多少，而不管我吃不吃得下。

从reactor的源码上看，就是subscription.reqeust(n)这个动作是在Subscriber中调用的。

我现在不太敢确定的是：放到网络环境中，以webflux的默认设置，或直接上reactor-netty为例，这个服务端给出的backpressure最直接的表现是不是netty的io线程向socket缓冲区执行request(n)。
直觉上应该是这样的，让我不确定的原因是当这个“backpressure”放到完整的服务调用环境中时就比较难以定位了。抱歉我因为本来就有点迷糊，所以没办法详细描述我的疑问，所以我试着列一些与我的疑问相关的因素：

• 背压在服务调用上可以理解为一种“流控”。但这里的背压应该和令牌桶、熔断这些没关系

• 对这种背压的流控，比较核心的内容应该是：当client发送的速率超过server端当前的消费上限时，应该是“server端对client说，我现在可以处理100个(或大小)的请求，你现在给我”。

  • 这一部分我猜是reactor-core借助netty流量整形的api实现的，handler的名字记不清了，大概是ChannelTrafficShapeHandler之类的。不知道猜测是否正确？
  • 如果我的猜测正确，那么就印证了我问题中的这句：“netty的io线程向socket缓冲区执行request(n)”
• 如果上面的猜测正确，那么背压就是server端的线程给自己的socket缓冲区的背压，如果要最终反馈到client，一定还需要别的要素参与。

• 我猜测的要素和相关不懂的问题如下：

  • server的socket缓冲区满了之后，是不是client这边实际的发送速率也会跟着降下来？并且如果client不考虑自己的发送缓冲区大小的话，就会OOM爆掉？
  • 上面这一条针对“数据大小”的背压，如果是针对请求数的，应该就不叫“背压”了吧，直接server上令牌桶，client上hystrix就可以了？
  • 或者真的要具体情况具体分析？因为前面这些我只考虑了rpc、http这样的请求，现在突然想到，如果是一个client与server建立了一个长连接，然后不停的发送一些数据的话，那么可能直接两边都上NIO+流量整形就够了吧。

抱歉写了不少内容后还是没办法理清自己的问题，大伙能帮忙解惑多少就解惑多少吧....