Flink深入之:理解ProcessFunction的Timer逻辑

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码)：https://github.com/zq2599/blog_demos

本文概览

• 减少铺垫，长话短说，本文作用是辅助理解Process Function的定时器，仅通过几个关键点把定时器逻辑说清楚，因此文章很短；
• Flink官方有篇文章是讲Process Function的，地址是：https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/operators/process_function.html
• 这篇文章中给出一个demo，里面用了定时器，核心代码如下图：

在这里插入图片描述

• 建议您先把上述官方代码看一遍，这样再看过下面几个关键点，就能熟练使用此定时器了；

定时器的几个关键点

• 下图红框中的registerEventTimeTimer方法只要执行了，则蓝框中的onTimer方法就会执行（之前曾天真的猜测第二次registerEventTimeTimer会覆盖掉第一次注册的timer，但实际上，只要registerEventTimeTimer的入参不同，就不会覆盖）：

在这里插入图片描述

• 如下图，onTime方法执行时，timestamp的值是之前registerEventTimeTimer的入参：

在这里插入图片描述

• 最后一点也是最关键的一点：每次执行processElement都会修改state，所以，每次onTimer执行的时候，拿到的state都是最近一次processElement中写入的值，因此，假设processElement执行10次，onTimer也会执行10次，但下图红框中的判断只有最后一次等于ture，因为每次判断时，左边的timestamp都是不同的processElement产生的，但右边的result.lastModified却是同一个（最后一次processElement中写入的）：

在这里插入图片描述

举例说明

第一次执行processElement，时间是12:01:01，因此state中记录的是12:01:01，registerEventTimeTimer入参就是12:11:01（这就是第一个onTimer的timestamp入参）

第二次执行processElement，时间是12:01:05，因此state中记录的是12:01:05，registerEventTimeTimer入参就是12:11:05（这就是第二个onTimer的timestamp入参）

第一个onTimer执行，timestamp是12:11:01，取得state是12:01:05，因此timestamp == result.lastModified + 60000判断为false(12:11:01不等于12:11:05)

第二个onTimer执行，timestamp是12:11:05，取得state是12:01:05，因此timestamp == result.lastModified + 60000判断为false(12:11:05等于12:11:05)

关于容器和镜像的环境

如果您不想自己搭建kubernetes环境，推荐使用腾讯云容器服务TKE：无需自建，即可在腾讯云上使用稳定， 安全，高效，灵活扩展的 Kubernetes 容器平台；

如果您希望自己的镜像可以通过外网上传和下载，推荐腾讯云容器镜像服务TCR：像数据加密存储，大镜像多节点快速分发，跨地域镜像同步

你不孤单，欣宸原创一路相伴

1. Java系列
2. Spring系列
3. Docker系列
4. kubernetes系列
5. 数据库+中间件系列
6. DevOps系列

欢迎关注公众号：程序员欣宸

微信搜索「程序员欣宸」，我是欣宸，期待与您一同畅游Java世界...加粗