通过增加延迟使密钥失效;如何减少延迟?

w80xi6nr  于 2021-06-24  发布在  Flink
关注(0)|答案(1)|浏览(492)

当我用keyedstream运行一个简单的flink应用程序时,我观察到一个事件的时间延迟从0到100ms不等

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
    DataStream<Long> source = env.addSource(new SourceFunction<Long>() {
        public void run(SourceContext<Long> sourceContext) throws Exception {
            while(true) {
                synchronized (sourceContext.getCheckpointLock()) {
                    sourceContext.collect(System.currentTimeMillis());
                    Thread.sleep(1000);
                }
            }
        }

        public void cancel() {}
    }).keyBy(new KeySelector<Long, Long>() {
        @Override
        public Long getKey(Long l) throws Exception {
            return l;
        }
    }).addSink(new SinkFunction<Long>() {
        @Override
        public void invoke(Long l) throws Exception {
            long diff = System.currentTimeMillis() - l;
            System.out.println("in Sink: diff=" + diff);
        }
    });
    env.execute();

输出为:

in Sink: diff=0
in Sink: diff=2
in Sink: diff=4
in Sink: diff=4
in Sink: diff=5
in Sink: diff=7
in Sink: diff=9
in Sink: diff=9
in Sink: diff=11
in Sink: diff=12
in Sink: diff=14
in Sink: diff=14
in Sink: diff=16
in Sink: diff=17
in Sink: diff=18
in Sink: diff=19
in Sink: diff=21
in Sink: diff=22
in Sink: diff=24
in Sink: diff=24
in Sink: diff=26
in Sink: diff=27
in Sink: diff=29
in Sink: diff=29
in Sink: diff=31
in Sink: diff=32
in Sink: diff=34
in Sink: diff=34
in Sink: diff=36
in Sink: diff=37
in Sink: diff=39
in Sink: diff=40
in Sink: diff=41
in Sink: diff=43
in Sink: diff=45
in Sink: diff=45
in Sink: diff=47
in Sink: diff=48
in Sink: diff=50
in Sink: diff=50
in Sink: diff=52
in Sink: diff=53
in Sink: diff=55
in Sink: diff=57
in Sink: diff=57
in Sink: diff=59
in Sink: diff=60
in Sink: diff=61
in Sink: diff=62
in Sink: diff=63
in Sink: diff=65
in Sink: diff=66
in Sink: diff=67
in Sink: diff=69
in Sink: diff=70
in Sink: diff=72
in Sink: diff=72
in Sink: diff=74
in Sink: diff=76
in Sink: diff=77
in Sink: diff=78
in Sink: diff=79
in Sink: diff=81
in Sink: diff=82
in Sink: diff=83
in Sink: diff=84
in Sink: diff=86
in Sink: diff=87
in Sink: diff=88
in Sink: diff=89
in Sink: diff=91
in Sink: diff=92
in Sink: diff=94
in Sink: diff=94
in Sink: diff=96
in Sink: diff=97
in Sink: diff=99
in Sink: diff=99
in Sink: diff=0
in Sink: diff=2
in Sink: diff=3
in Sink: diff=4
in Sink: diff=4
in Sink: diff=5
in Sink: diff=7
in Sink: diff=9
in Sink: diff=9
in Sink: diff=11
in Sink: diff=12
in Sink: diff=14
in Sink: diff=14
in Sink: diff=16
in Sink: diff=17
in Sink: diff=18
in Sink: diff=19
in Sink: diff=21
in Sink: diff=22
in Sink: diff=24
in Sink: diff=24
in Sink: diff=26
in Sink: diff=46
in Sink: diff=48
in Sink: diff=50
in Sink: diff=52
in Sink: diff=53
in Sink: diff=54
in Sink: diff=56
in Sink: diff=58
in Sink: diff=59
in Sink: diff=60
in Sink: diff=62
in Sink: diff=64
in Sink: diff=65
in Sink: diff=66
in Sink: diff=68
in Sink: diff=70
in Sink: diff=71
in Sink: diff=73
in Sink: diff=74
in Sink: diff=76
in Sink: diff=77
in Sink: diff=79
in Sink: diff=81
in Sink: diff=82
in Sink: diff=83
in Sink: diff=85
in Sink: diff=86
in Sink: diff=88
in Sink: diff=88
in Sink: diff=90
in Sink: diff=92
in Sink: diff=92
in Sink: diff=94
in Sink: diff=95
in Sink: diff=97
in Sink: diff=98
in Sink: diff=99
in Sink: diff=0
in Sink: diff=2
in Sink: diff=4
in Sink: diff=4
in Sink: diff=5
in Sink: diff=7
in Sink: diff=9

如您所见,延迟是一种模式,逐渐增加到100,从0开始下降,循环重复。我需要尽可能低的延迟。这个例子是我实际应用程序的简化版本。有人能给我解释一下延迟的原因,以及如何将延迟降低到尽可能低的程度吗。

lc8prwob

lc8prwob1#

造成这种延迟的原因是,通过添加keyby,您将强制进行网络洗牌以及序列化/反序列化。延迟如此多变的原因是因为网络缓冲。
您需要阅读文档中名为“控制延迟”的部分。tl;dr是指您要将网络缓冲区超时设置为较小的值:

env.setBufferTimeout(timeoutMillis);

如果需要,可以将缓冲区超时设置为零,但这比将其设置为小值(如1ms或5ms)对吞吐量的影响更大。默认值为100ms。有关flink中网络堆栈的组织方式的详细信息,请参阅flink项目博客上的flink网络堆栈的深入研究。
在讨论这个问题时,其他延迟源可能包括检查点屏障对齐和垃圾收集。

env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.AT_LEAST_ONCE);

将禁用屏障对齐,代价是放弃一次处理语义。
使用rocksdb state后端将减少垃圾收集对象的数量(因为rocksdb将其状态保持在堆外),在某些情况下,以更差的平均延迟为代价来改善最坏情况下的延迟。然而,现代垃圾收集器使用rocksdb来提高最坏情况下的延迟可能是一个错误。
也,

env.getConfig().enableObjectReuse();

将指示运行时重用用户对象以获得更好的性能。请记住,当用户代码函数没有意识到这种行为时,这可能会导致错误。
如果使用的是水印,则水印延迟会影响触发事件时间计时器的延迟(包括windows),并且自动水印间隔也会影响延迟。
最后,事务接收器的使用增加了端到端延迟,因为这些接收器的下游使用者在事务完成之前不会看到提交的结果。预期的延迟大约是检查点间隔的一半。
如果您对测量延迟感兴趣,请查看延迟跟踪和监视apache flink应用程序101中有关延迟的部分。

相关问题