现在我们尝试使用事件时间来解决情况二的延时问题。要启用事件时间处理，需要一个时间戳提取器，从消息中提取事件时间信息。流式计算按照数据的事件时间来将数据分配到对应的窗口，而不是按照处理数据的时间，处理结果如下图。
引入事件时间后的结果看起来更好了，窗口2和窗口3发出了正确的结果，但是窗口1仍然是错误的。Flink没有将延迟的消息分配给窗口3，因为它现在检查的是消息的事件时间了，并且理解它不在窗口中。但是为什么没有将消息分配给窗口1呢？原因在于延迟的消息到达系统时（第19秒），窗口1的评估已经完成了（15秒）。
4.3.3 水印为了达到解决情况二的问题，达到情况一的预期结果。引入水印机制，水印机制可以看作是一种告诉Flink一个消息延迟多少的方式。现在将水印设置为当前时间负5秒，告诉Flink希望消息最多有5秒的延迟，这是因为每个窗口在水印通过时被评估。由于设置的水印时间为当前时间负5秒，所以窗口1（5秒~15秒）将在第20秒时被评估，以此类推，窗口2（10秒~20秒）将在第25秒时进行评估。优化后的结果如下：
最后调整引入水印机制后，得到正确的结果，这3个窗口均按照预期的方式发出计数，即(F,2)、(F,3)、(F,1)。
5.总结（Flink VS Spark）了解了Flink和Spark各自的特点后，知道了Spark Streaming通过小批量的方式保证了吞吐的情况下，同时提供了Exactly Once语义，但是不是严格意义上的实时，而且由于微批处理的方式，对窗口和事件时间的支持比较有限。Flink采用分布式快照的方式实现了一个高吞吐、低延时，并且支持Exactly Once的实时计算引擎，同时Flink的实时计算引擎也能更好支持窗口和事件时间。
通过对Flink和Spark特点的掌握，再结合实际的项目需求、业务场景、以及技术储备，来选取最适合的计算引擎。
6.结束语这篇博客就和大家分享到这里，如果大家在研究学习的过程当中有什么问题，可以加群进行讨论或发送邮件给我，我会尽我所能为您解答，与君共勉！
另外，博主出书了《Kafka并不难学》和《Hadoop大数据挖掘从入门到进阶实战》，喜欢的朋友或同学， 可以在公告栏那里点击购买链接购买博主的书进行学习，在此感谢大家的支持。关注下面公众号，根据提示，可免费获取书籍的教学视频。