对于Flink流式传输/Flink有状态函数，已知setBufferTimeout为小值(例如5ms(将提供"最佳"延迟体验。在优化Flink流或有状态函数作业中的延迟时，必须注意的其他推荐配置值是什么(设置、重置、修改..(？
端到端延迟受到许多因素的影响。忽略Flink摄入事件之前累积的延迟，这就需要考虑以下问题：
- 网络缓冲区超时
- 序列化
- 对象重用
- 水印延迟(用于容纳无序事件(
- 自动水印间隔
- 状态访问(依赖于状态后端(
- 垃圾收集
- 定时器
- 聚合(例如窗口化(
- 事务汇
- 检查点
- 背压
利用操作员链。避免不必要地使用keyBy和更改并行度。在适当的情况下使用reinterpretAsKeyedStream。
以上几点将有助于避免不必要的序列化，但您也应该注意优化序列化。使用缓慢的序列化程序可能会产生巨大的影响，使用复杂的、深度嵌套的集合类型也会产生巨大影响
您应该始终启用对象重用。默认情况下，Flink会防御性地复制操作员链中传递的对象。启用对象重用时，请记住对来说是不安全的
- 记住函数调用或
- 修改输入对象
如果你避开这两点，你可能
- 修改输出对象并再次发射
如果使用事件时间处理，最佳情况是能够依赖于递增的时间戳，并相应地生成水印(零延迟(。如果你正在进行窗口化，那么在窗口关闭时进行预聚合可以避免负载峰值，而配置短的自动水印间隔将有助于最大限度地减少延迟。
FsStateBackend将状态作为堆上的对象进行维护，然后对其进行GC。此状态后端具有最佳的平均延迟，但您需要仔细调整垃圾收集器以避免GC停滞。虽然总体速度要慢得多，但RocksDB状态后端可能具有更好的最坏情况延迟，尤其是如果您需要在每个任务管理器上运行多个任务槽的情况下。使用FsStateBackend，每个TM一个插槽将使GC的范围更小，这有助于减少延迟。
避免同时启动多个计时器。为不同的钥匙在不同的时间点火安排窗户。
请记住，事务接收器的下游消费者将经历由检查点间隔控制的延迟。
如果您不需要一次保证，请通过配置检查点以使用CheckpointConfigInfo.ProcessingMode.AT_LEAST_ONCE来禁用检查点屏障对齐。
在某些情况下，未对齐的检查点可能非常有用。
最后，尽你所能避免背压。给这份工作足够的资源。不要在你的用户功能中做任何阻塞i/o。尽量避免数据偏斜(热键(。