1. Back Pressure（背壓）在算子層面上很好理解堡妒，背壓的出現(xiàn)代表下游的消費者的消費速度小于上游生產者的生產速度皮迟；但實際上在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的負責轉發(fā)數(shù)據(jù)的nettyServer會收到消息击罪，停止發(fā)送數(shù)據(jù)媳禁，直到上游subtask的ResultPartition撐滿竣稽，上游的算子就被背壓了（追源索驥6.3）毫别。
這樣來說岛宦，一個subtask/算子是否背壓和他本身的處理情況沒有直接關系恋博，而是取決于下游是否有subtask的處理速度一直低于輸入速率债沮；換言之取決于下游算子的busy time疫衩。同時闷煤，如果我們想了解一個subtask的真實處理速率假褪，一個比較好的辦法是看他在（接近）滿busy time的情況下的處理速率生音。
2. 在流處理任務中缀遍，我們很難直接定義和估計一個任務的latency域醇，F(xiàn)link中的end2end-latency metrics用LatencyMarker衡量的更多是通訊和排隊的成本譬挚，而不包含和實際數(shù)據(jù)處理過程相關的延遲信息（bypass）殴瘦。
提問：在Flink中busy time和latency之間的關系如何？
對于一個subtask，我們考慮用和他相關的local buffer pool usage信息來衡量他的input隊列，從而考量lag latency晓勇。
Buffer首先是TaskManager層面的概念绑咱，TM的NetworkBufferPool工廠類管理內存片描融，然后分配給每個subtask私有的LocalBufferPool窿克；上游subtask的output buffer在邏輯上會先進入ResultPartition中的子分區(qū)，然后按照一定的頻率flush給下游算子的InputChannel（追源索驥6.2）玻募。所以本質上Task之間的通訊是TM之間的通訊。
Metrics：InPoolUsage =?floatingBuffersUsage+exclusiveBuffersUsage啸蜜，衡量local buffer pools中已使用buffer的數(shù)量占比衬横，另外像*QueueLength等不被推薦使用；然而InPoolUsage只計算RemoteInputChannel噪叙，忽略了LocalInputChannel（flink doc）睁蕾。
提問：如果下游算子的某一個subtask的處理速率過低瀑凝，具體會如何影響上游算子粤咪？
回顧數(shù)據(jù)從上游到下游的過程（上游算子準備好了之后放進ResultPartition寥枝，通知job master囊拜，master通知下游算子比搭，下游算子向上游算子請求數(shù)據(jù)）；那么如果下游算子的某一個subtask處理速率過低，在InputChannel對應的內存空間占滿后怠苔，他將過少地向上游的所有生產者subtasks請求輸入數(shù)據(jù)柑司，從而導致這些subtask的ResultPartiton占據(jù)內存空間攒驰，導致無法有效處理輸入，進而被背壓劲室，并且將背壓向前傳遞很洋。
提問：一個subtask的背壓對（1）和他處于同一個TM上的其他subtasks喉磁，以及（2）sharing同一個slot的其他subtasks會如何產生影響线定？
