flink-概述

operator并行度相同+forward可合并，此时Task是一个operator chain，含main operator

时间/计数 滚动/滑动 注意滚动不重叠，滑动需指定滑动步长 会话窗口(一段时间无数据进入结束窗口)
Event/Ingestion/Window Processing Time，多用event time
watermark: 当event time=x的事件到达，认为event time=x-watermark的事件都到达了，注意不一定是event time
operator state: 如kakfa connector内的位点，keyed state：keyed stream 每一个key的state
重启：不重启/固定延迟/失败率(一段时间内失败次数到达阈值)
allowedLateness：当watermark到达，触发窗口关闭，关闭后allowedLateness时间范围内来一条数据就计算(获取结果)并向后输出一次
sideOutput：超过allowedLateness输出到sideOutput

count/gauge的累加: 来一条数据不是保留其原始数据，而是累加到一个值或MergingDigest上去
count/gauge的计算: 计算不是真实的计算，而是获取这个累加的对象(值或MergingDigest)
watermark和allowedLateness区别：两者一样都延长了其内存保留时长，区别在于watermark设置太大，数据很晚才计算并向后输出，allowedLateness设置太大，数据除了第一次watermark到了输出，后面每来条数据都要计算(获取结果)并输出，详见WindowOperator.processElement

checkpoint流程：具体可见org.apache.flink.streaming.runtime.tasks.SubtaskCheckpointCoordinatorImpl#checkpointState
broadcast barrier
同步：snapshotState和构建future
异步：future内写持久化存储（DefaultOperatorStateBackendSnapshotStrategy）+ ack (表达我这个subTask checkpoint完成)

Task主线程
一般一个subTask只含有一个线程，SourceStreamTask 相对特殊，带有LegacySourceFunctionThread，两线程依靠checkpointLock同步，所有的mail(checkpoint,timer)和event处理都是同步的，注意Flink Source还有一个consumer Thread用于实际拉取消息
一般来说主线程循环处理mail和input(defaultAction- processInput, 处理一个元素)，source特殊其processInput为启动LegacySourceFunctionThread（只会运行一次）

flink source(FlinkKafkaConsumer)
每个subTask通过assign分配具体partition
OffsetCommitModes: checkpoint打开，默认enableCommitOnCheckpoint，即checkpoint complete时提交offset
StartupMode 默认group_offsets，即flink任务启动从消费组已有的位点开始消费，我们经常配置latest直接从最新位点消费
snapshotState ：内存里放入已经处理完毕的位点 （本质是保留state供重启后使用）
notifyCheckpointComplete：对应checkpoint的处理完毕位点commit