Flink：背压，busy time和延迟之间的关系探究

1. Back Pressure（背压）在算子层面上很好理解，背压的出现代表下游的消费者的消费速度小于上游生产者的生产速度；但实际上在Flink的runtime中，每个算子由subtask组成，背压更多是一个subtask层面的概念。

提问：在Flink中back pressure的定义，以及和busy time这一指标的关系如何？

Subtask-level的相关metrics包括：backPressureTimeMsPerSecond， idleTimeMsPerSecond，busyTimeMsPerSecond，三者之和等于1000(ms)；具体来说，当一个task没有可用的output buffers，就处于背压时间，而在有output buffers的情况下，处于busy或者idle时间（flink doc）。

更具体地来说，当一个subtask消费速率低于上游的生产，这个subtask的InputChannel buffer会被撑满，然后上游subtask的负责转发数据的nettyServer会收到消息，停止发送数据，直到上游subtask的ResultPartition撑满，上游的算子就被背压了（追源索骥6.3）。

这样来说，一个subtask/算子是否背压和他本身的处理情况没有直接关系，而是取决于下游是否有subtask的处理速度一直低于输入速率；换言之取决于下游算子的busy time。同时，如果我们想了解一个subtask的真实处理速率，一个比较好的办法是看他在（接近）满busy time的情况下的处理速率。

2. 在流处理任务中，我们很难直接定义和估计一个任务的latency，Flink中的end2end-latency metrics用LatencyMarker衡量的更多是通讯和排队的成本，而不包含和实际数据处理过程相关的延迟信息（bypass）。

提问：在Flink中busy time和latency之间的关系如何？

对于一个subtask，我们考虑用和他相关的local buffer pool usage信息来衡量他的input队列，从而考量lag latency。

Buffer首先是TaskManager层面的概念，TM的NetworkBufferPool工厂类管理内存片，然后分配给每个subtask私有的LocalBufferPool；上游subtask的output buffer在逻辑上会先进入ResultPartition中的子分区，然后按照一定的频率flush给下游算子的InputChannel（追源索骥6.2）。所以本质上Task之间的通讯是TM之间的通讯。

Metrics：InPoolUsage = floatingBuffersUsage+exclusiveBuffersUsage，衡量local buffer pools中已使用buffer的数量占比，另外像*QueueLength等不被推荐使用；然而InPoolUsage只计算RemoteInputChannel，忽略了LocalInputChannel（flink doc）。

提问：如果下游算子的某一个subtask的处理速率过低，具体会如何影响上游算子？

回顾数据从上游到下游的过程（上游算子准备好了之后放进ResultPartition，通知job master，master通知下游算子，下游算子向上游算子请求数据）；那么如果下游算子的某一个subtask处理速率过低，在InputChannel对应的内存空间占满后，他将过少地向上游的所有生产者subtasks请求输入数据，从而导致这些subtask的ResultPartiton占据内存空间，导致无法有效处理输入，进而被背压，并且将背压向前传递。

提问：一个subtask的背压对（1）和他处于同一个TM上的其他subtasks，以及（2）sharing同一个slot的其他subtasks会如何产生影响？