本质上是流里的数据量伸缩比较大导致的吧，感觉你去自定义source做下限流是不是更优雅一些。
不过说到底流式处理一般是对延迟比较敏感，恨不得用上所有资源让延迟最小化，你这里貌似对资源更敏感。。。 在 2021-08-31 15:19:01，"yidan zhao" <[email protected]> 写道： >不过目前我覆盖实现过很多flink的api，都很难受，因为各种要么private，要么没有get/set，导致只能覆盖实现。没办法继承调整部分实现。 > >刚刚看了下，这个思路实现的话，目前需要自定义个 window 类，不使用 >TimeWindow，需要在window中记录下触发时间，否则trigger的onEventTime方法回调中没办法确认是否当前元素的触发时机。 >或者triggerContext提供currentKey，但我看了TriggerContext中有key，但是没提供getCurrentKey方法，导致。。。 > >yidan zhao <[email protected]> 于2021年8月31日周二 下午3:16写道： > >> cpu尖刺平滑呀。 >> >> Shuo Cheng <[email protected]> 于2021年8月31日周二 下午3:14写道： >> >>> 这样做是要达到设么目的呢? 目前的触发机制以及 early/late fire 满足不了需求么？ >>> >>> On 8/31/21, yidan zhao <[email protected]> wrote: >>> > 如题，我目前计划自定义event time trigger实现分散触发。 >>> > 比如0-5的窗口分散到6-11分触发， 从6开始是因为本身有个1min的乱序处理。 >>> > 同时配合将allowedlateness设置为5min，这样避免窗口状态在触发之前被clean。 >>> > >>> > 不知道想法是否OK呢？ >>> > >>> >>
