在前一篇里笼统的介绍了一下flink的时间，但感觉说的还不够，那么今天就专门来说说时间。
本文仅代表个人理解，如有错误，请不吝赐教。欢迎转载，请注明出处。
首先flink里与《Streaming 101》(后面简称101)里介绍的时间有一些不同，多引入了一个概念：摄入时间（Ingestion time）。所以在flink里有三类时间：处理时间（Processing time）、事件时间（Event time）、摄入时间（Ingestion time）
处理时间：事件发生的时间。这个概念很容易理解，就是时间发生的当前机器的时间，他不需要协调机器时间和流中事件相关的时间。他提供了最小的延时和最佳的性能。但是在分布式和异步环境中，处理时间不能提供确定性，因为他对事件到达系统的速度和数据流在系统的各个节点之间处理的速度很敏感。
事件时间：事件流入系统的时间。事件时间对于乱序、延时、或者数据重放等情况，都能正确处理，这是因为事件时间依赖于事件本身，而跟物理时钟没有关系。利用事件时间编程时必须指定如何生成事件时间的watermark，这是使用事件时间处理事件的机制。机制是这样描述的：事件时间处理通常存在一定的延时，因此自然的需要为延时和无序的事件等待一段时间。因此，使用事件时间编程通常需要与处理时间相结合。
这张图，是来源于101里的一张经典图，可以从图中看出，理想状态下，事件时间和处理时间相同。也就是事件一发生就会立即被处理，但是这是也只是美好的愿望。现实中几乎不可能发生，这点大家应该很容易理解。
所以，处理时间一定是滞后于事件时间的，而且不是线性的，也没有固定规律，这取决于网络，访问量等诸多因素。
下图，原谅色部分是我加入的，摄入时间，一定是在处理时间和事件时间之中的。
摄入时间：摄入时间是事件进入flink的时间，在source operator中，每个事件拿到当前时间作为时间戳，后续的时间窗口基于该时间。
摄入时间与处理时间相比：稍微昂贵一点，但是能过够给出更多可预测的结果。因为摄入时间使用的是source operator产生的不变的时间，后续不同的operator都将基于这个不变的时间进行处理，但是处理时间使用的是处理消息当时的机器系统时钟的时间。
摄入时间与与事件时间相比：摄入时间无法处理延时和无序的情况，但是不需要明确执行如何生成watermark。
在系统内部，摄入时间采用更类似于事件时间的处理方式进行处理，但是有自动生成的时间戳和自动的watermark。
从上面这个流程图，就可以从流程上，理解各个时间所处的位置。和在处理中起到的作用。
关于flink的time，我们暂时说到这里。
下一篇预告：
说到这里，flink是如何完成 exactly-once的？通过检查点，那么怎么加的检查点呢？是通过watermark，看文章有人翻译成水位线，有人翻译成水印，个人比较推荐使用水印的，因为这样可以方便你后续理解程序，反正我开始看一些文章，总觉得水位线这个翻译，和他起到的作用，有一种很割裂的感觉。
这段话，是我再上一篇里关于watermark翻译的一些理解，最近在研究的时候发现，似乎水印还真不如水位线适合场景，所以下一篇，我们来说说watermark。
参考：
[1]:https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101
[2]:https://ci.apache.org/projects/flink/flink-docs-release-1.4/dev/event_time.html
[3]:https://www.jianshu.com/p/f90831c1e96d
