理解ProcessFunction的Timer邏輯

歡迎訪問我的GitHub

https://github.com/zq2599/blog_demos

內容：所有原創文章分類匯總及配套源碼，涉及Java、Docker、Kubernetes、DevOPS等；

本文概覽

1. 減少鋪墊，長話短說，本文作用是輔助理解Process Function的定時器，僅通過幾個關鍵點把定時器邏輯說清楚，因此文章很短；
2. Flink官方有篇文章是講Process Function的，地址是：https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/operators/process_function.html
3. 這篇文章中給出一個demo，里面用了定時器，核心代碼如下圖：

4. 建議您先把上述官方代碼看一遍，這樣再看過下面幾個關鍵點，就能熟練使用此定時器了；

定時器的幾個關鍵點

1. 下圖紅框中的registerEventTimeTimer方法只要執行了，則藍框中的onTimer方法就會執行（之前曾天真的猜測第二次registerEventTimeTimer會覆蓋掉第一次注冊的timer，但實際上，只要registerEventTimeTimer的入參不同，就不會覆蓋）：

2. 如下圖，onTime方法執行時，timestamp的值是之前registerEventTimeTimer的入參：

3. 最后一點也是最關鍵的一點：每次執行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)

你不孤單，欣宸原創一路相伴

1. Java系列
2. Spring系列
3. Docker系列
4. kubernetes系列
5. 數據庫+中間件系列
6. DevOps系列

歡迎關注公眾號：程序員欣宸

微信搜索「程序員欣宸」，我是欣宸，期待與您一同暢游Java世界...
https://github.com/zq2599/blog_demos