B到C如何分割成2个任务，你是打算把B里面每个Window的数据都Sink出来，然后在另外一个任务里读进来再用C处理么?
这样做的意义何在呢？仅仅从监控层面看不见反压而已(反压实际上转移到连接B和C的存储上来了)，整体的系统开销是上升的，对吞吐和延迟恐怕并没有正面的影响。 对性能影响大的肯定是瓶颈部分，不提高C的处理能力，优化其他部分没有多大意义。 如果只是希望反压的影响更平滑，可以尝试增大buffer，整体开销恐怕还是比增加一个任务要小。 在 2021-06-15 20:03:32，"yidan zhao" <[email protected]> 写道： >flink 的task单线程，我那个问题中，很可能当B被反压时候，线程被卡在向C发送的过程中。这样B本身就无法处理A的输入。进而导致receive >buffer满，然后A被反压。 >如上为我的想法，这个也比较坑。如果是这样，那对于我这种类似的case，如果C属于计算复杂的task，B属于window的话。可能需要从B到C之间分割成2个任务。否则性能影响还是比较大的。 > >东东 <[email protected]> 于2021年6月15日周二 下午7:07写道： >> >> flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive >> buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。 >> 所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。 >> >> 在 2021-06-15 17:39:26，"yidan zhao" <[email protected]> 写道： >> >假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。 >> > >> >A是Kafka数据源，数据qps很平滑。 >> >B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。 >> >C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。 >> > >> >总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂） >> > >> >对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。 >> >C task busy，进而导致B被反压，即B的backpress值很高。 >> > >> >此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。 >> > 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。 >> >但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。 >> >为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。 >> > >> >想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？ >> >还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？
